20 Oct

WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and in every instance we have seen so far, without providing a warning as the low quality of the data. As example here was what Wordfence’s plugin recently sent out to people using the plugin Sermon Browser:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

As we noted previously, the vulnerability being linked there had been fixed six years ago. For whatever reason when it was added to WPScan’s data three years ago it was not listed as being fixed, so when Wordfence reused the data without checking it first they spread inaccurate information. They didn’t include a disclaimer to warn people that they hadn’t checked that data, they even make it sounds like the opposite as they said “It has unpatched security issues”, and therefore didn’t know if it there was any veracity to the claim of a vulnerability in the plugin.

The problem with WPScan’s data isn’t limited fixed vulnerabilities are not correctly labeled as being fixed. Another issue is vulnerabilities that didn’t actually exist being included and labeled as being fixed despite not existing, an example of we just ran across while preparing another post. That could be a problem if you were using WPScan’s data while working on cleaning up a hacked website, since you might believe that you have discovered a likely cause of a hacking, through an outdated plugin, only to later find that wasn’t the case when the website gets hacked again.

This isn’t the first time we have run across this, but what we found notable about this instance is that one of our blog posts is cited despite contradicting their information.

Here is the entry as it is currently:

The claim is that there was an unauthenticated arbitrary file upload vulnerability in the plugin WP Job Manager, which has been fixed. There first reference for that, an entry at Packet Storm from July of last year, makes the claim that there was a remote shell upload/arbitrary file upload vulnerability as of version 1.25. In August of last year we wrote a post detailing why that was false, as the plugin limits what types of files can be uploaded. The plugin did and still does allow anyone to upload files permitted by WordPress.

The third reference cited by WPScan states that:

 Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in.

All that indicates is that those not logged in to WordPress can no longer uploads files through WordPress AJAX functionality, but as we already mentioned the plugin did not allow arbitrary files to be uploaded, so the change does not relate to what they said was fixed.

What is the other important part of this is what was mentioned in the post of ours that was cited:

But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

As the title of our post indicates, “Image Upload Capability in WordPress Plugin Being Abused”, the issue with this plugin was that the ability to upload images was being abused. The change made doesn’t actually remove that capability, it just removes the ability to do that through AJAX. You don’t have to take our word from that, here is what one of the developers said:

Hi there! They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

So to recap, the vulnerability that WPScan lists didn’t exist, but if there was a security vulnerability in the plugin, it still exists, just the way it was being abused at the time was removed.

While we think that WPScan’s data is good source for a lot of people because it can be accessed for free, you do get what you pay for. Where its use is more problematic is when it is used by security companies without a proper disclaimer as to the sourcing and quality issues, which also extend to have a limited set of new vulnerabilities in it. If those companies were to admit to all of that, it would probably make more people understand that the inflated claims these companies often make about their expertise are far from the truth. (It would also help us, as once people realize the value of such data, getting better quality data would likely be of more interest to some of them.)

06 Oct

Wordfence Doesn’t Want You to Know We Discovered the Vulnerability in Postman SMTP

We have seen a lot sleazy stuff out of the WordPress focused security company Wordfence, including claiming that they care more about security than the WordPress team as justification for creating a fake threat, so it shouldn’t be surprising to find their post about the removal of the plugin Postman SMTP from the Plugin Directory, which people assume is due to a reflected cross-site scripting (XSS) vulnerability we discovered, doesn’t mention us or link to our post despite being about the only substantive thing mentioned in their post. They clearly are aware of who the source was as the second paragraph clearly references our post:

On June 29, an unnamed security researcher published the details of the vulnerability, including a proof of concept. A proof of concept is a demonstration that shows the plugin author (and in this case the entire internet, including potential attackers) how to exploit the security vulnerability. The security researcher had apparently attempted to reach the author but had been unable to.

It is worth noting that here that this type of vulnerability is highly unlikely to be exploited on the average website (contrary to a recent claim by Wordfence that this type of  vulnerability “will be exploited by attackers“) and the proof of concept included just reiterates what is already mentioned in detailing the vulnerability, so someone that would be exploiting this type of vulnerability shouldn’t have a problem without it. Someone looking to do a targeted attack against a website using this plugin, likely could have easily found this vulnerability on their own (and who knows, they might already have).

One of the reasons we include a proof of concept on how to exploit vulnerabilities is so that others can double check our work, as among other things we often find that vulnerabilities that are being disclosed and claimed to be fixed, haven’t actually been. If there is a proof of concept it is easier to catch that vulnerability hasn’t been fixed and then we can work with the developer to get it fixed (and usually in that situation it can be fixed very fast). It also helps to check if there are other related vulnerabilities that have been missed, as has been the case with Wordfence’s discovered vulnerabilities in the past (or more recently them missing that vulnerable code still was in a plugin, though not accessible). There also was the situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it.

It is also important to note that all major web browsers other than Firefox have XSS filtering to protect against this type of vulnerability for years, which is likely plays an important role in it not being likely to be exploited.

When we have discussed things that Wordfence has written we have properly credited them.

Advertising Over Improving Security

We wouldn’t mind them not mentioning us if they had finally decided to actually help the effort to get WordPress to properly handle removed plugins, since that is so important. Instead their post is mostly just an ad for their plugin and service, which both leave people not knowing why plugins are removed.

Wordfence clearly understands there is an issue with people not knowing why plugins are removed as the first paragraph of their posts states:

We have received a number of questions regarding the Postman SMTP plugin which was removed from the WordPress.org directory this week.

We assume it was removed because it contains a publicly known reflected cross-site scripting (XSS) vulnerability that has not been fixed.

