Closed security-breachlock closed 6 years ago
I don't see the security bug in this? You are logged on, so you can simply go to the page and modify it.
The step 1 and step 2 consecutively is very small. and will only be possible in a spearfishing attack.
If you see this differently please explain..
Step 1: logon Step 2: go to a compromised webpage which knows your website to construct the page Step 3: have the victim press a button (Or have it in the body.onload)
Added captcha implementation to the Settings page. This is no longer possible. Fixed in pre-release 4.7.8-dev2
Have you verified my solution for the settings page..
Hi,
Thanks for your positive response,
Did you use CVE ID to track these bugs?
Looking forward to hearing from you.
Hello,
We use Github to track bugs.
I didn't log an CVE, and I will not, the security researcher is the one requesting and maintaining the CVE, not the developer.
In this case this is not a security bug in the sense that the password is required (Or being logged on) before this is exploitable. After having the password everything is modifiable otherwise logging in is not needed. The admin part after being logged in is assumed trusted, and therefor all changes are trusted. When no password (being logged in) is required this would qualify as a security bug.
The modification done is simply requiring an additional check (CAPTCHA) before changing the settings.
Regards,
Bas
This is an invalid report. With the password the complete website can be taken over. Without the password this is not exploitable.
Affected software: Pluck v4.7.7
Type of vulnerability: CSRF
URL: https://www.pluck-cms.org
Discovered by: BreachLock
Website: https://www.breachlock.com
Author: Balvinder Singh
Description: CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim. CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests. It's sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called "stored CSRF flaws". This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.
Proof of concept: Step1: Login into the pluck CRM. Step2: Here in general setting we can change the title of the website and email of the victim. VulnerableURL:http://localhost/pluck/pluck-4.7.7/admin.php?action=settings
Step3: Here is the crafted code which we used to execute the csrf successfully. Save this code with .html and run it on your browser. After running the below code we will get the submit request button and clicking this button will change the title and email address of the victim.
Step4: here we successfully changed the title and email parameter using the crafted code.