Tag: Wordfence

Wordfence Continues To Peddle False Claim of Brute Force Attacks To Push Plugin That Doesn’t Protect Against Real Threat

When it comes to improving security of websites one of the problems we see is that real issues do not receive the attention they should, while other issues, that are of little to no concern, do get attention. Often times it is security companies that play an important role in this happening, when they should be helping to push against this.

When it comes the security of WordPress websites one of the big problems that exists is that vulnerabilities in plugins that are being exploited do not always get fixed in a timely manner or in some cases ever. A recent example of that comes with an arbitrary file upload vulnerability that exist in the most recent version in the plugin Delete All Comments. Through that vulnerability a hacker could upload files of their choosing and then do almost anything they want with the website. The security company NinTechNet spotted the vulnerability while cleaning up a website was hacked through it on November 20. They notified the developer, but received no response from them (one possible explanation for the vulnerability being in the plugin is that it was actually intentional put in the plugin, though it could just as easily be unintentional).

NinTechNet then notified the Plugin Directory and the plugin was removed from that. That prevents anyone not using the plugin already from installing and making themselves vulnerable, but what happens for the 30,000+ websites that already were using it according to wordpress.org? Nothing. The people running those websites are left unaware that their website is open to be exploited. Amazingly this isn’t because no one had brought up this issue. We raised it back in March of 2012. Shortly after that we proposed on the Ideas section of the WordPress website that people be alerted people when their websites are using plugins that have been removed from the Plugin Directory and providing at least general reason why it was removed. Shortly afterwords it was marked as “Good idea! We’re working on it” and it was stated that it was being worked on. By six months ago the same person said:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

Strangely the idea is still marked as “Good idea! We’re working on it”, which keeps it from being listed on prominently on front page of Ideas section (where it would be tied for the second most popular idea that hasn’t been greenlit and where more people would see that the issue is being left unaddressed).

There is another option, the Plugin Directory can put out a fixed version when the developers doesn’t do that, but they rarely do that, don’t seem to have provided any sort of public criteria on when they would do that, and someone on the WordPress side even deleted a comment we made in regards to the issue at one point.

In the meantime if you install the companion plugin for our Plugin Vulnerabilities service you get warned in situation like this as we include information on vulnerabilities that looked to be being exploited to the free data included with that (last week we also added data on vulnerabilities that look to being exploited in the current version of a plugin with 40,000+ installs and another with 20,000+ active installs).

If these got more public attention we have hard time believing that WordPress would continue to leave people vulnerable, but that is the situation we and everyone else is dealing with until such time.

If you are thinking that a security plugin would protect against this type of thing, think again. We tested the ability of 15 security plugins to prevent exploitation of the vulnerability in Delete All Comments last week and found that none of them stopped it.

One of those plugins that didn’t stop it was Wordfence, a plugin with 1+ million active installs, which is describe on the its main page on the Plugin Directory thusly:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

That unqualified claim is that it stops from you getting hacked is clearly false as not only that test against the vulnerability in Delete All Comments shows. In three other tests we have done, in either Wordfence provided no protection or the protection was easily bypassed. It is also worth noting that from everything we have seen Wordfence’s Threat Defense Feed misses many plugin vulnerabilities.

So how do you get over 1 million installations of plugin that doesn’t actually do what it claims to do. Well what appears to be an important role in that is that Wordfence simply makes up threats and then claims to protect against them.

Brute Force Attacks Are Not Happening

Take for instance last Friday when they put out a post “Huge Increase in Brute Force Attacks in December and What to Do“, which claimed:

At Wordfence we constantly monitor the WordPress attack landscape in real-time. Three weeks ago, on November 24th, we started seeing a rise in brute force attacks. As a reminder, a brute force attack is one that tries to guess your username and password to sign into your WordPress website.

Of course they have the solution for this:

If you install the free version of Wordfence, you are automatically protected against brute force attacks. It’s that simple. We also automatically block the worst offenders completely, and we share some information below on who those are.

There is just one problem with all of that, brute force attacks against WordPress admin logins are not actually happening. Back when we originally discussed the fact that security companies are falsely telling people brute force attacks are happening in August we used as an example from Wordfence in January, so Wordfence has been using this falsehood to push their product for some time.

We wrote in that post:

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. 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)

The chart of login attempts in Wordfence post from last week show only millions of login attempts per day:

It would take a long time for that to get to the amount needed for a brute force attack, but wait, those are not against one website, those are across hundreds of thousands of websites:

So we are talking about an average of 10s of attempts per website, which is never going to amount to a brute force attack.

So what is actually going on? Well based on the number of attempts and by looking at what username/password combinations were used in actual malicious login attempts it looks like most of these are actually dictionary attacks. A dictionary attack involves trying to log in using common passwords.

Knowing what type of attack is important because how you prevent them and the level concern you should have is very different for different types. With what is actually happening, dictionary attacks, all you need to protect yourself is to use a strong password, otherwise you can simply ignore this.

That might explain why Wordfence is misleading people, if they told people the truth they wouldn’t be a need for them to install their plugin (and then possibly sign up for Wordfence’s paid service). The other possibility, which seems just as likely based on what else we have seen, is Wordfence simply doesn’t have a good understanding of security. That could also explain why they don’t understand why it is inappropriate to make an unqualified claim that their plugin “stops you from getting hacked” when that would that would be able to truly stop any hack is next to impossible.

If you look at the comments on Wordfence’s recent post you can see they have successfully mislead a lot of people into believing their false claim, which makes it even harder to get people to focus on real issues and that means more websites are going to get hacked that should not have.

Wordfence Using Outdated and Insecure Software on Their Website

When it comes to the security of websites what we see is that basic security measures are often not being taken with websites, while security companies push additional security measures without evidence that they provide better protection than doing the basics or in addition to doing the basics. Considering how bad the security industry is, it probably isn’t surprising to hear that we have repeatedly found that security companies themselves are not doing the basics, while pushing additional security measures.

Back in October we looked at one cyber security company that claimed to have “clients in the intelligence community, DoD and nearly every cabinet agency” that wasn’t keeping the WordPress and Drupal installations on their websites up to date, while telling people that they doing the additional security step of vulnerability scanning isn’t enough and that they need penetration testing done as well (which not surprisingly they offer). From what we have seen it looks like a lot of penetration testing largely involves running automated tools that try exploit known vulnerabilities in software, which usually would not exist if you are keeping your software up to date.

In November we looked at a couple of other cyber security companies that had been in news that were also running outdated software on their websites.

Today let’s look at example of this from the WordPress security world, which shouldn’t be all that surprising if you follow our blog. In the past we have mentioned the security company Wordfence in regards to their scary lack of security knowledge and pushing the falsehood of of brute force attacks against WordPress admin logins (which they are still pushing).

Over at the blog for our Plugin Vulnerabilities service today we looked another instance where Wordfence’s very popular security plugin failed to prevent exploitation of a plugin vulnerability (the 14 other security plugins we tested also failed to prevent exploitation), this vulnerability is one that you can’t protect yourself against by keeping your plugins up to date, so it would be something where an additional security measure could actually be useful (the companion plugin for our service has been warning webmasters of that vulnerability since Monday).

While working on that we ran across the Wordfence Official Documentation portion of Wordfence’s website and noticed they are running an outdated and insecure version of MediaWiki on that:

Both versions 1.23.14, release in May, and 1.23.15, released in August, contain a number of security fixes.

It’s Scary How Little Wordfence Knows About Security

If you follow the news what seem pretty clear is that cybersecurity is not in good shape these days, whether it’s major credit card breaches at retailers or hacks of high profile organizations, clearly something is very wrong. It seems unlikely that is due to a lack of spending on security products and services, consider that estimates of yearly spending on cybersecurity are in the 10s of billions of dollars and expected to continue to rise. Instead part of the explanation is that much of that money is being spent on products and services from companies that know and or care little about security.

To give you one example, anti-virus software from well known companies Kaspersky Lab, Norton, McAfee, Sophos, and Trend Micro all were found by Google researcher Tavis Ormandy to have had exploitable vulnerabilities in them. When you have to be concerned that security products are increasing your security risk that indicates something is quite wrong. But what is more striking about those vulnerabilities is the ease of exploiting some of these and that they were due in part to the companies doing dumb things. For example, in the case of Norton, quite of few of their products, including enterprise products, were subject to a remote code execution vulnerability that could be exploited by sending an email (it wouldn’t have had to be opened) that was due in part to running code at a higher privilege level than was have been needed.

As we have ramped up our Plugin Vulnerabilities service for keeping track of vulnerabilities in WordPress plugins, we have run across more of what WordPress security companies are up to and what is seen is that are not the exception when it comes to the poor state of security companies. One such example is Wordfence, we have frequently seen things that showed they either didn’t know or care much about security.