And later they write:

Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

They didn’t write anything about doing anything to resolve that situation, which is easily resolvable if WordPress wanted to take action, but here is all the advertising they had time to include in the post instead:

Both Wordfence Free and Premium users who have the firewall enabled have been protected against attempts to exploit this vulnerability from day one. In addition, we alerted all Wordfence users who have the plugin installed when it was removed from the plugin directory.

It should be noted they didn’t provide any evidence that their plugin actually can protect against this type of vulnerability (or for that matter do they provide evidence that it does for other types and our testing hasn’t shown it to provide much protection). As we mentioned before the major web browsers other than Firefox provide protection against this type of vulnerability as well, something Wordfence didn’t note.

Wordfence Firewall Includes Robust XSS Protection

The Wordfence firewall includes protection against new and emerging XSS attacks. Both Wordfence free and Premium users have been protected against this attack since (and before) it was made public. This is a great example of why using a firewall to protect your website is so important: you are immediately protected against most new threats.

In cases where we don’t already protect against a new threat, we develop a new firewall rule, deploying it to our Premium customers in real-time and free customers 30 days later. This ‘virtual patching’ by our security analysts and developers keeps your sites safe.

Wordfence Alerts You When Plugins Are Removed From WordPress.org

When plugins you have installed on your site are removed from WordPress.org, Wordfence alerts you. There is a long list of reasons why the plugin team at WordPress.org might remove a plugin from the directory. One common reason is that someone has discovered a security vulnerability that has not yet been fixed. Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.


If you haven’t already, we suggest that you install Wordfence on all of your WordPress websites. It will alert you when your plugins have been abandoned or removed from the the WordPress directory. Its firewall will also protect you against new and emerging attacks.

Finally, consider upgrading to Wordfence Premium if you haven’t already. The real-time firewall rule updates will protect you from the latest threats. In addition, the real-time IP blacklist will stop all attacks from the most malicious IPs, regardless of what they’re up to.

Our Advertising

Since Wordfence is going to use a vulnerability we discovered to advertise their service so garishly, we will quickly plug our service, which would have not only warned you about the vulnerability in you were using the plugin back when it was disclosed in June, but we would have also have been available to help you make the best decision as to deal with.

The more customers we have the more we are able to improve the security of WordPress plugins for everyone using them. While this vulnerability has gone unfixed, this week we help get vulnerabilities fixed in plugins with 140,200+ active installs and we have contacted developers of plugins with another 500,000+ active installs about vulnerabilities in them that need to be fixed.

Fixing the Vulnerability

As we said before the vulnerability isn’t something that is a big concern, so it wouldn’t be a big risk to keep using the plugin in its current form, but fixing the vulnerability is easy.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php in the plugin replace this line:

value="<?php echo $_REQUEST['page'] ?>" />


value="<?php echo esc_attr($_REQUEST['page']) ?>" />

The esc_attr() added will escaping the value, which prevents the possibility of reflected cross-site scripting (XSS).

03 Oct

Wordfence Still Being Irresponsible When It Comes To Disclosing Vulnerabilities

On September 22, we discussed a PHP object injection vulnerability that had been fixed in the plugin Appointments, which we had spotted being fixed due to the proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. What was somewhat concerning about the handling of the vulnerability was that the vulnerable code still was in the plugin, though not accessible through it anymore. What had happened is the code originally was contained in one file and then that file’s contents were split among several files, but the old file was never removed. After we notified the developer, that file was removed, but the version number wasn’t changed so those already running 2.2.2 still have the code.

Two companies with a security focus had missed the code was still in the plugin, the developer of the plugin, WPMU DEV, and the discoverer of the vulnerability, Wordfence. That is a good reminder of why providing the details of vulnerabilities that has been fixed is important because even security companies can miss issues related to a vulnerability. That has been the case in multiple instances with the few vulnerabilities that Wordfence has disclosed in the past, including a situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it. Making those instances more problematic was that Wordfence failed to provide the details that would have easily allowed someone else to check to make sure everything had been properly resolved. Only because we did the work to figure details of those vulnerabilities were we able to spot and help get some additional related vulnerabilities fixed in some of the plugins.

In the post on that vulnerability in Appointments we wondered if Wordfence would handle the situation better, if and when they mentioned that vulnerability:

 If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

We now have the answer, they didn’t. They release a post on it and couple of apparent PHP object injection vulnerabilities yesterday and it lacks the details that would have allowed someone to easily see that the same code existed elsewhere in the plugin. Since a PHP object injection vulnerability requires more than just knowing about the vulnerability (you need to be aware of code that can be accessed through the vulnerability), providing more details wouldn’t likely to have done little to increase the risk from disclosing more details.

Considering they are claiming all three vulnerabilities are zero-day vulnerabilities, which are vulnerabilities being exploited before the developer becomes aware of them, some hackers would already be aware of how to exploit them, further reducing the additional risk caused by doing that.

In that past Wordfence has referred to any vulnerability they discovered as a zero-day vulnerability and the post lacks details that would make it clear these all were really zero-day vulnerabilities, so the claim of them all being zero-days seem a bit questionable (though PHP object injection vulnerability are highly likely to be exploited).

The Missing Details Could Be Useful

For one of the other vulnerabilities, in the plugin Flickr Gallery, we also spotted it being fixed through our proactive monitoring. What isn’t mentioned in Wordfence’s post or further discussion of that post is a note added to that plugin alongside the fix for the vulnerability:

This plugin is deprecated, please remove it from your WordPress install.

