10 Mar

Developer Security Advisory: CodePeople

On February 8 a report of several vulnerabilities in CodePeople’s Booking Calendar Contact Form plugin was released. While reviewing those for inclusion in our data we found that issue 5, a cross-site request forgery (CSRF) vulnerability that permitted the deleting calendar items still existed. That own its own is not major issue since someone would have to want to cause calendars to be deleted and get someone logged in as admin to visit a page that would caused it to happen, so we didn’t find much concern with that. We did notify the developer and several days later it was fixed.

While that on its own seems to be a minimal issue, over the next month vulnerability were reported in two more of the plugins and in each case CodePeople failed to fully resolve the issues, leaving us to believe the security of their plugins should be a concern.

Second Time

On February 24 a report of a session hijacking vulnerability in their Calculated Fields Form plugin was released. When we tested we found that a persistent cross-site scripting (XSS) vulnerability mentioned in that report still existed. We thought that maybe they were still working on fixing it, but we decided to notify them just in case they missed that.

The response we got back was odd:

The mentioned authenticated persistent cross-site scripting vulnerability cannot be considered a plugin vulnerability in this case but a WordPress feature: The WordPress posts and pages allow to paste <script> tags directly on them, so adding the script via the shortcode doesn’t add a new privilege since that privilege is already supported by the WordPress editor without needing a shortcode. The editors already have access to paste any scripts into the WordPress pages/posts.

It is true that editor level users are allowed to use unfiltered html by default, but that would seem to make this a bug not a feature in that cases, since it doesn’t seem to have been intended. The larger issue is that we had not said anything about editors (since we are aware of their capabilities) and the original advisory specifically mentions both authors and editors:

The attacker must have an account like author or editor for create posts and embed malicious shortcodes and hijack admin or other user’s sessions.

After we pointed out that it impacted authors as well, the issue was fixed.

Third Time

On March 2 a report of several vulnerabilities in their CP Polls plugins was released, including cross-site request forgery (CSRF) / cross-site scripting (XSS) vulnerability in the plugin’s import functionality. When we tested that we found that the CSRF portion of the vulnerability existed. So yet again that hadn’t resolved part of the issue and again the had failed to add CSRF protection despite the ease of doing it. By doing that they would prevent the possibility of similar issues since without the CSRF the other issues would not be exploitable. The importation of data into the website also seems like something that would be important to be properly secured to us.

09 Mar

Developer Security Advisory: Smackcoders

Recently four of Smackcoders plugins were to found by Rahul Pratap Singh to have reflective cross-site scripting (XSS) vulnerabilities. This type of vulnerability is not something we really see being exploited, probably due in large part due to the fact that all of the major web browsers other than Firefox have filtering that should prevent it from being successful in most cases. But the presence of it does indicate that the developer is not too concerned about security as properly handling user input data is really a basic piece of programming in a secure fashion.

Also of concern was how long it took the developer to respond after the issues were discovered. Here are the timelines given by discoverer of the vulnerabilities for how long it took for the the vulnerabilities to be fixed

WP Ultimate CSV Importer:

  • January 14, 2016 – Bug discovered, initial report to Vendor
  • January 14, 2016 – Vendor acknowledged and scheduled a fix
  • January 18, 2016 – Reported to wordpress
  • January 19, 2016 – WordPress Response, plugin taken down
  • January 26, 2016 – Vendor Deployed a Patch

WP Advanced Importer Plugin:

  • January 30, 2016 – Bug discovered, initial report to WordPress
  • February 1, 2016 – WordPress response, plugin taken down
  • February 23, 2016 – Vendor Deployed a Patch

WP Ultimate Exporter:

  • January 30, 2016 – Bug discovered, initial report to WordPress
  • February 1, 2016 – WordPress response, plugin taken down
  • February 24, 2016 – Plugin up with same version

Import Woocommerce:

  • January 30, 2016 – Bug discovered, initial report to WordPress
  • February 1, 2016 – WordPress response, plugin taken down
  • February 24, 2016 – Vendor Deployed a Patch

If there were larger issue found you obviously don’t want to have the plugin remaining vulnerable for weeks.

Larger Issues

It turns out that the reflected XSS vulnerabilities was not the end of their issues in properly handling user input. After seeing the report of the issue in WP Ultimate Exporter Henri Salo noticed that the plugin was also vulnerable to SQL injection, due to a failure to use prepared statements. This would be more an issue than the reflected XSS vulnerabilities, but for you average website probably not a major one.

When we reviewed that report we noticed an even larger issue, the export function of the plugin does not do any check to make sure that the request for export is properly authenticated. That means without being logged in anyone can get a copy of the data the plugin can export, which includes custom posts, pages, and posts. In many cases that wouldn’t matter since all the pages and posts on the website are publicly available, but if some are not supposed to be accessible to the general public they would be through this issue.

We contacted the developer last Monday and informed of these two issues. We received an automated reply that they would be getting back to us, “usually within 24 hours”. But by Friday we had not received any response, so we went ahead and notified the people running the Plugin Directory. On Monday the plugin was removed from the directory and so far it has not been fixed.