What we have wondered for some time though, is it more that they don’t know about security or if they just don’t care about it. To see why that is, take their involvement in the widespread claim that brute force attacks against WordPress admin password are occurring, despite the fact the evidence from Wordfence and other security companies actual shows that they are not. Does Wordfence had no clue what they were talking about or do they know they were telling people a falsehood to help push their product and service, seeing as those wouldn’t be needed if people knew what the malicious login attempts falsely being labeled as part of brute force attacks were most likely part of, dictionary attacks, which can be protected by simply using a strong password. We really were not sure.

In another example, Wordfence made a bold claim about being able to protect against stored XSS attacks, which we found to be false with some simple testing. In that case it could have either been that they were saying something they knew wasn’t true or it could have been that they understand so little about this type of vulnerability that they didn’t understand what incredible claim they were making and that they needed to be very careful about making it without being sure about the claiming.

We think the latest false information put forward them makes it pretty likely that they are lacking a basic understanding of security, which is frightening since so much of the WordPress community is relying on them for information and protection.

In a post about what they say are the most attack plugin vulnerabilities (worth mentioning here is that we recently found that Wordfence seems to be oblivious to vulnerabilities in plugins that are actually the biggest threat) they made a claim that we and they found out surprising, that many of the vulnerabilities being targeted were local file inclusion (LFI) vulnerabilities:

The large number of local file inclusion vulnerabilities that are being exploited is surprising. I should also note that many of these LFI’s were discovered by Larry Cashdollarwho I had the pleasure of seeing speak at Defcon in Las Vegas 2 weeks ago. So I suspect that many of these are being used in an attack script of some kind which may explain their prevalence in the attacks we’re seeing.

The clustering of LFI’s together and Shell exploits together in the list order is odd, but I don’t have a theory to explain that and there is no error in the data that accounts for that. It appears to be coincidence.

Considering that everything we know from monitoring plugin vulnerabilities and dealing with lots of hacked websites is that this type of vulnerability is rarely targeted, this seemed odd. But a quick look at the data they presented showed a simply explanation, local file inclusion vulnerabilities were not actually be targeted. Instead what was being targeted were what we refer to as arbitrary file viewing vulnerabilities (they are also often referred to arbitrary file download or directory traversal vulnerabilities), which are very different.

Before we get in to what each of those type of vulnerabilities is,  it is worth mentioning that Wordfence really had to go out of their way to get this wrong, as can easily seen by the fact that the first five vulnerabilities they listed as being local file inclusion vulnerabilities are actually listed in the linked to advisories as being the following types of vulnerabilities:

Not one of those is listed as listed local file inclusion vulnerability, so Wordfence must have thought they were all wrong.

A local file inclusion (LFI) vulnerability allows an attacker to include a file that exists on the file system of the server the website is on (a remote file inclusion (RFI) vulnerability allows the same with a file that exists somewhere else). For this type of vulnerability to useful to a hacker they either need to be able to place a file on the website or there needs to be a file thats inclusion in this way causing a security issue. Since those do not appear to be readily available in most cases it follow that this type of vulnerability is not often being exploited.

An arbitrary file viewing vulnerability allows viewing the contents of a file that exists on the website. With WordPress websites we frequently see attempts to exploit this type of vulnerability to view the contents of the wp-config.php file. If successful that would provide the attacker with the database credentials associated with the website. For that to be useful the attacker would need to be able to connect to the database, their ability to do that varies greatly depending on the hosting setup. While we see many attempts to exploit this type of vulnerability, we see it being the cause of a website being hacked much less than arbitrary file upload vulnerabilities, which we also see many exploit attempts against.

While Wordfence’s lack of understanding what each of these vulnerabilities would likely has some impact on protecting against them, it would have an even bigger impact on their properly doing hack cleanups (which they also offer) since it greatly helps to understand what security vulnerabilities have existed on the website to determine the source of the hack and the impact the exploitation of a vulnerability could have had.

If you care about security we would recommend you help us get the truth about Wordfence out to a wider audience so that together we can lessen the damage they are doing toward the security of so many websites.

WordPress Disappears Our Response To Post Indicating that Wordfence Premium Failed To Protect Websites From Being Hacked