With the third plugin we didn’t notice a PHP object injection being fixed in it at the time and in looking at the changes so far we haven’t figured out where there would have been a PHP object injection fixed. That vulnerability is supposed to have been fixed in version of the plugin RegistrationMagic-Custom Registration Forms.

In looking over the changes made in that version the only change that directly involves code that could be involved in PHP object injection looks like this in version (in the file /includes/class_rm_dbmanager.php):

$result = maybe_unserialize($wpdb-&gt;get_var("Select form_options FROM `$table_name` where `$primary_key` = $form_id"));

In the code has been changed to use a prepared statement in the SQL query in it:

$result = maybe_unserialize($wpdb-&gt;get_var($wpdb-&gt;prepare("Select form_options FROM `$table_name` where `$primary_key` = %d",$form_id)));

There isn’t an obvious way that would prevent a PHP object injection vulnerability.

The rest of the changes mainly involve using prepared statements for SQL queries and adding a missing function.

As of version there look to be 61 usage of the maybe_unserialize(), so it could be the change made in that version impacts code elsewhere that would have lead to PHP object injection. We are going to have to look closer at the rest of the code to try to figure out what is going on. If you have figured it out, please let us know.

Knowing where a PHP object injection would have been fixed there is important because it could help to get other vulnerabilities fixed, since it would make it more likely that others could spot similar vulnerabilities. For example, the way we noticed the other two vulnerabilities being fixed also led to us identifying 9 unfixed vulnerabilities related to PHP object injection that we disclosed just last month (we noticed additional ones through other methods):

26 Sep

Wordfence Falsely Claims Current Version of Removed Plugin Contains Vulnerability That Was Fixed Over Six Years Ago

A couple of weeks ago we noted that Wordfence was trying to make people reliant on their plugin instead of helping everyone in the WordPress community by getting behind the effort for WordPress to start alerting when websites are using plugins that have been removed from the Plugin Directory. One of the reasons we noted as to why what they were doing was problematic even for those using their plugins, is that the people on the WordPress side of things know why plugins are removed and could let people know why, while Wordfence can’t. It turns out though that Wordfence will present things in way that leads to people to believe otherwise, while in the case of at least one plugin, presenting incredibly inaccurate information about the security of it.

Through monitoring of the WordPress Support Forum we do to keep track of vulnerabilities in WordPress plugins, we came across the thread about the plugin Sermon Browser, which has been removed from the Plugin Directory. The original poster in thread wrote:

I just received a “Critical” security notice from my website last week. It stated that the plugin was removed from the WordPress repository because of critical security issue. Apparently a SQL injection vulnerability has been identified.

I am sure the owner was notified of the removal. But I would expect a “sticky” post or an update or something. Has anybody else heard of any response to this?

Below that was the message from Wordfence:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

Following the link to the entry on the WPScan Vulnerability Database in that message brings up this page:

The most important things to note in that is the vulnerability is not labeled as being fixed and the dates, the listing was added on “2014-08-01″ and last updated ” 2015-05-15″. From that page you can get the actual information on the vulnerability.

In looking over things we found that the vulnerability was actually fixed the same day it was disclosed, back on April 26, 2011.

That the information in the WPScan Vulnerability Database isn’t accurate isn’t a surprise. It was just back in June that we discussed their inaccurately label an unfixed vulnerability as being fixed. In April we noted another instance where they labeled fixed plugins as not being fixed. We could go because there are plenty of instances we have discussed on this blog, which certainly are not all of them.

WPScan’s accuracy issues are only part of the problem here, as Wordfence is choosing to further spread the inaccurate information. Either they haven’t done any due diligence at all on their data source on plugin vulnerabilities, which would not put them in a good light, or what seems more likely, they know and don’t care. It’s not like no one has pointed out the problem with Wordfence using that data before, we did that back in May. The other option Wordfence could use is to check the information to make sure it is correct before passing it along to those using their plugin, but what we have seen repeatedly is they either don’t have the skills to do that sort of thing or are too lazy to do that.

If you are a customer of Wordfence’s you might want stop that since you are giving money to a company that doesn’t seem to have interest in really improving security, but you should at least contact them and let them know they should get behind the effort to get WordPress to properly handle alerting for removed plugins.

If you want accurate data on vulnerabilities in WordPress plugins you can get that with our service or in more limited form with the free data on vulnerabilities that are already being exploited that comes with the companion plugin for our service.

If you are using a plugin that isn’t being supported by the developer anymore, over at our main website we offer a service for taking over abandoned WordPress plugins, which includes doing a security review of it.

22 Sep

Vulnerability Details: PHP Object Injection Vulnerability in Appointments

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Since June we have been doing proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. So far that has lead to identifying a couple of dozen vulnerabilities. For the third time it has lead to identifying a PHP object injection vulnerability being fixed in a plugin, this time in the plugin Appointments.

In this instance though what we also noticed was that the new version of the plugin put out to fix the vulnerability still contained the vulnerable code, though it is not accessible through the plugin. What makes that situation stand out is that two companies that put out WordPress security plugins were involved in fixing this vulnerability and appear to have missed that remaining vulnerable code.

In version 2.2.2 of the plugin, two lines that pass the value of cookies to the maybe_unserialize() function, which would have permitted to PHP objection to occur, were removed. They are the following lines in the file /includes/class-app-sessions.php:

$apps = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments'] ) );
$data = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments_userdata'] ) );

Our monitoring picked up their removal, but at the same time that picked up the following two lines in the file being included in the file /includes/class_app_shortcodes.php in that version:

$apps = unserialize( stripslashes( $_COOKIE["wpmudev_appointments"] ) );
$data = unserialize( stripslashes( $_COOKIE["wpmudev_appointments_userdata"] ) );

