Hacking Concrete5 – ProBlog 2.6.6 & ProEvent 2.8.5 (CSRF, XSS, Side Effects)May 23, 2016
- I talk about the last C5 plugin exploit I found
- The CSRF & XSS exploit
- Side Effects
My last security report here concerned the ProEvents Concrete5 plugin. After the Portland Labs team reviewed the developer’s plugins, they posted on their blog that they were unable to find any further vulnerabilities.
I figured I would take a crack at it and see what I could find. I also hoped that the new security policies in place would allow for a smoother disclosure process.
Because the ProBlogs plugin does not validate the anti-csrf token on a POST request. A victim who is logged in could be fooled into clicking a malicious form (styled to look like a link, image, etc) which would create a page in their C5 website.
Because the ProBlogs plugin does not validate the parent cID asserting it is the actual Blog, the attacker could potentially place the page anywhere on the C5 site map tree.
CSRF & XSS
You can easily style the following form below to look like an image or link. From there, social engineering or phishing techniques have a high probability of allowing someone to succeed with the attack.
<input name=“cParentID” type=“hidden” value=“0” />
Although I only reported the issues with the ProBlog plugin, the developer communicated promptly and then proactively fixed the issues in both of his plugins within three hours. As a customer I greatly appreciate this and as a researcher I appreciate the developer’s commitment to security.
Unlike the previous report, HackerOne was utilized this time. I do think it helped the communication. The critical bit for me about HackerOne is that just because I’m reporting something using the vendor’s desired channel doesn’t mean I am agreeing to their specification for “Responsible Disclosure.” I believe HackerOne hasn’t really solved this.
My submission required that I put the word “crayons” in the body and I missed it because it wasn’t in the “Requirements” section. I’m not the only reporter who has missed this. I’d remove it.
I’d remove the wall of text and just put a template of what you require.
As soon as the issue is fixed and the patch is on the marketplace, I’d recommend the issue be disclosed. My opinion is that all should get the information equally.
I believe that all comments for the exploit should be visible so that others can learn from the conversation. Both in how to disclose a vulnerability and also in thinking about how to code solutions to protect their own projects.
I also wanted to see a notification channel so that users can subscribe and be alerted (email, blog). PortlandLabs did take this suggestion and create a security blog but my post is up and their blog has no mention as of yet (link). I think the community should get this information as quickly as possible in an easily consumable format.
- 20160422 – Disclosed via HackerOne and email@example.com (https://hackerone.com/reports/133847)
- 20160422 – Developer fixed issues in < 3 hours and posting the new version online
- 20160522 – Issue publicly disclosed 30 days after report