When it comes to improving the security of WordPress ecosystem one of the things that is desperately needed is better security information. For example, if you were to look at discussions of WordPress security you would likely to believe that there were a lot of attempts to brute force WordPress admin passwords, despite the evidence from the WordPress security companies claiming they are happening showing that those supposed brute force attacks are not happening at all. Unfortunately, one of the parties we have recently found being an impediment to improving security information that is available to the public is WordPress, or more specially, one or more of the people involved in moderating their forums.

Several weeks ago we discussed how someone at WordPress was disappearing some of our posts on the wordpress.org support forum and it has happened again just in the last day. Since one of the threads that had a reply of ours removed, touches on some important security issues that are in need better information, we thought it would be a good idea to discuss it here, especially since someone at WordPress doesn’t want accurate security information related to that to be accessible to people reading their forum for some reason.

One of the things we do to keep track of what plugin vulnerabilities are out there to make sure we provide the best data for our Plugin Vulnerabilities service is to monitor the wordpress.org support forums for threads discusses such issues. In doing that we run into threads discussing an assortment of other security issues, which we sometimes add a response when we can provide some insights based on knowledge of plugin security and hack cleanups of WordPresw website. Yesterday we ran into a thread involving a claim that several websites were hacked due to a third-party library included with WordPress, SWFUpload.

There we several things that stuck out to with this post. One, was that person, who discussing a hack of several of their clients websites, did not appear to have tried to properly determine how the website were hacked, instead they just seem to be guessing that it was caused by SWFUpload:

Now I think I found the hackers method, I believe they used “swfupload”.

Any security scan will not show “swfupload” as a danger because WordPress (foolishly) includes these script files for legacy reasons. Apart from that, the files in folder “swfupload” are not needed for current WordPress installs. These are old files and since they are old they are NO longer updated to stop hackers.

Now that I had 2 client websites hacked and malicious files uploaded, I believe that is the weak spot in WordPress allowing the hacker to gain access.

If that were the source of the hackings there should be evidence of the log files, which their post made no mention of reviewing (despite being a basic part of a hack cleanup). It seems highly unlikely that was the source, since if a hacker were to have discovered a vulnerability that allows hacking websites throughWordPress it is likely they would try to hack as many websites as possible quickly before it was discovered that their was issue since once it was, WordPress could quickly release an automatic update that would protect the vast majority of WordPress websites within a day. Seeing as we haven’t seen any evidence to point to a hack of WordPress itself occurring recently, it seem unlikely that was the source. The first two paragraphs (of total a three) of our response discussed those things:

If there was a known vulnerability that could be exploited like this in the version of SWFUpload included with WordPress it is likely that there would be a lot of websites being hacked through it right now, but we are not seeing any evidence of something like that going on at this point, so it isn’t likely to be the source of your hackings.

What you will want to do is to review the log files for the websites to see what evidence they provide as to the source of the hackings. If SWFUpload was in fact the source then there should be evidence of that in the HTTP log and that evidence would also provide information needed for the WordPress developers to work on fixing it.

The other major thing that stuck out what this person surprise that the website had been hacked while using the Wordfence Premium service:

I had 2 of my client WordPress sites hacked in this past month and they uploaded malicious PHP and JS files to infect the site with a backdoor PHP script. When I found the hacked upload 2 weeks ago in one client’s site, I wondered how did they got into the site while using WordFence Premium?

Should that be surprising? Not to anyone who is actually knowledgable about security, since in reality the various website security products and services out there provide at best limited protection against real threats against websites (and sometimes they actually are the security threat). For example, a WordPress security plugin would have no ability to stop an attacker who gains access to the FTP credentials from accessing the website’s files and in fact if the attacker wanted to they could modify the security plugin to ignore any changes they made to the website.

For Wordfence in particular it wasn’t surprising to us that their service wouldn’t protect a website considering among other thing they are one of the security companies pushing false claims of brute force attacks (while advertising that their service will protect you from them) and that we recently found their claim that their plugin would protect against stored XSS vulnerabilities was not supported when testing real world vulnerabilities against it. When it comes to their paid service, Wordfence Premium, back in June we noted that it was failing to detect vulnerabilities that were being exploited in the current versions of plugins. We concluded our response by mentioning that, since it is relevant for someone thinking that the service would protect them, that said service is oblivious to vulnerabilities that are being exploited and could actual be a cause of the hackings:

Since you brought up Wordfence Premium, it is worth noting that the service looks to have missed detecting exploitation of numerous vulnerabilities that were in the current version of WordPress plugins, so its ability to protect websites against real world threats is at least somewhat limited.