Those are almost exactly the same as the first two. With the only difference being use of the WordPress function maybe_unserialize() versus the PHP function unserialize() and single quotes versus double quotes.

In looking over the situation we found that the file /includes/class_app_shortcodes.php wasn’t being used, what looks to have happened is that the contents of that file were split in to different files and then that file was never removed.

This risk of that vulnerable code is limited since on its own the file can’t do anything. The risks we could think of is if someone was able to use some other code to cause this file to be loaded or that someone might reuse the vulnerable code from this file. The latter is something we recently saw happen with another plugin, though in that case the code was being utilized in the plugin it was copied from.

When the vulnerability existed in the plugin it was exploitable through several locations, including on pages using several shortcodes.

Security Companies Missed the Remaining Vulnerable Code

Normally a developer missing other instances where vulnerable code is still in the plugin isn’t something that we would be too concerned about, but in this case the developer is WPMU DEV, which also makes the Defender security plugin. We would expect that a company that provides a security plugin to be more careful about the security of their plugins.

In a look over how they promote that security plugin we didn’t get the feeling that they really have the level of concern for security that they should have when producing a security plugin. No where do they present any evidence of the effectiveness of the plugin overall or the effectiveness of its various features. One area where we know that what they are providing has limitations, is their checking for known vulnerabilities in plugins, as the source of plugin vulnerability data is WPScan Vulnerability Database, which has serious limitations, as we have discussed in previous posts. They really should be disclosing the source of the data in the marketing material and making it clear that the data they provide has serious limitations.

Something else that stuck out to us in how the plugin is promoted is this:

Brute force attacks are no match for Defender. Limit login attempts to stop users trying to guess passwords. Permanently ban IPs or trigger a timed lockout after a set number of failed login attempts.

Brute force attacks against WordPress admin passwords are not happening, what is happening, dictionary attacks, can be prevented by simply using a strong password, which WordPress does a good job of helping to people use. Protections meant to protect against brute force attacks would not always be effective against dictionary attacks and can lead to unnecessary complications.

In the changelog for version 2.2.2, one the entries seemed to be possibly referring to this vulnerability:

  • Fixed security issue (vulnerability) with data stored on a browser. Thanks to Matt Barry @ Wordfence

When we contacted the developer of the plugin about the remaining vulnerable code, they confirmed that did in fact refer to this vulnerability.

That Wordfence missed the remaining vulnerable code isn’t all that surprising based on their track record. Last year they disclosed several vulnerabilities in plugins and we found that three related vulnerabilities had not been fixed. The problem then wasn’t as much that they missed them, but that they were not providing the normal level of detail on the vulnerabilities they found that would have allowed someone to check things over and spot those related issues easily. Their providing limited details was not due to a concern about that being misused, but so they could market that they provided protection against the vulnerabilities that other firewall providers did not. In explaining why they were handling things they way they did they claimed that “At Wordfence the security of our customers and the greater WordPress community is of paramount importance to us.”,  which seems untrue when you consider that it was only because we figured out the details they didn’t provide that we could work to get the other vulnerabilities fixed. If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

File Removed

After we notified the developer of the remaining issue, the file /includes/class_app_shortcodes.php was removed. If you already updated to version 2.2.2 though you will still have the file. In normal circumstances that is harmless, but if you want to be extra careful you could delete the file or reinstall the plugin to get rid of the file.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “wpmudev_appointments_userdata” to “O:20:”php_object_injection”:0:{}” and then when you visit a page with the shortcode “app_confirmation” (with a “title” attribute) the message “PHP object injection has occurred.” will be shown.

15 Sep

Wordfence Security Causing Full Path Disclosure Security Issue on Some Websites

Earlier this week we mentioned our concern over Wordfence promoting being reliant on their plugin instead of getting behind an effort to make WordPress more secure for everyone that uses it. We also noted that the average WordPress website shouldn’t even need a security plugin if security of WordPress was being handled properly, which should be the goal. The most important reason that the average WordPress websites shouldn’t need a security plugin is because WordPress should be secure out of the box for most usage of it, but there are additional reasons. One other reason is that security plugins, as is true of any plugin, can introduce security issues of their own, so if you add one (or more than one) you are introducing additional risk.

That isn’t a theoretical threat, last year we found that a security vulnerability in the current version of security plugin was being exploited. We recently disclosed that there is a PHP object injection vulnerability, which is a type of vulnerability that has been widely exploited in WordPress plugins, in the current version of another security plugin.

As part of our monitoring the WordPress Support Forum for information on vulnerabilities in plugins we came across a mention of a less serious issue that involves the most popular security plugin, Wordfence Security.

A forum poster by the name of David wrote:

See: https://www.exploit-db.com/ghdb/4544/

By default a user.ini file is created and contains the root path of the site on the server. This could allow hackers to more easily attempt a directory traversal type attack.

We checked and confirmed that there are websites where the full path for the website is disclosed in that file in a line added it to by Wordfence Security. The linked page includes a Google Dork for searching for impacted websites. Using that we got 13 pages of results (with up to 10 results per page) and with omitted results included 24 pages. Since Google could only show files where they somehow found a link to the file, there are probably many more websites where this file is viewable.

The full path alone won’t allow you to hack a website, but it could assist in some types of attacks. For example, certain vulnerabilities require knowing the full path to a file to take an action with the file, so the full path would assist in exploiting that. Also, for cPanel based websites the path contains the cPanel username, which could assist an attacker in certain instances, say if someone uses the same password across various websites.

What concerned us more was part of the response from a WordPress Wordfence representative:

The .user.ini file is created during the Firewall Optimization process. At the same time as the .user.ini is created code is added in .htaccess which prevents access to the .user.ini.

WordPress is supported on web servers that don’t use .htaccess files, which is something a company focused on WordPress security should know. But in reviewing things we found that Wordfence is aware of this. Looking over the plugin’s code, it has a warning for NGINX users that they should add code to the nginx.conf file to prevent the file in question from being viewable. We didn’t see anything similar for IIS in the code, but that is not officially supported by Wordfence.

In looking over the first 20 results in Google for the Google Dork provided in the link in the first message, we found that 11 of the websites were on NGINX servers, 7 on Apache HTTP servers, and 2 were on servers that were not accessible. Considering that NGINX is used on less websites than Apache HTTP server that seems to indicate that some of the issue is caused by people not adding the code to the nginx.conf file.

If you are using Wordfence Security you can easily check if you are impacted by this by requesting the file .user.ini at the root of your WordPress installation. So for example, if the homepage of your WordPress installation was at http://www.example.com, you would request http://www.example.com/.user.ini .

13 Sep

Wordfence Would Rather Promote Their Plugin Than Address Important Issues Putting WordPress Websites at Risk

When it comes to improving the security of WordPress it often times seems that security companies more interested in promoting themselves than actually improving security. One company that comes to mind is Wordfence, so it wasn’t surprising to see when they discussed the recent malicious takeover of the Display Widgets plugin it was devoid of any discussion of the real problems this situation highlighted and that need to be fixed, instead it was largely a rather explicit ad for people being reliant on their plugin, when the average WordPress website shouldn’t even need any security plugin if security was being handled right.

Advertising over Proper Security of WordPress

It only takes getting to third paragraph to get to them promoting their plugin:

Wordfence warns you if you are using a plugin that has been removed from the repository. During the past months you would have been warned several times that this plugin has been removed with a ‘critical’ level warning that looks like this:

Further in the post is a whole section promoting how they warn:

The last part of that stands out:

I’m incredibly proud that our team took the initiative and got this feature released in June of this year, just in time to save many of our free and paid customers from being affected by this malicious plugin.

What is striking is while they believe that is so important, they don’t even suggest that this capability should be in WordPress itself. That is something that we have been trying to get to happen for over 5 years. It would be great if Wordfence would get behind that effort instead trying to get people reliant on their plugin. If a security feature is truly needed for the average website, it shouldn’t require an additional plugin or service since that will leave a lot of websites insecure. Of course if your plugin already has 2+ million active installs, you probably don’t have an incentive to make sure WordPress is properly secured since it would negate a lot of the people needing your plugin.

You don’t have to take our word that they want people reliant on their plugin, here is another part of the post where they explicitly say this:

As I mentioned in the introduction, Wordfence would have warned you each time this plugin was removed from the repository. It is important that you have Wordfence installed and have your email alerts configured.

In another section they say knowing that plugins have been removed is part of being “on top of security”:

I would also ask you to not start any witch hunts. I’m sure some folks are angry about what transpired here, but things happen and if you were on top of security, you would have been notified that the plugin was removed from the repository and you would have removed it from your site.

Getting back to that previous section, not surprisingly coming from Wordfence, the rest of what they are saying isn’t really true. The users of their plugin were only warned that the plugin had been removed after it was removed from the Plugin Directory, which means even if they removed it immediately they would have still been affected. But it you look at the second quote there, that person had kept the plugin installed after Wordfence warned about it being removed multiple times.

Seeing as plugins are removed from the Plugin Directory for various reasons, removing a plugin from a website immediately just because it was removed from the Plugin Directory is less than ideal. For example, if a plugin is removed because the developer is no longer supporting it, while you would probably want to move away from it, you wouldn’t have need to do that immediately. This would be another reason for having WordPress notify people, as they would know why it was removed.

Any protection that Wordfence provided was not based on anything they did beyond adding a feature (years after they should have), which brings us to what else is missing from their post.

Those Who Don’t Learn From History are Doomed to Repeat it

One constant in security is change; you have to continually review what is happening and adjust. For example, with our service that has meant an increasing focus of PHP objection vulnerabilities as those became a popular target for hackers. That has lead to us identifying and helping to get many of those fixed before they are exploited on a large scale (and hopefully before they were ever exploited).

When it comes to this situation, Wordfence doesn’t take anything close to a critical look as to what happened on the WordPress side of things. That is particularity striking since they are claiming that how you would have protected yourself from this would be by removing the plugin after it was removed from the Plugin Directory, which has to be done by someone on the WordPress side of things.

The reality here is things did not go right and there isn’t good reason to believe that they will get corrected when they involve issues that have been known for some time and when those in the security industry are more interested in promoting their products and services over even touching on them.

The start of the problems with this plugin are not something we would fault anyone other than the person that took it over. Unlike Wordfence we never mentioned who previously owned it, because that seemed rather irrelevant to what happened after they sold it.

Depending on how ownership is transferred it isn’t necessarily possible to determine if it has been transferred without someone involved publicly disclosing it. It might make sense to provide a process where people could indicate they are transferring ownership, which could provide better insight if something goes wrong, but it would be limited, since someone with malicious intentions would probably try to avoid that happening.

It also is would be very difficult to spot someone first adding malicious code to a plugin if they want to hide what they are doing. The proactive monitoring of changes made to plugins that we do uses checks based in part on previous instances of intentionally (and possibly intentionally) malicious code, but so far we haven’t found anything added this time that we think it would make sense to look for.

