19 Jan

Vulnerability Details: Information Disclosure Vulnerability in W3 Total Cache

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

19 Jan

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) in Arigato Autoresponder and Newsletter

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

18 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Event Notifier

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

17 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Stop User Enumeration

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

17 Jan

Reflected Cross-Site Scripting (XSS) Vulnerability in WangGuard

We recently introduced a new feature where we do security reviews of plugins that are selected by our customers. The first review was of WangGuard. The most serious issue we found in that reviews is a reflected cross-site scripting (XSS) vulnerability.

In the file /wangguard-user-info.php the value of the GET input “userIP” is set as the value of the variable $userIP without any sanitization:

11
$userIP = $_GET["userIP"];

That value is then printed without it being escaped:

33
printf( __('User IP: %s <br />'), $userIP);

Proof of Concept

The following proof of concept will cause any available cookies to shown in alert box. Major web browsers other than Firefox provide XSS filtering so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?page=wangguard_users_info&userIP=<script>alert(document.cookie);</script>

Timeline

  • January 2, 2017 – Developer notified.
  • January 17, 2017 – WordPress.org Plugin Directory notified.
  • January 18, 2017 – Version 1.7.3 released, which fixes vulnerability.
17 Jan

WordPress Plugin Security Review: WangGuard

Last week we did the first release of results from our security reviews of WordPress plugins selected by our customers. That actually involved the second the plugin we reviewed though, as we were waiting to hear back from the developer of the first plugin we reviewed, WangGuard, after notifying them of the security issues we found. It has now been two weeks without a response from the developer or fixes for the vulnerabilities (it looks like the plugin might not be supported anymore), so we will disclose the results now. One of the issues found is something that will usually cause a plugin to be removed the Plugin Directory, so the plugin will likely be removed from that shortly.

If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.

The review was done on version  1.7.2 of WangGuard. We checked for the following issues:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

Results

We found a number of security issues during the testing, though none that would likely be exploited by a hacker on the average website.

Reflected Cross-Site Scripting (XSS) Vulnerability

In the file /wangguard-user-info.php the value of $_GET[“userIP”] is printed without any sanitization or escaping, leading to reflective cross-site scripting (XSS). This impact of this issue is limited due to the fact that we don’t see much interest in hackers targeting this type of vulnerability, probably due to the combination that requires getting someone else to visit a URL you specify and the fact that all of the major web browsers other than Firefox have XSS filtering, which limits the ability for this type of vulnerability to be exploited.

Cross-site Request Forgery (CSRF) Vulnerabilities

We found that a number of activities that can be taken by an Administrator in the plugin are lacking protection against cross-site request forgery (CSRF). Specifically we found that changing the plugins settings on the WangGuard settings tab of /wp-admin/admin.php?page=wangguard_conf, cron job addition/deletion on /wp-admin/admin.php?page=wangguard_cronjobs, sign up moderation on /wp-admin/admin.php?page=wangguard_signupmod, deleting questions on the Security questions tab of /wp-admin/admin.php?page=wangguard_conf. The function wangguard_ajax_callback() also lacks CSRF protection.

To exploit this type of vulnerability you would need to get a logged in Administrator-level user to visit a URL or page you control, which like the last issue, means that isn’t something we see hackers trying to exploit. In this case we didn’t find any serious issue that could be done with the actions that lack CSRF protection.

Lack of Protection Against Direct Access to Files

In some files, including /wangguard-allow-signup-splogger-detected.php and /wangguard-block-login-moderation.php, the plugin has code at the beginning of the file to restrict direct access to the files. Lot of other .php files that look like they are also not intended to be accessed directly are lacking that protection. In the files we looked over we didn’t see anything that could exploited due to that.

Potential PHP Objection Due To Lack of Secure Connection

In the files /wangguard-addons.php and /wangguard-compatible-plugins.php the unserialize() function is run on what is returned from requests to http://api.wordpress.org. That has the potential to permit PHP object injection in the event of a man in the middle attack between the server and that domain. That isn’t a likely occurrence, but it could be made more secure by doing the request over HTTPS instead of HTTP. That could also be done with requests sent to rest.wangguard.com in the plugin.

12 Jan

Authenticated Persistent Cross-Site Scripting (XSS) Vulnerability in Chained Quiz

When adding a vulnerability to our data set we actually look in to it to confirm that a vulnerability actual existed, what versions of the plugin had the vulnerability, and that it has been fully fixed. Recently while looking over changes made in version 0.9.9 of the plugin Chained Quiz, which was listed as having “Fixed various XSS issues”, we noticed that one of the cross-site scripting (XSS) issues was only partially resolved.

Several of the changes made sanitized title fields for various pieces of the plugin’s quizzes. By default only Administrator-level user have access to the pages with those fields and for those users it wouldn’t have really been a vulnerability for the fields to not be sanitized since that level of user normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting. The plugin does provides the option to make those pages as well as the Social Sharing page accessible to lower level users, which would not have that capability, which would make this a vulnerability.

In looking over the relevant files what we noticed was that the rest of the text input is not being sanitized, so the vulnerability still exists on those pages.

An example of that is when creating a new question, you can see that in version 0.9.9 the value “$vars[‘title’]” is sanitized but the other text inputs “$vars[‘question’]” and “$vars[‘qtype’]” are not (the database field for “$vars[‘qtype’]” is limited to 20 characters making it difficult to use it for malicious code) :

25
26
27
28
29
$vars['title'] = sanitize_text_field($vars['title']);
 
$result = $wpdb->query($wpdb->prepare("UPDATE ".CHAINED_QUESTIONS." SET
	question=%s, qtype=%s, title=%s, autocontinue=%d WHERE id=%d", 
	$vars['question'], $vars['qtype'], $vars['title'], @$vars['autocontinue'], $id));