Was someone at WordPress trying to cover up the fact that Wordfence Premium has serious problem in its protection by removing our response, we don’t know, but removing our post had the same effect.

No One Is Trying To Brute Force Your WordPress Admin Password

When it comes to improving the security of the WordPress ecosystem one of the biggest problems we see is the shear amount misleading and often times false information that is put out by security companies. One of the most frequent falsehoods we see is the claim that there are a lot of attempts to brute force WordPress admin password. Not only is the claim false, but is so obviously false that these security companies either don’t understand the basics of security or they are knowingly lying to the public, either of which would be a good reason for you to avoid them.

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. 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)

Now that you have an idea of the number of requests it would take to actually do a brute force attack, lets look at the number of attempts that security companies are claiming are occurring that support their claim that brute force attacks are going on.

First up is Wordfence, back in January they put out a post about the claim that brute force attacks are going on and gave a figure for how many login attempts had occurred over a recent 16 hour period (they call each login attempt an attack):

During this time we saw a total of 6,611,909 attacks targeting 72,532 individual websites. We saw attacks during this time from 8,941 unique IP addresses and the average number of attacks per victim website was 6.26.

The total during that time period likely isn’t any where near enough login attempts for even one brute attack to be successful, but with less 7 attempts per website, that clearly is not evidence of brute force attacks actually occurring.

How about Sucuri Security, they have a page on their website entitled WordPress Brute Force Attacks, that is supposed to present the “state of brute force attacks against WordPress sites”. The graph shown there includes failed login attempts for websites “protected” behind their website firewall. There is an obvious issue with that since failed login attempts are not necessarily malicious, so the graph is not necessarily entirely that accurate. Even with that caveat, the largest amount on one day looks to be have been about 50 million requests:

sucuri-security-brute-force-graph

We don’t know how many websites that is split across, but even if it was one website that likely wouldn’t be nearly enough for one successful brute force attack per day.

In one instance recently, someone we perviously did some work for contacted us because they had gotten an email from Sucuri’s WordPress plugin that was alerting them to brute force attack. In that instance Sucuri was claiming that a brute force attack was occurring based on a total of 30 login attempts.

Security Companies That Don’t Understand the Basics of Security

Back in September of last year Sucuri not only claimed that brute force attacks where happening, but also claimed that brute force attacks are frequent source of hacking (despite the fact that they are not actually happening at at all):

However, brute force attacks are still going strong. In fact, they are one of the leading causes of website compromises.

So what could explain the false claims about brute force attacks?

One explanation is that these security companies don’t have an understanding of the basics of security, like knowing what a brute force attack is. Considering you don’t have to look at some obscure resource to know what they are, you just have to go to the Wikipedia, there isn’t any excuse for that.

The other explanation is that these security companies do know what a brute force attack actually is, but they are lying about them happening since if they told what was actually happening they wouldn’t be able to use it to push the products and services they provide. That would have the added bonus of allowing them to claim they can protect against something, without having to worry about that turning out to not be true (as we recently found with another claimed protection by Wordfence), since the brute force attacks are not actually happening.

Protecting Yourself From the Real Threat, Dictionary Attacks

So based on those security company’s data brute force attacks are not going on, but there are malicious login attempts happening, so what is actually happening? Based on looking at actual login attempts and the number of requests it looks like most of the malicious login attempts are from dictionary attacks.

A dictionary attack involves trying to log in using common passwords, think things like “123456” and “123admin”.

With dictionary attacks protecting your website is really easy, just use a strong password. Thats it. You don’t need to put in place all sorts of other protection, since the dictionary attacks will fail as long as you do that. WordPress now defaults to generating a strong password and displays a password strength indicator if someone chooses to create their own password, so if you have an Administrator choosing to use a weak password, you probably have bigger issues to worry about. If you are concerned about lower level users using weak passwords and then being subject to dictionary attacks, there are a number of options to enforce stronger passwords that are available.

With it being that easy to prevent what is going on, it would be difficult for security companies to promote products and services to deal with this, so that is why we wonder if they are intentionally lying about what is going on.

It also worth noting that there is likely a quite a bit of overlap between the passwords tried during different dictionary attacks, so the amount passwords tried is likely much less than the total attempts occurring over even a fairly short period of time.

Help Us Clear Things Up