Where the fault starts is after the first version by the new owner, which would request a zip file from a remote location and loads code from it on the website. That not only violated the developer guidelines for WordPress plugins, but should have raised serious red flags because even what was presented as the legitimate usage of the files added, which was tracking anyone accessing a website using the plugin, has been the kind of thing that has been done with other software when it has been taken over by bad actors.

Let’s go the timeline included in the Wordfence post for what happened with the next release of the plugin following that occurring:

Then on June 30th, 7 days later, the developer released version 2.6.1 of the plugin. This release contained a file called geolocation.php which, no one realized at the time, contained malicious code

The last part is in red in original, so it is really being highlighted. What is never addressed in the Wordfence post is if someone should realized that it contained malicious code. In our looking over the code in that version, based on what was in the previous version it seems like it should have at least raised questions about what is going on. We believe if those questions were asked of the developer the plugin would not have returned. This incident seems like it should be a wakeup call that how things have been has not been working, but if security companies won’t say that, it is less likely to happen.

Changes don’t have to just rely on people on the WordPress side of things. One idea we had mentioned in that post, is that when a vulnerability is fixed in a plugin that there should be a capability for others outside of the WordPress team to be provided information needed to look over what happened and what the fix was, which could also apply for other security issues. That would provide a better chance of things like what happened here being caught. That seems like a really good idea especially when you consider that not only do we frequently find that vulnerability that were supposed to have been fixed haven’t been, but we have specifically found that has occurred with plugins that have been removed from the Plugin Directory.

On July 23rd, Calvin Ngan opened a Trac ticket reporting that Display Widgets was injecting spammy content into his website. He included a link to Google results that had indexed the spam and said the malicious code is in geolocation.php.

On the 24th of July the WordPress.org plugin team removed Display Widgets from the plugin repository for a third time.

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

On September 7th a forum user on WordPress.org reports that spam has been injected into their website on the Display Widgets plugin support forum.

There is something missing in the timeline that seems important. As we mentioned in one of our posts the information provided in what is linked to for July 23 shows what the malicious code in the plugin was being used for, but also where the malicious code was. Yet the plugin returned at some point before September 7th (Google caching shows it had been returned by at least September 5, but it could have occurred long before that). How did the plugin get returned when it should have been clear that there was malicious code in it?

Accuracy Issues

One of the other problems we often see with things put out by Wordfence is they make claims that are not accurate, which hasn’t so far caused others to have the level of scrutiny of their claims they should receive. The claims are sometimes rather serious, such as a recent claim that a plugin was under attack. There is a glaring one in the timeline, though less serious one, in this post, which we mention, because, as we just said, people should be much more careful before believing or repeating claims made by Wordfence. Here is the first mention of it:

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

That links doesn’t work anymore; here is a link to the same thing that still works.

They make it again here:

The 2.6.3 release of their plugin makes a minor modification to the malicious code in geolocation.php to fix a bug in the code that lets the plugin author list the malicious posts they have published on your site.

The change they are referring to occurred in version, not 2.6.3. The only change made in version 2.6.3 was to fix a supposed vulnerability, which didn’t exist. That seems like it could be an important element to what happened here, but goes unmentioned in Wordfence’s post for some reason.

Update 9/18: After looking at an article at the Threatpost that sourced most of its information from Wordfence’s post, we noticed a more problematic issue related to this inaccuracy. Wordfence inaccurately stated the that versions up to 2.6.3 were contained malicious code:

Actually, the backdoor exists on any site running versions 2.6.1 to version 2.6.3 of the plugin.

Version, which Worfdence never mentioned, also contained malicious code.

01 Sep

SiteLock, Kasperky Lab, and Wordfence Mislead Public on Threat from Vulnerability in WordPress Plugin

Yesterday over at our main blog we noted how the web security company SiteLock and their web hosting partner 123 Reg, a GoDaddy brand, are making baseless claims as to the likelihood of websites being hacked to try scare customers in to purchasing SiteLock security services. In the meantime they and others in the security industry were also taking a minor security vulnerability discovered by SiteLock in a WordPress plugin that is used with WooCommerce and using misleading information to make it sound like a much bigger threat.

To see what happened let’s start with an article on the Threatpost, which is Kaspersky Lab’s news website. The article is titled Reflected XSS Bug Patched in Popular WooCommerce WordPress Plugin. No where in the post is there anything to backup up the claim this plugin is all that popular, instead the article makes a confusing mention of the claimed usage of WooCommerce:

An extension of the WooCommerce WordPress plugin, used by 28 percent of all online stores, has been patched against a reflected cross-site scripting vulnerability.

In the ranking of plugins available for sale through the WooCommerce Extension Store, the plugin is the 45th most popular plugin.

What is important to note is that is the risk from a vulnerability has little to do with its popularity, but instead is largely based on the type of vulnerability. As we will get to in a little bit, this type of vulnerability is not one that is a major concern due to not being likely to be exploited.

The focus on usage wasn’t just something that author at the Threatpost was focused on, SiteLock tried to find it out for the “purposes of accurate impact disclosure”, despite that not being a major factor in the impact.

Next up in inaccurate information in the post is this:

“At the time of discovery it was a zero day on the current version,” said Logan Kipp, WordPress evangelist for security vendor SiteLock. “If this was discovered by someone else, it could have been a real problem.”

A zero-day vulnerability is one that is being exploited before the developer is aware of it; it isn’t just a vulnerability that has yet to be fixed. Real zero-day vulnerabilities are very serious issue since keeping your software up to date won’t protect you against them at first, which seems to have lead to many in the security industry to use the term incorrectly.

The next section makes the vulnerability sound really concerning:

“Theoretically, this is weaponizable by sending a crafted link to any party who has a set of logins on that website,” Kipp said. “And if they have an active session, you could hijack that session.”