The text inputs on Social Sharing page are also not sanitized or escaped.

We contacted the developer about the issue and seeing as they had just fixed part of the issue and another related vulnerability, we figured they would be receptive (that is usually the case in this type of situation). Instead we got a very different response. It began:

The contents of the questions should not be filtered: it has to allow HTML and scripts if the site managers want to use them.
All these issues are “Self-XSS” that we are not interested to hear about: no one has any interest to hack their own site or give management access to people they don’t trust.

As far as we can tell self-XSS actually refers to a social engineering attack, not a vulnerability, which these are.

In our reply to that we explained that unless users have the unfiltered_html capability they are not allowed to use unfiltered HTML, so they needed to make sure users without the capability had their input sanitized. We haven’t gotten any response in the week since we sent that reply and the vulnerability hasn’t been resolved.

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/admin.php?page=chainedquiz_social_sharing, when logged in to WordPress with an account that has access to the page.

  1. As an Administrator access /wp-admin/admin.php?page=chainedquiz_options and set it so that Subscribers can manage quizzes.
  2. Log in as a Subscriber.
  3. Visit /wp-admin/admin.php?page=chainedquiz_social_sharing.
  4. In the “Your Facebook App ID” field enter ‘”><script>alert(document.cookie);</script>’ (without the single quotes around it).
  5. Click “Save All Settings”.

Timeline

  • January 4, 2017 – Developer notified.
  • January 5, 2017 – Developer responds.
  • January 12, 2017 – WordPress.org Plugin Directory notified.
  • January 12, 2017 – Removed from WordPress.org Plugin Directory.
  • January 12, 2017 – Version 1.0 submitted to WordPress.org Plugin Directory, which fixes issue.
12 Jan

Vulnerability Details: Persistent Cross-Site Scripting (XSS) Vulnerability in Chained Quiz

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

12 Jan

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Super Socializer

This post's content is only accessible to those who have an active account with our service. If you currently have one then please log in to view the content. If you don't currently have one, when you sign up now you can try the service for free for the first month.

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 Jan

A Case For WordPress Providing Details on Fixed Security Issues in Plugins

When it comes to providing information on security issues in web software the amount of information disclosed varies pretty widely. For WordPress security issues fixed in the core they are disclosed when the new version is released. For example, here is how they were mentioned in the most recent security release, 4.6.1:

WordPress versions 4.6 and earlier are affected by two security issues: a cross-site scripting vulnerability via image filename, reported by SumOfPwn researcher Cengiz Han Sahin; and a path traversal vulnerability in the upgrade package uploader, reported by Dominik Schilling from the WordPress security team.

For plugins, which are developed by third-parties, no information is released by WordPress. That isn’t the way that everyone handles the situation. TYPO3, for example, releases security bulletins, including for third party extensions.

In the past we have discussed the issue of WordPress keeping everyone in the dark about security issues in the current version of plugins that they are aware of. While they do remove those plugins from the Plugin Directory, that does nothing for those who are currently using them. Something we recently ran across seems to make the case that providing information on security issues that have been fixed could be useful as well.

It starts with a review from three weeks ago that we ran across recently, as part of our monitoring of the wordpress.org Support Forum for mentions of plugin vulnerabilities, for the plugin Menu Image that claimed that “Plugin applies malware/addware to your site.” The review stated that:

I just wanted to post a warning about this plugin. I have noticed various malicious scripts being added to one of my sites. After countless hours of tracking I found that Menu Image was the problem code. There seems to be an exploit or hole in your code.

We often run across reviews with claims that a plugin is the source of hacking where it is either unsupported by any evidence or where a quick check of the plugin shows that plugin could not have been the source of what happened to the website.

Others responded that they were having the same issue.

The developer responded in a way that wouldn’t seem to be appropriate even if the claim was totally false:

Please, disable the Menu-Image plugin and remove it from your wordpress site at all and never use it in future. I think this will not solve your problem. All plugin code you can check here: https://github.com/zviryatko/menu-image, compare it with that you have.

The reality is that the plugin was in fact the cause of this, something the developer was likely aware of (and certainly should have been), but also something the WordPress was in all likelihood also aware of.

If you read through all the responses on the review the cause of malicious JavaScript is a file notice.php that existed in some versions of the plugin.

What the legitimate purpose of that file was supposed be, if any, isn’t clear. The changelog entry for the version it was added in simply states “Add notification plugin.”

In a support forum thread five from months ago where someone asked why the noticed.php file was connecting to domain apistats.net the developer responded with this:

Yes, there is a strong reason for that, it’s help to make plugin work much better, also there’s no security issue, you can check the code by yourself. When you installed the plugin you saw the license agreement and you accepted it.

How it was supposed to make the plugin work much better isn’t explained.

Checking the code would just tell that it is making a request to that domain, it doesn’t explain why and wouldn’t show what would get served from that (according to one of the responses to the review malicious code was only served from that domain for part of the day).

The fact that there is a license agreement seems like a red flag, looking at what you actually get shown makes things seem even shadier, as you could easily think you are just agreeing the GPL:

The last response in that thread is from the developer, who indicates that the people on the WordPress side of things were aware of a security issue with the file:

Hello, I’ve removed all that code, when plugin will be approved by wp.org security team, it will be back again!

When the issue was resolved the changelog entry stated “Remove notification plugin. It was not a good idea btw.”, which wouldn’t give any one an indication what had really happened.

If WordPress had provided security bulletin on the issue after it was fixed it would have helped to clear up for people that dealt with this what was going on without them having to do a lot digging themselves. As this case shows relying on developer to provide that type of information isn’t always going to work out.