If you see someone claiming that brute force attacks against WordPress admin accounts are happening, we would appreciate if you point them to this post, so that we can start to clear up the false information being pushed by those security companies and people can start focusing on properly protecting themselves.

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a good grasp of security, and that the plugin produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation. In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our Plugin Vulnerabilities service, we monitor the wordpress.org forum for threads related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

WordFence Really Doesn’t Know What They Are Talking About

One of the biggest problems we see with improving the security of websites is the amount of bad information out there, as it is hard to start to address the underlying problems when so much of what is being said is wrong. What surprised us when we started dealing with security issues is how much of that bad information comes from security companies. We don’t have the time to go through every instance of this since it is so widespread, but it is worth looking at an example of a company putting out bad information from time to time when a larger security issue is also raised.

On February 11, security researcher Claudio Viviani publicly disclosed a SQL injection vulnerability in the WordPress plugin WORDPRESS VIDEO GALLERY. According to his advisory he had notified the developer of the plugin about the issue two days before that. The next Tuesday we added the vulnerability to our Plugin Vulnerabilities plugin and on Friday, after waiting a few days to give time to the developer to release the fix, we notified the people running the WordPress.org Plugin Directory of that the vulnerability existed and had not been fixed. Following that the plugin was pulled from the directory. Earlier today they let us know the plugin had been removed and that the fixed version should be available soon. While checking to confirm that issue was fixed in the new version, which it was, we came across a forum thread that linked to a WordFence, which sells a WordPress security service, blog post entitled Zero Day SQL Injection Vulnerability in WordPress Video Gallery.

The problems with their blog post start with the title. This vulnerability wasn’t a zero day vulnerability since that involves a vulnerability being exploited before the developer or the public knows about the vulnerability. That wasn’t the case here as the vulnerability was publicly disclosed a week before and it appears the developer knew about it before that. The implications of a zero day vulnerability are much different than what this actually is, so the distinction is important. Zero day vulnerabilities do get more press coverage, so you might ask if they characterized it that way to try to get them attention.

That wasn’t the end of the problems, it continues into the content of the post:

There is currently a zero day SQL injection vulnerability in the WordPress Video Gallery plugin. Our researchers are seeing exploits in the wild for this and the exploits claim the vendor has been notified on the 9th of February.

If you click the “exploits in the wild” link what you get is not anything to do with exploits of the vulnerability in the wild, instead it is a copy of Claudio Viviani’s advisory on the Exploit Database website. The advisory itself doesn’t provide any code to exploit vulnerability. The proof of concept (POC) given simply shows where the SQL injection code would go:

http://target/wp-admin/admin-ajax.php?action=rss&type=video&vid=[SQLi]

It doesn’t include any malicious SQL code and providing the POC doesn’t really make much difference in exploiting the vulnerability since with the details of the vulnerability someone should be able to recreated the provided POC quite easily.

You really have to wonder about the competency of the WordFence researchers when they are claiming that a security advisory is somehow evidence of “exploits in the wild”.

Also in that section they half acknowledge the developer was notified of the vulnerability ahead of the exploitation, which would mean that this isn’t a zero day vulnerability as they are claiming.

The plugin still has not been updated by the vendor. Because this is being exploited actively and the vendor has been notified, we are now publicly disclosing the existence of this vulnerability.

WordFence isn’t actually publicly disclosing anything since the person that discovered the vulnerability already did that, it isn’t clear if they don’t know what public disclosure actually is or if they are intentionally trying to take credit for something they didn’t do.

A ‘googledork’ is also available in the exploit which allows attackers to use Google to find sites which suffer from this vulnerability in order to exploit them.

While this might sound ominous it doesn’t really mean much, the “googledork” in this case is simply a search query that shows URLs in Google’s index that are from RSS feature of this plugin. Here it is from the advisory:

# Dork Google: inurl:/wp-admin/admin-ajax.php?action=rss

Again this doesn’t actually matter much since all the search query does is show indexed URLs that contain the start of the path that is exploited:

http://target/wp-admin/admin-ajax.php?action=rss&type=video&vid=[SQLi]

Protecting Against Unfixed Vulnerabilities in WordPress Plugins

The situation with this plugin does get to a real problem, how do we protect against websites being hacked when known vulnerabilities in WordPress plugins are not fixed. WordFence’s solution beyond reporting the issue to the Plugin Directory, seems to be more effective at promoting their website then dealing with this type of situation:

Please share/tweet/mail this to your fellow WordPress administrators to help create awareness about this serious issue.

We have been pushing for a better approach to handling than this type of situation for years, which would involve WordPress warning admins when an installed plugin has been removed from the Plugin Directory (if you would like to see that happen please vote for it on the WordPress Ideas website). Until that happens you can use our No Longer in Directory plugin that provides a more limited version of that functionality. For this type of situation though one of our other plugins, Plugin Vulnerabilities, is more useful. This plugin warns when installed plugins have known security issue and also provides information on vulnerabilities that existed in other versions, which is useful when cleaning up a hacked WordPress website. Last Tuesday we updated the plugin to warn about this security vulnerability, so if you had our plugin installed and you had version 2.7 of the WORDPRESS VIDEO GALLERY plugin installed you would have then seen the following warning on the Installed Plugins page:

Plugin Vulnerabilities Screenshot

Wordfence and WPScan Acted Irresponsibly With WordPress Plugin Vulnerability

Several years ago we noted a pretty big problem when it came to the security of WordPress plugins; many plugins with known security vulnerabilities in their most recent version were still available in the wordpress.org Plugin Directory. That was a big failure as making sure that those vulnerabilities were fixed or the plugin was pulled until it was fixed was such a low hanging fruit towards better plugin security. For a while after that we were keeping a watch for unfixed vulnerabilities to make sure that wasn’t occurring, but after a while we were simply too busy with services unrelated to security of WordPress that we didn’t have time to do this anymore. Recently we again had time to focus on the security of WordPress plugins, as part of that we started working a new plugin, Plugin Vulnerabilities, which lets you know of security vulnerabilities that exist and existed in the plugins you have installed.

When we started working on the plugin we quickly found that the issue of plugins with known vulnerabilities in their most recent versions still being available in the wordpress.org Plugin Directory hasn’t gone away. In less than a month we have helped to get known vulnerabilities in seven plugins fixed by either contacting the developers of the plugins – who in many are not notified by the person who discovered the vulnerability – or letting the people running the Plugin Directory know that a vulnerability exists in the plugin. Some of them were rather serious, one that we mentioned before involved a backup plugin that permitted any logged in user to download backups made by the plugin. In that case within a day of us passing along the issue to the Plugin Directory people the issue was resolved, that was after almost a month had gone by since the developer had been notified of the issue and two weeks after it was made public.

While looking into another vulnerability we found something more troubling. On September 10 a claimed vulnerability was disclosed in the plugin Rich Counter. In late November when we took a look at it to verify that it was real before add it to our plugin, we found that as described the exploit didn’t work. To exploit the vulnerability it said you should change your web browser’s user agent to “Mozilla<script>alert(document.cookie)</script>”. For us it didn’t work that way, but it did work if you removed “Mozilla” from the start of the user agent. We were somewhat curious as to what had happened to cause a situation where a vulnerability was correctly identified but the explanation of the exploitation of it to not work. We thought it might be case where someone else had actually discovered the issue and someone else was trying to take credit for it. We didn’t find anything to explain the situation, but while doing that we found that several WordPress related security projects had mentioned the disclosure of the vulnerability. We are rather troubled that they were aware of the vulnerability but had not made sure it was fixed or the plugin was pulled from the directory. What made this worse was that within days of us alerting the developer to the issue a partial fix was made and after further message the issue appears to be fully fixed. It would have been quite easy for them to have done the same, but they didn’t leaving website vulnerable when they didn’t have to be, so we feel it is worth highlighting their irresponsible behavior.

First up is Wordfence, which sells a WordPress security service. They mentioned the vulnerability back on October 30 in a post about plugins with vulnerabilities they wanted  “to draw your attention to”, unfortunately they were more interested in drawing your attention to their website then actually drawing the attention of the developer to the issue who would have actually fixed the issue if they had contacted them as we did (or if the developer was unwilling at that time Wordfence should have then contacted the WordPress.org Plugin Directory about it).

The other place we found it mentioned was the in WPScan Vulnerability Database, a website that lists WordPress vulnerabilities,  in an entry added on October 18. Again this came from someone selling WordPress security services and the project is also sponsored by another security company Sucuri. You have to question why security companies would be in the business of providing wider notice of security vulnerabilities in WordPress plugins but not letting the developer, who could actually fix the issue, or the people at the Plugin Directory know about the issue if their interest was truly in security versus making you more vulnerable and then selling you their security services.