An attacker could email that crafted link to an already established vendor on a site running WooCommerce. If the vendor is logged in and clicks on the link, an attacker could capture the session and run scripts on the vendor’s browser, taking control of any functionality they have, Kipp explained.

“The chances are very high that if they are the webmaster, they’re going to be logged in at the time of clicking the link and they’re going to have very high privileges,” Kipp said. Kipp characterizes XSS as a tool to gain higher privileges.

“It’s a means to go further, a foothold,” he said. “So while in itself it may not cause any direct damage to the website, we could potentially gain administrator privileges by hijacking sessions.”

The keyword there though is theoretical, because we just don’t see reflected cross-site scripting (XSS) vulnerabilities being exploited against the average website at this time. That could change at some point and it is possible that it could be used in a targeted attack.

What isn’t mentioned in any way in that article or SiteLock’s own article about this and is a possible partial explanation why you don’t seem much targeting of this type of vulnerability, all of the major webs browsers other than Firefox have protection against this type of vulnerability through XSS filtering. So to exploit them you would have to hope the exploitee was using Firefox or come up with a way around the protection provided by the web browser (or multiple ones to get around different protection in different web browsers).

If the SiteLock employee had left their comments with the above it would have been accurate, but they didn’t:

“A lot of times it’s overlooked because people don’t take it seriously. It’s a huge problem because folks don’t always grasp that maybe it can’t modify the website itself, but this is a perfectly weaponizable vector to target visitors,” he said.

This type of vulnerability isn’t a huge problem since it is unlikely to be exploited and isn’t a perfectly weaponizable vector.

Wordfence Jumps in

In what shouldn’t be surprising to anyone that is mildly familiar with the WordPress focused security company Wordfence, in their coverage of this vulnerability they passed along to their readers inaccurate information. Here is the first paragraph:

A reflected cross site scripting vulnerability has been reported in a premium WordPress plugin for WooCommerce known as the ‘Product Vendors‘ plugin. This plugin is used by 28% of all online WooCommerce stores.

As mentioned earlier the 28% really refers to claimed usage of WooCommerce, not usage of the plugin.

Further in to the post they make the claim that vulnerability “will be exploited”, despite the fact that there is very little likelihood of that:

If you are running an older version of the Product Vendors plugin, it is important that you upgrade immediately to avoid having your site exploited. This vulnerability is now public and will be exploited by attackers.

While they make a claim that their plugin will protect against this type of vulnerability (without providing any evidence), they make no mention that web browsers provide protection:

If you are using Wordfence it is unlikely that your site is exploitable because Wordfence includes advanced XSS protection for our free and paid customers.

Also worth noting is that they make no mention that SiteLock discovered the vulnerability, which seems to be in rather bad form.

Overall it looks like Wordfence saw this as a way to market their service and either they don’t have the capability to provide accurate information when it comes to security or they intentionally are misleading people. Based on everything we have seen from them, either seems possible, which doesn’t speak well to the state of WordPress security when you consider they are the company behind the most popular security plugin.

Why This is a Problem

When you strip out the false information included in the articles the problem with this type of coverage of vulnerabilities can be seen in another part of the Wordfence article:

Product Vendors version 2.0.35 is affected by the vulnerability. If you are using this plugin, you need to upgrade immediately to at least version 2.0.36, which includes the fix. The current version of Product Vendors is 2.0.40.

In the Product Vendors changelog, they do not mention that a vulnerability was fixed. The changelog entry for 2.0.36 simply says:

2017-07-28 – version 2.0.36
* Fix – Adjusts how we handle the vendor registration form validation.  

The takeaway from that should be that you should be keeping you plugins up to date at all times, since if this vulnerability was as serious as these security companies make it sound you would have left your website insecure for over a month if you relied on them telling you to update it instead of just updating it. Wordfence doesn’t seem to understand the importance of keeping plugins up to date seeing as they are not telling people they need to update to the latest version of the plugin despite knowing that they were unaware until a month after the fact that the version they are telling people to update to now, contained a security update.

The situation get worse when you consider that many more serious vulnerabilities don’t get covered. For example, we haven’t seen coverage of a real zero-day vulnerability in the plugin Asgaros Forum that was being exploited a couple of weeks ago. What also doesn’t get much coverage are vulnerabilities that haven’t been fixed, which are ones that could use news coverage because simply keeping your plugins update to date won’t protect you. As an example of that, on Tuesday we disclosed that a PHP object injection vulnerability, which is one that is much more likely to be exploited than a reflected XSS vulnerability, exists in the current version of a security plugin with 6,000+ active installs.

11 Aug

Wordfence Unnecessarily Scares Public by Including Non-Existent Threat Against Plugin in Their WordPress Attack Report

Unfortunately much of the security industry doesn’t seem to have interest in being responsible when it comes to security information they put out, instead they throw out information without regards to accuracy, often causing the public to be concerned about non-threats (while real threats go under focused).

A case in point of this is something we just looked into involving Wordfence and their The July 2017 WordPress Attack Report. The report is rather inaccurate, for example there is a whole section on brute force attacks, despite those not occurring. But what brought our attention to the report was a thread on the WordPress Support Forum that came up in our monitoring of that for mentions of vulnerabilities in plugins. The person that started the thread had deactivated the plugin WP-PageNavi due Wordfence’s claim about the plugin in the report:

We looked into the details of the biggest mover on the list, ‘wp-pagenavi’, which moved up 38 spots to number 11. The surge in attacks are attempting to exploit the TimThumb vulnerability we discussed in the theme section. We couldn’t find reference to the plugin including TimThumb, but given that the TimThumb vulnerability in question is over 5 years old now it would be difficult to say for sure.

We don’t understand why Wordfence is saying that it would be difficult to say if the plugin used TimThumb, seeing as the plugin is available in the Plugin Directory and therefore all the versions that have been available through that are still viewable through the Subversion repository that stores the plugins. This certainly wouldn’t even be the first recent instance where Wordfence didn’t appear to have done proper due diligence before making a claim.

The developer of the plugin responded in the thread this way:

It is a popular plugin and I am not surprised. The plugin has NEVER use TimThumb before and as far as I know, there is no vulnerability being reported to me.

In looking at the logs of several our website going back through the beginning of July we saw 0 requests for anything files from that plugin. If there was a large scale attempt to exploit something in that plugin there would have been, as there has been for every other large scale attempt to exploit a plugin in at least the recent past. So it looks like their list of the most exploited plugins is including many things that are not receiving significant exploitation attempts (considering that based on past experience Wordfence isn’t even aware of many plugin vulnerabilities that are being targeted they probably are missing vulnerabilities that should be listed).

Looking at one of the websites we monitor to help keep track of what plugin vulnerabilities are being targeted, abuseipdb.com, we found the start of what might explain what is going on here. One of the pages on that website showed a request to a file within the directory of WP-PageNavi that happened in May:


That file hasn’t actually existed in WP-PageNavi though. So why send a request there? One explanation could be that a hacker plants a backdoor file in that location on hacked websites and someone was sending a request hoping the file was there. In this case though that seems unlikely because it does look like an attempt to exploit the vulnerability that had existed years ago in the TimThumb script.

Doing a search for “/wp-pagenavi/inc/thumb.php” for brought us to a page that lists location where the TimThumb script was supposed to have been in various software. It lists multiple locations in this plugin:


The directory structure there isn’t even right in that (it should start “wp-content/plugins”) and the TimThumb file wouldn’t be in all those locations in a plugin, but it does point to there having been a belief that the TimThumb script had been in this plugin.

So what looks to be going on here is that Wordfence is seeing attempts to exploit a vulnerability that hasn’t really existed (those are not all that uncommon) and they either don’t understand that or don’t care and included it in their data. That leads to people reading their report to falsely think that there has been a vulnerability that is being targeted by hackers in the plugin WP-PageNavi, when there hasn’t. Assuming that is true, Wordfence is being highly irresponsible here and they should stop putting out those reports until they can take the time to put out accurate information because as thread on WordPress Support Forum show this misleading data is causing the public to take unneeded action.

07 Jul

Wordfence’s Lack of Understanding of SQL Injection Vulnerabilities Leads to False Claim About WP Statistics Vulnerability

Yesterday we touched on how the web security company Sucuri and others in the security community were overstating the threat of a vulnerability recently discovered by Sucuri in the plugin WP Statistics. While looking over something else related to that vulnerability we came across the web security company Wordfence using that vulnerability basically as an ad for their products and services, while reminding people that are actually knowledgeable  about web security that Wordfence really don’t have a good grasp of it.

Their post starts out:

It’s been a tough week for the WP Statistics plugin. Last Friday, Sucuri (now owned by GoDaddy) discovered a SQL injection vulnerability in the WP Statistics plugin version 12.0.7 and older. To exploit the vulnerability, an attacker needs to register an account (or use a compromised account) with subscriber-level access. They can then exploit a weakness in a WP Statistics shortcode to launch a SQL injection attack. This allows them to, for example, create an admin-level user and sign in to your website as an admin.

The vulnerability doesn’t allow someone to create an admin-level user, which is something that Wordfence should know considering shortly after that in the post they tout their plugin will protect against SQL injection vulnerabilities. If you don’t understand the basics of them, then you are not likely to be good at protecting against them.

They certainly shouldn’t be out there making claims that are false like this, but considering this company even goes to the level of claiming they care more about security than WordPress while making up a threat, it really isn’t surprising.

This isn’t all that complicated, here are the vulnerable lines of code in the plugin (as identified by Sucuri):

switch ( $time ) {
case 'today':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d' )}' AND {$search_query}" );
case 'yesterday':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -1 )}' AND {$search_query}" );
case 'week':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -7 )}' AND {$search_query}" );
case 'month':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -30 )}' AND {$search_query}" );
case 'year':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -365 )}' AND {$search_query}" );
case 'total':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE {$search_query}" );
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', $time)}' AND {$search_query}" );

In that code the value of the variable $search_query, which contains user input, is used in used in multiple SQL statements without being sanitized. The important part here is that the SQL statements are SELECT statements which allow reading data from a database, they don’t allow insert anything, so you can’t add admin user or anything else (the INSERT statement would be used to insert data). What you could do is slowly read out the contents of the database, which isn’t something that we see any evidence of hackers doing against the average website (it could be used in a targeted attack).

Wordfence Fails To Mention Many Plugin Vulnerabilities

While Wordfence’s post titled a “Vulnerability Roundup” they only mentioned vulnerabilities disclosed recently in two other plugins, both of which were already fixed, while not mentioning any of the  numerous vulnerabilities in plugins that were recently disclosed that haven’t been fixed. Telling someone to update a plugin that already has been fixed is really not all that helpful, since what you really should be telling people is to keep all of their plugins up to date at all times. When vulnerabilities haven’t been fixed that is when it would be useful to make people aware of the issue. As example of Wordfence of not warning about those unfixed vulnerabilities, here are just the vulnerabilities that we disclosed last week that haven’t been fixed:

If you used our service you would know about those vulnerabilities and many others that remain unfixed, including many that are likely to be exploited.