11 Jan

A Case For WordPress Providing Details on Fixed Security Issues in Plugins

When it comes to providing information on security issues in web software the amount of information disclosed varies pretty widely. For WordPress security issues fixed in the core they are disclosed when the new version is released. For example, here is how they were mentioned in the most recent security release, 4.6.1:

WordPress versions 4.6 and earlier are affected by two security issues: a cross-site scripting vulnerability via image filename, reported by SumOfPwn researcher Cengiz Han Sahin; and a path traversal vulnerability in the upgrade package uploader, reported by Dominik Schilling from the WordPress security team.

For plugins, which are developed by third-parties, no information is released by WordPress. That isn’t the way that everyone handles the situation. TYPO3, for example, releases security bulletins, including for third party extensions.

In the past we have discussed the issue of WordPress keeping everyone in the dark about security issues in the current version of plugins that they are aware of. While they do remove those plugins from the Plugin Directory, that does nothing for those who are currently using them. Something we recently ran across seems to make the case that providing information on security issues that have been fixed could be useful as well.

It starts with a review from three weeks ago that we ran across recently, as part of our monitoring of the wordpress.org Support Forum for mentions of plugin vulnerabilities, for the plugin Menu Image that claimed that “Plugin applies malware/addware to your site.” The review stated that:

I just wanted to post a warning about this plugin. I have noticed various malicious scripts being added to one of my sites. After countless hours of tracking I found that Menu Image was the problem code. There seems to be an exploit or hole in your code.

We often run across reviews with claims that a plugin is the source of hacking where it is either unsupported by any evidence or where a quick check of the plugin shows that plugin could not have been the source of what happened to the website.

Others responded that they were having the same issue.

The developer responded in a way that wouldn’t seem to be appropriate even if the claim was totally false:

Please, disable the Menu-Image plugin and remove it from your wordpress site at all and never use it in future. I think this will not solve your problem. All plugin code you can check here: https://github.com/zviryatko/menu-image, compare it with that you have.

The reality is that the plugin was in fact the cause of this, something the developer was likely aware of (and certainly should have been), but also something the WordPress was in all likelihood also aware of.

If you read through all the responses on the review the cause of malicious JavaScript is a file notice.php that existed in some versions of the plugin.

What the legitimate purpose of that file was supposed be, if any, isn’t clear. The changelog entry for the version it was added in simply states “Add notification plugin.”

In a support forum thread five from months ago where someone asked why the noticed.php file was connecting to domain apistats.net the developer responded with this:

Yes, there is a strong reason for that, it’s help to make plugin work much better, also there’s no security issue, you can check the code by yourself. When you installed the plugin you saw the license agreement and you accepted it.

How it was supposed to make the plugin work much better isn’t explained.

Checking the code would just tell that it is making a request to that domain, it doesn’t explain why and wouldn’t show what would get served from that (according to one of the responses to the review malicious code was only served from that domain for part of the day).

The fact that there is a license agreement seems like a red flag, looking at what you actually get shown makes things seem even shadier, as you could easily think you are just agreeing the GPL:

The last response in that thread is from the developer, who indicates that the people on the WordPress side of things were aware of a security issue with the file:

Hello, I’ve removed all that code, when plugin will be approved by wp.org security team, it will be back again!

When the issue was resolved the changelog entry stated “Remove notification plugin. It was not a good idea btw.”, which wouldn’t give any one an indication what had really happened.

If WordPress had provided security bulletin on the issue after it was fixed it would have helped to clear up for people that dealt with this what was going on without them having to do a lot digging themselves. As this case shows relying on developer to provide that type of information isn’t always going to work out.

21 Dec

Wordfence Is Leaving Sites Relying on Their Plugin Vulnerable to Unfixed Vulnerability That They Know is Being Exploited

On WordPress’s Plugin Directory page for the Wordfence Security plugin the description of it begins:

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

And later states that:

Wordfence Security is 100% free and open source. We also offer a Premium API key that gives you Premium Support, Country Blocking, Scheduled Scans, Password Auditing and we even check if your website IP address is being used to Spamvertize.

Despite that, it turns out that unless you are not using Wordfence’s paid service you actually can easily get hacked (and even with that you are left vulnerable to their slow response to vulnerabilities). You don’t have to take our word on that, Wordfence admitted to that fact yesterday.

Before we get to that, let’s provide you with some important background information. On November 20 the security company NinTechNet discovered that the WordPress plugin Delete All Comments had an arbitrary file upload vulnerability, which allows a hacker to upload any file they want and through that they can do almost anything they want with a website. They discovered that while cleaning up a website that was hacked through that vulnerability (unlike so many security companies they actual did the important step of trying to determine how the website was hacked). They contacted the developer of the plugin and didn’t get a response. Subsequently they notified the Plugin Directory and the plugin was removed from that. The vulnerability has yet to be fixed, so anyone still using it is vulnerable to being exploited.

On December 10 NinTechNet publicly disclosed the vulnerability. We then added it to the data for our service. We put out a new version of our service’s companion plugin with the vulnerability added to the free data included in it on Monday, the 12th, so those not using our service yet started getting warned about the issue (WordPress really should be warning about this, but their position is that doing that would put people at more risk). On Monday we also started seeing what looked to be hackers probing for usage of the plugin, so it looks like more widespread exploitation of the vulnerability probably began then as well.

Then on Friday we did a test of 15 security plugins, including Wordfence Security, to see if they would prevent the vulnerability from being exploited. This would be a situation where a security plugin could provide some value, since even if you keep your plugins up to date, you would still be vulnerable since the plugins hasn’t been fixed. The result was that none of the plugins provided any protection.

That wasn’t the only instance where Wordfence security wouldn’t stop you from being a vulnerability from being exploited, in five previous test we have found that it provided no protection in three and the protection was easily bypassed in the other two (many of the other plugins we have test have provided no protection in any of test they were included in).

Against those results a recent posting on Reddit by them stood out, they wrote:

I’d say about 2 years ago I would not have been comfortable running WordPress even with Wordfence on a mission critical site where data theft is a disaster.

Today that has changed and there is one thing that changed it: Our firewall. Back when I wrote and launched the code for Wordfence myself (in 2011) we didn’t even have a firewall. We launched a full blown firewall some time ago and it’s now evolved to the point where I’m completely confident that if you install our firewall and are running WordPress, you are going to be much more secure than if you’re running an alternative product, even if that alternative CMS is behind a firewall.


So if you run our firewall I’m 100% confident you can run WordPress securely on a large mission critical production site. We’re doing it ourselves for wordfence.com along with several other major sites we run. All use our firewall.

We responded pointing to the results of our testing that showed the reality is their product doesn’t live up those claims.

Their response to that is rather troubling.

In regards to the vulnerability in Delete All Comments they only did anything about it on December 16:

We developed a firewall rule for that exploit and released it into production on December 16th, the moment we heard about it from our users. That’s a screenshot from our internal Slack. It’s a fun read – shows what a great place Wordfence is to work.

They also only became aware of because of their users, so they are not actively monitoring for information on vulnerabilities in plugins. We were not the only ones that noticed the disclosure before then, it was included in WPScan Vulnerability Database on December 11.

Later in the post they claim that:

As you can see, the team responds very quickly.

Which is the opposite of the truth.

But now people using their plugin are protected right? No:

The rule is now in production for Wordfence Premium. It will only be available in the free Threat Defense Feed 30 days after release, so around Jan 15th.

So they know that vulnerability is already being exploited, since that is how it was discovered, but they are leaving people that use their plugin, but not also their paid service, vulnerable for a month.

They then went on to try to downplay this by claiming the plugin was not very popular twice (emphasis ours):

FYI, that plugin was pulled from the repository and is no longer available. It wasn’t very popular when it was in the repo.

We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild. That just wasn’t a widely exploited vulnerability or a popular plugin. In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

So what do they consider to be an unpopular plugin, one that as of a month ago had 30,000+ active installs.

We would consider that popular. So does WordPress, as the Popular section of the Plugin Directory currently includes plugins with a 10,000+ active installs.

It turns out that not that long ago so did Wordfence. In a post written in November of last year,  New Vulnerabilities in 6 Popular WordPress Plugins, one of the 6  popular plugins had 30,000+ active installs. It went even lower than that. One of the others had only 2,000+ active installs. Did they really radically change their view of what constitutes a popular plugin in 13 month or does their view change to fit the narrative they are going with?

Also worth noting in that is this portion “We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild”. So their protection relies on them being aware of vulnerabilities, which is fairly big problem since we have repeatedly found that Wordfence is unaware of vulnerabilities despite them promoting their Real-Time Threat Defense Feed as giving them “unmatched access to information about how hackers compromise sites”.

What You Should Do If Use Wordfence Security

The best case we see with Wordfence is that they don’t have a good understanding of security, which leads them to repeatedly make false claims. That probably isn’t a good base for creating a good security plugins, which makes the fact that it is the most popular WordPress security plugin with 1+ million active installs problematic (the plugin even has been found to have vulnerabilities of its own in a number of instances). It then wouldn’t be all that surprising that they would make claims about their plugin,like we mentioned earlier in the the post, that don’t match reality.

A worse case scenario is that they are intentionally misleading people to push their plugin and service. Take an example last week where they claimed that there was a recent increase in brute force attacks against WordPress admin password and of course the way to protection yourself against them is to use their plugin. The problem with that being that brute force attacks are not happening. What looks to be going on are dictionary attacks, which involved trying common passwords and can be protected against by simply by using a strong password, no security plugin needed.

Given that, avoiding their plugin could help to attract more people to plugins and companies that have a better handle on security, leading to improved WordPress security.

Beyond that, getting warned when you are using a plugin with a vulnerability that is being exploited would be a good idea. As we mentioned earlier the WPScan Vulnerability Database has included since before Wordfence even became aware of it, so using a plugin that uses their data would do the trick in this instance (if you do a search for “wpscan” on the Plugin Directory you will find a number of those plugins).

As we have discussed in the past though the WPScan Vulnerability Database doesn’t always do a good job of included vulnerabilities in their data (among other issues). That is where the companion plugin for our service can come in. Last week in addition to adding the vulnerability in Delete All Comments to the free data included with that, we added vulnerabilities that were likely being exploited in the current versions of a plugin with 20,000+ active installs and another with 40,000+ active installs (this one has now been fixed). Neither of those are currently included in WPScan’s data, despite us publicly disclosing them at the same time we added them to our data for the service and in the plugin.

If you want more comprehensive information on vulnerabilities in plugin you use can sign up for our service. With that you get information on not just vulnerabilities that are already being exploited, but all vulnerabilities being discovered whether by others or by us (as well as rating on the likelihood of the vulnerability being exploited).

You also get support, so if you run into a situation where you are using a plugin that has yet to be fixed we can help you to make the best decision on handling that. In some cases you can safely ignore the issue, in others we can provide you with a workaround, in others the best option might be to stop using the plugin.

To help keep it from getting to situation where vulnerabilities are first discovered when they are being exploited our paying customers get to suggest and vote for plugins to get a security review done by us.

Finally, by using our service you are helping to improve to the security of WordPress plugins for everyone, as the work we do for the service helps to get numerous vulnerabilities, including many that were already being exploited, fixed for everyone.

Currently you can try the service for free for a month.

20 Dec

You Are Not Going To get The Best Information on WordPress Plugin Vulnerabilities From Twitter

Last week we looked at an example of one of the problems with WordPress’ handling of security, that being websites using plugins that contain vulnerabilities in the latest version are left in the dark about the issue, even in the case of the vulnerability already being exploited, as was the case with this vulnerability in the plugin Delete All Comments (we also found that security plugins didn’t prevent it from being exploited). We were curious to see what others were saying about the issue, so we took a look on Twitter and results were a reminder that you are not going to get the best information there.

We found that a web host was telling people to update the plugin:

There are several problems with that. The first one being that you can’t update it now since the plugin is and had been removed the Plugin Directory for at least several days before that tweet went out. The vulnerability is in the most recent version of the plugin, so updating it wouldn’t provide you with a fixed version. Finally, the vulnerability only exists in the most recent version, 2.0, so if you were able to update it at this point it (say if it hadn’t been removed from the Plugin Directory and you were still using an older version) it would have actual caused your website to become vulnerable (our data on vulnerabilities includes a listing of what versions are vulnerable, so you can also know that sort of thing).

We also found that a security company AntiHackers.co.uk was telling people to disable the plugin:

We would take that as them meaning you should deactivate the plugin, the problem with that is the vulnerability is exploitable when the plugin is deactivated if you send a request directly to the plugin’s main file (when activated you can also exploit it by sending a request to any WordPress page, which can make it easy to avoid security products or services trying to stop it from being exploited).

While looking at the other tweets from that company we noticed something else, a lot of there tweets just involved them repeating information from the WPScan Vulnerability Database, without disclosing that. The problem with that is that  WPScan Vulnerability Database’s data has some serious quality issues, so if you are relying on their data it should be disclosed and notice provided as to the issues. The issues include among other things, odd cases of  not including vulnerabilities and inaccurate reporting that vulnerabilities have been fixed. An example of that latter issue we discussed recently involved a report of a vulnerability in the plugin NextGen Gallery, where we found that while the vulnerability had been reported by the discloser as being fixed in version 2.1.57, it still existed. After we got in touch with the developer and helped them to get it fixed, a full fix was included in version 2.1.60. Since AntiHackers.co.uk just repeats claims from WPScan data they claimed it was fixed in 2.1.57:

It also worth noting that while their tweets they repeatedly state that you need to upgrade “before you get #hacked“, many of the vulnerabilities mentioned are highly unlikely to have exploit attempts against them, so the chances of being hacked due to them is negligible. Unfortunately far to much of the security industry isn’t interested in providing accurate assessments of threat level of different issues (or they don’t actually have the knowledge needed to do that), leading to a situation where often what focused on is not what should be of most concern.

15 Dec

When a Security Company Does the Right Thing and The WordPress Plugin Directory Drops the Ball

Due to how bad the security industry is we rarely have the ability to point to a situation where the a security company has done the right thing, but today we have one to discuss.

Yesterday, we discussed how security companies rarely due one of the three basic components of a proper hack cleanup, which is to try to determine how the website was hacked. As we mentioned in that post, in instances where that isn’t done we are frequently brought in to re-clean the websites after they get hacked again. The problem of not determining how the websites are hacked doesn’t always just impact that website, if the vulnerability exploited exists in the current version of software on the website then spotting an early exploitation has the possibility of limiting the amount of additional websites that get hacked due to it. That possibility occurred with an arbitrary file upload vulnerability that exists in the WordPress plugin Delete All Comments. On November 20 the security company NinTechNet was looking into a hacked website and found the website was hacked due to that vulnerability. It wasn’t all that hard to spot with the combination of the logging and the code in the plugin, but since so many security companies don’t even try to determine how the websites they are cleaning up have  been hacked, something like that can easily get missed.

The vulnerable code was introduced in version 2.0, which was the first release put out by a new committer and that lead someone that mentioned the vulnerability to us, to believe this might have been intentional. To us it also looks like something that could have happened when someone writes code without having a good grasp of the security implications of what they wrote.

After NinTechNet spotted this they did the following:

The author was informed on November 20th but did not respond. We contacted the WordPress plugin department and the plugin was removed from the repository the same day.

On Saturday they publicly disclosed the vulnerability. Subsequent to that we added it to the service’s data and added it to the free data that comes with the service’s companion plugin on Monday, so even those not using the service yet could have gotten notified of the issue (if you haven’t installed the plugin, now would be a good time to do that).

Looking at the logging from our websites and the third-party data we monitor we don’t see any evidence of wide scale attempt to exploit this until Monday. So between when NinTechNet came across this and that there was a chance for the WordPress Plugin Directory to mitigate the threat from this when the developer didn’t.

The easier thing they could do is to start warning people when they are using vulnerable plugins that have been removed from the Plugin Directory, but they are refusing to do that on the basis that it puts people at more risk. As we discussed before that doesn’t make much sense as hackers can still figure out that the vulnerabilities exist even if they keep quiet about it.

The other option would be for them to put out a new secured version of the plugin, which they have the ability to do. They even have the ability to have the update to that version of the plugin happen automatically, in the same way that minor WordPress updates now occur automatically (and in the same way all plugin updates can happen with our Automatic Plugin Updates plugin). Like a lot of security related items involving the Plugin Directory, the process for deciding to release a secured version is rather opaque. In one instance when we tried to raise the issue over the lack of this happening on the wordpress.org Support Forum our post was deleted without explanation and the plugin being discussed was never fixed. If they decide to improve the situation we would love to help with it.

Instead they did neither, leaving everyone using the plugin vulnerable.

Until WordPress gets better about this you can help protect your website for free by installing the service’s companion plugin and installing one of our other plugins that lists plugin you are using plugins that have been removed from the Plugin Directory. For those with the budget you can sign up for our service, where you get data on all plugin vulnerabilities, not just ones that are already being exploited, and you also have the ability to suggest and vote for plugins to have a security review done by us, which could help catch more security vulnerabilities in plugins before they have a chance to be exploited by hackers.

14 Dec

The Wrong Way To Determine The Source of Hackings Leads To False Claims of Plugin Vulnerabilities

We are frequently brought in to re-clean hacked website after someone else had cleaned it up and then it got hacked again. The first thing we always ask in these instances is if the previous cleaners determined how the website had been hacked. If that hasn’t been determined then the vulnerability could still be there, leaving the website open to easily being hacked again. Not surprisingly, considering that the website did get hacked again, the answer almost always is that determining how the website got hacked never even came up during the work (that is despite the fact that is one of the three basic components of a proper hack cleanup).

Sometimes security companies do make an effort to determine how the website was hacked, but maybe because they really don’t know what they are doing or they don’t care to do things right, they don’t attempt to to do it right. To give an example let’s take a look at high profile vulnerability from earlier this year. On May 29 we spotted what looked to be a malicious request sent to a file in the plugin WP Mobile Detector on one of our websites (we were not using the plugin). After looking at the code in the file we noticed an arbitrary file upload vulnerability in the plugin and notified the developer of the issue. Two days later we notified the Plugin Directory and the plugin was pulled. On June 2 a new version was released that fixed the vulnerability (the plugin was subsequently pulled again due to a less serious vulnerability we found in it). Also on June 2 the security company Sucuri mentioned noticing the vulnerability as well:

For the last few days, we have noticed an increasing number of websites infected without any outdated plugin or known vulnerability. In most cases it was a porn spam infection. Our research team started to dig into the issue and found that the common denominator across these WordPress sites was the plugin WP Mobile Detector that had a 0-day arbitrary file upload vulnerability disclosed on May 31st by the Plugin Vulnerabilities team.

This decidedly isn’t how you should determine how website are hacked. In certain instances this might be helpful if you didn’t have access to the more direct evidence, let’s say if say a web host was hacked, since they probably wouldn’t provide you the relevant log files. But in this case since the hacking could easily be spotted in log files and it had just started happening, so when the first website they dealt with was hacked they could have seen what the source was and taken steps to deal with it. Instead they allowed more of their customers to get hacked and didn’t do anything to prevent the ones they already were aware of being hacked from being getting hacked again. If we hadn’t had already disclosed this, who knows when they would have figured out the cause.

Looking for a common denominator can also lead to false accusation as to the source of the hack, as we have saw frequently in the past with security companies falsely connecting hacks to certain WordPress versions. When we looked in to the situation we would find that the websites were not even all running the version of WordPress they were claimed or even running WordPress at all.

Recently we have been running in to instances were WordPress plugins are being claimed to have lead to website being hacked, not based on actual evidence, but based on a correlation with its use on the website being hacked.

Take a one star review of the plugin Google Analytics, titled “Website Hacked”, which says:

Do not use this plugin, there is a whole in this plugin which can be exploited for URL injections.

So how did the reviewer determine that was the case:

Using a new installation of wordpress with only this plugin and it had URL injections all over the place. I will try to pull out the logs for you.

There are a number of ways a website can be hacked other than a vulnerability in a plugin, so it being the only plugin doesn’t necessarily mean it was connected to the hack. When we came across the claim we reviewed the plugin to see if it could be the source of the vulnerability and found a plugin that looked to have been securely coded, with nothing that could lead to this. For those interested in double checking that, the plugin only contains two files with code in them, one generates the settings page and the other with the rest of plugin’s functionality. Considering that the plugin has 600,000+ active installs according to wordpress.org it isn’t surprising that someone using it has been hacked, but if there was a vulnerability in such a popular plugin you would expect to see it being exploited on a mass scale, which we haven’t seen any evidence of.
What makes a false claim like this more problematic is that if you mention any details of an actual vulnerability in a plugin on the WordPress Support Forums (of which reviews are part of) are often removed, but false reports are allowed to stay up, so secure plugins like this can have a false appearance of being insecure versus plugins that have actually been insecure.
Another example of this involves the plugin Smart Maintenance & Countdown, where a one star review has the title “This plugin is infected with an EXPLOIT” and the body of the review as “DO not use this!”. In response to question about the evidence as of the plugin being the cause the review stated:
Here’s what happened: on a freshly installed WordPress I added this plugin. Then I noticed the user_login had changed from “ravadmin” to “indoxploit”.
In looking over the plugin we couldn’t find code necessary for changing a user’s username or any other code that look like it could lead to a website being exploited. With 3,000+ active installs according to wordpress.org if there were this type of vulnerability you would expect to see more than one report of an issue and other evidence that the plugin is being targeted, but we haven’t seen either of those.
We don’t want to give you the impression that all reports of vulnerabilities in plugins in the Support Forums are false, just a couple of weeks ago we ran across an accurate report of a vulnerability in a plugin and that plugin has been removed the Plugin Directory pending a fix after we notified the Plugin Directory. If you see a report of a vulnerability in a plugin there feel free to let us know, because while we do monitor for those, there is a decent chance that doesn’t catch everything, and if we haven’t seen it we can likely figure out if it is legit (and needs further action) or if the reporter should know they likely have a different issue.
13 Dec

Vulnerability Discoverers Shouldn’t Be Threatened Or Shamed In To Hiding Vulnerabilities

One of the issues we continue try to find the best way to handle is the disclosure of vulnerabilities we discover. On the one hand the people that are paying for our service (and therefore ultimately have made those discoveries possible) deserve to get notified in a timely manner when they are using a WordPress plugins with a known vulnerability. On the other hand if the vulnerability hasn’t been fixed yet, disclosing it increases the chances of it being exploited. While our customers will be aware of the vulnerability and we can help to them to mitigate their risk, everybody else using the plugin else remains vulnerable.

To try to balance those two things we attempt to notify the developer of the plugins and give them a chance to fix it before disclosing the vulnerability. How long to wait is one of the items we continue to look at and often isn’t one that fit neatly with standard disclosure periods. For example, if a vulnerability is already likely being exploited, as many we have found are, then waiting 30 or 90 days for a fix would mean that lots of website could be hacked in the meantime, which is far from ideal. Currently for those type of vulnerabilities we usually wait a few days at most for a fix before disclosing the vulnerability. To make sure as many people as possible are warned right away we publicly disclose it at the same time that we start warning our customers, so that other providers have a chance to warn their customers, and we also add the vulnerability to the free data that comes with our service’s companion plugin, so that anyone that has it installed will also start getting notified even if they are not using the service yet.

Disclosing vulnerabilities also sometimes leads to unpleasant interactions with the developers of software that seem more interested in hiding that a vulnerability has existed then actually fixing it. Today ZDNet had a story about PwC (formerly PricewaterhouseCoopers) responding to notification of a security vulnerability in their software with the threat of legal action:

A portion of the cease-and-desist letter, seen by ZDNet, said that PwC demanded the researchers “not release a security advisory or similar information” relating to the buggy software. The legal threat also said that the researchers are not to “make any public statements or statements to users” of the software.

Not only does this do nothing to fix this particular vulnerability, which someone else with malicious intent could find (or already has found) and start exploiting, but each time a company does this it makes it less likely that other vulnerabilities in software are going to be reported to the developers in the future, making everyone less secure.

In our dealing with developers we have yet to get any legal threats, but we have on occasion we have gotten responses that we don’t find all that appropriate. One of those occurred today.

Back in September we discovered an authenticated cross-site scripting (XSS) vulnerability in the plugin wpDataTables Lite, in part based on a disclosure of a previous vulnerability in a paid version of the plugin. The developer responded later the same day that they would be including a fix for it in the next release, since it was a type of vulnerability that isn’t likely to be exploited we didn’t have a problem waiting for that to be released. In hindsight that seems to have not been a great idea as the next version wasn’t released for three months (we are currently looking at having a policy to have a limit on how long we wait in this type of situation). So at least after three months it had been fixed right? No.

After finding that there wasn’t’ anything that looked like an attempt to fix the vulnerability in the new version, yesterday we disclosed the vulnerability and reported the issue to the Plugin Directory. Once a vulnerability has been reported to the Plugin Directory, unless it is very minor, the relevant plugin will be removed pending a fix. Our experience is that often will quickly lead to a vulnerability being fixed that has been ignored by the developer, but it also can lead to it taking longer for a fixed versions to get to users of the plugin, as it can take a while for the Plugin Directory restore the plugin after a fixed version has been submitted.

This morning we got an email from the developer asking us to remove the post. After explaining how they had failed to include the fix in the new version, they made the following remarks which in part questioning our motives:

Of course that’s our fault, and our mistake that we didn’t resolve that quicker, however we truly hope that your primary goal is to keep WP sites secure, not to have as many of them hacked as possible, through a published exploits DB. We hope hacker’s sites did not yet notice the article to re-publish it and distribute an exploit – and I hope you don’t want this to happen.

Probably the most important is that this type of vulnerability is very unlikely to be exploited on your average website, so the risk of disclosing it is minimal. Where it might be used is in a targeted attack, of which there are not many of, and in which it should be easy for someone doing that to find the same vulnerability.

After we responded explaining why disclosing vulnerabilities is important (we have help to get numerous vulnerabilities fixed due to disclosures made by others) and the fact that if not for people disclosing vulnerabilities our services wouldn’t exist and therefore the vulnerability in their plugin would likely remained there for the foreseeable future, we got more responses questioning are interest in making WordPress more secure.

It is frustrating when developers that haven’t secured their own code are questioning the interest of those trying to actually doing the work to limit the damage that has, instead of promptly resolving their own problem.

08 Dec

CWIS Antivirus Scanner Can Also Leave You Unaware That You Are Still Vulnerable To Plugin Vulnerabilities

Yesterday we discussed a couple of recent instances where WordPress plugins were reported to have vulnerabilities that were fixed by discovered and those vulnerabilities were added to WPScan Vulnerability Database with the vulnerabilities listed as be fixed. But in both cases when we actually tested out the vulnerabilities as part of our adding them to our own vulnerability data, we found that the vulnerabilities had not actually been fixed. Those instances were a reminder of the need to actual check if vulnerabilities have actually been fixed (those two instances are by no means the only times that has happened) and reminder that isn’t something that happens with data included in the WPScan Vulnerability Database, which is used in a number of services and plugins. It turns out they were not the only ones that incorrectly listed one of the vulnerabilities as being fixed.

Last month we looked at a new source of vulnerability data in WordPress plugins, the plugin CWIS Antivirus Scanner, and found that they were including false reports of vulnerabilities in plugins in their data. Just as we came across it the first time, through our monitoring for updates to plugins that might be related to a security fix, a more recent update for the plugin popped up with that and one of the new listings was:

2016-11-22 * Check Email [version = 0.3] XSS : http://www.exploitalert.com/view-details.html?id=25359

As we mentioned in the previous post while the vulnerability in the Check Email plugin was listed as being fixed in the version after 0.3, 0.5, it was until two more releases (and our helping the developer) that it was actually fixed in 0.5.2. If they had tested out the vulnerability the would have also noticed it hadn’t been fixed, but clearly they didn’t. So if you use the CWIS Antivirus Scanner to warn you about plugin vulnerabilities you will need to test out any vulnerabilities in the plugins you use to make sure they are actually fixed, otherwise might still be vulnerable (or you could use our service, since we actually do that testing in the first place).

That same release of CWIS Antivirus Scanner also continued with the adding of vulnerabilities that don’t actually exist. Two of the other entries were as follows:

2016-11-22 * MailChimp [version = 4.0.7] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25361

2016-11-22 * Easy Facebook Like Box [version = 4.3.0] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25351

In the case of both vulnerabilities just a quick glance by someone knowledgeable about vulnerabilities in WordPress plugins would likely been enough to think that they were false, since the proof of concept for exploiting them seemed to show that the protection against the vulnerability actually existed. When we tested out each of them we found the protection was properly functioning, so neither of the claimed vulnerabilities actually existed.

Including the false report of a vulnerability in the Easy Facebook Like plugin is more problematic, as CWIS Antivirus Scanner lists it as being the current version of the plugin. The plugin has 90,000+ active installs according to wordpress.org, so that is lot of webmasters that could be mislead to think their website is currently insecure. MailChimp for WordPress has 600,000+ active installs , so even though they are not listing the current as being vulnerable, a lot of people could think there website had a vulnerability in the past, which it didn’t.

07 Dec

WPScan Vulnerability Database’s Data Can Leave You Unaware That You Are Still Vulnerable

Recently we looked at two instances where the WPScan Vulnerability Database only included some of sets of vulnerable plugins that we had disclosed, leaving those relying on their data unaware that they were using plugins with known vulnerabilities in the current versions. One set of vulnerabilities were easily exploitable and the other set involved plugins that it looked like hackers were already targeting, so the omissions were pretty serious. We still don’t understand how that happened, seeing as it is much easier for the WPScan Vulnerability Database to add new vulnerabilities than it for us since they don’t review the vulnerabilities before adding them. Their lack of reviewing vulnerabilities causes its own issues, as we found in two cases where they were claiming that vulnerabilities were fixed when they were not. If it were not for us, those vulnerabilities would still be in the plugins at this point, which is a reminder of the critical role we play in the security of WordPress ecosystem.

Bad Report = Bad Fix

Recently a report of a vulnerability in the very popular NextGEN Gallery plugin, which has 1+ million active installs according to wordpress.org, was released. We continue to be unsure of what vulnerability the report was actually trying to refer to since in only a few sentences it seems to be referring to an authenticated local file inclusion (LFI), authenticated arbitrary file viewing, or authenticated remote code execution (RCE) vulnerability. The WPScan Vulnerability Database list the vulnerability as being an authenticated local file inclusion vulnerability:

But in our testing we couldn’t find where that or an authenticated arbitrary file viewing vulnerability would have existed in the relevant code. Whether either of those vulnerabilities existed it seems to us that the vulnerability definitely existed, the authenticated remote code execution vulnerability, was the most serious, since it would allow you to do the equivalent of both other vulnerabilities.

In the version that reporter of the vulnerability and the WPScan Vulnerability Database reported it to be fixed, it wasn’t. The developer had made a change in that version that would have been relevant for either a local file inclusion or arbitrary file viewing vulnerability (though the code that already existed had same impact on the possibility of an arbitrary file viewing vulnerability). After we notified the developer, a change was made to try fix the actual vulnerability, but the first attempt included a security check that was easily bypassed. After notifying them of that and suggesting a more secure way to accomplish that, the vulnerability was finally fixed in version 2.1.60.

Fixed and Fixed Again

The second vulnerability also involves a bit of confusion. While the report of a vulnerability in the Check Email plugin labels the vulnerability as a cross-site scripting (XSS) vulnerability, parts of the report claimed the issue was caused by a cross-site request forgery (CSRF) issue. In version 0.5 of the plugin, protection against CSRF was put in place for the sending of test emails, but this protection didn’t do anything for the XSS issue because that can occur without any attempt to send a test email. After noticing the issue we contacted the developer and after one additional release, 0.5.1, that didn’t fix the issue, we were able to work with them to get a proper fix to the issue put in place with version 0.5.2.

As of November 15 the WPScan Vulnerability Database listed the vulnerability as being fixed in version 0.5:

A week later it was supposed to have been fixed 0.5.1:

You Need To Double Check Their Data

If you are using data from the WPScan Vulnerability Database and you actually want to be sure that vulnerabilities in plugins you use have been fixed you will need to test out any relevant vulnerabilities yourself, or you could sign up for our service, where we actually do the testing when adding vulnerabilities to our data (there are a number of other advantages that come with our data).

28 Nov

What worse than security journalism? Security journalism by security companies.

When it comes to poor state of security a big cause is the poor state of the security industry, in which most of the companies don’t know or care much about security. There is obviously role for journalism to shine light on how bad things are, but unfortunately they are often a part of the problem instead. For example, it seems like that the poor state of security journalism actually leads to some of the inaccurate and sometimes all together false research being put out by security companies, as sensational claims are more likely to get coverage from journalists and those journalist often don’t do any due diligence as to whether the claims have a basis in fact. So a security company could spend a lot of time doing real research and hope that it gets covered or they could skip the hard work and just make claims that are likely to pique the interest of journalists knowing that it is unlikely the journalists will look into the accuracy of the claims.

When it comes to the security of WordPress plugins we often see inflated claims about minor issues, while at the same time other issues that are serious issues don’t get coverage. Take for example a situation that we have been trying unsuccessfully for years to get fixed, where WordPress is refusing to warn people that they are using plugins that have been removed from the Plugin Directory due to security vulnerabilities. Considering that some of those plugins will never be fixed by the plugin’s developers and others are already being exploited when the plugin is removed, warning people is necessary and not doing it is leading to websites being hacked. At the same time you get overblown coverage of minor vulnerabilities that have already been fixed. A recent situation along those lines, shows that sometimes security journalists can actually be better than that, but that security journalism done by a security company can come in to keep the bad situation going.

As part of our monitoring for security issues in WordPress plugins to add them to the  data set for our service we monitor for news coverage of WordPress plugin vulnerabilities. Through that last week we came across a Threat Post article “WordPress Plugins Leave Online Shoppers Vulnerable“.  The article stated that:

Researchers are calling into question the safety of some of the top WordPress e-commerce plugins used on over 100,000 commercial websites prepping for Black Friday and Cyber Monday online sales.

In reviewing the top 12 WordPress e-commerce plugins, application security testing firm Checkmarx found four with severe vulnerabilities tied to reflected XSS (cross-site scripting), SQL injection and file manipulation flaws.

So what these vulnerabilities? The author of the article didn’t have any idea:

The study did not call out specific e-commerce plugins used by WordPress sites, nor did it identify which sites used the plugins. Researchers at the firm did not reveal whether the vulnerabilities had been patched by the plugin vendors or websites using them, either.

If the vulnerabilities existed the details of them would matter quite a bit as to whether they were severe (the reflected cross-site (XSS) vulnerability being the exception, as we will get to a bit later).

Looking at the report from company behind the claim, Checkmarx, they had not even notified the developer’s of the plugins about the claimed issues:

While most of these plugins are updated regularly, we are unable to comment on if there are patched versions until we notify the organizations behind the plugins about the possibility of having an open attack vector.

At this point we where perplexed as to they put out report without having done that or providing the details of the vulnerable plugins. It turns out we were not alone, Steve Ragan of CSO who had been offered the report ahead of its release had the same view:

The response from Checkmarx is good example of general terribleness of security companies:

While this certainly gives the company PR, we don’t understand what awareness this could possibly provide. Its not like it is a secret that software can have security vulnerabilities.

The last time we ran into Checkmarx they had put out another report of vulnerabilities in WordPress plugins,  where one of their recommendation was “Ensure all your plugins are up to date”, while running an out of date version of WordPress on their own website.

So one journalist passed on this, the explanation why another didn’t could be the fact that Threat Post is product of another cyber security company Kaspersky Lab (which we also found running outdated software on their website several years ago).

These Might Not Be Severe Vulnerabilities

One of the unique features of our data on vulnerabilities in WordPress plugins is that we provide a severity rating for vulnerabilities, so that our customers can have a better understanding of the threat posed by it, because we were finding that severity of them are frequently overstated. As we mentioned before without the specifics you can’t say in a lot of cases how severe is a vulnerability, but we can look in general terms as whether the vulnerabilities Checkmarx claimed to have found in the four plugins, match up with the claim in the report that they are “high-risk vulnerabilities”. The claimed vulnerabilities are:

  • Reflected cross-site scripting (XSS) in three plugins
  • SQL injection in one plugin
  • Second order SQL injection in one plugin
  • File manipulation in one plugin

The vulnerability found in three plugins, reflected cross-site scripting (XSS), is decidedly not a high-risk. While this type of vulnerability could cause a lot of problems, it just isn’t likely to be exploited in the real world based on everything we have seen. There two likely reasons for that. First, all of the major web browsers other than Firefox have XSS filtering, so an attacker would need to figure out a way around that (or multiple ways for different web browsers). Second, this type of attack involves getting someone else to access a specified URL, which isn’t something we see being attempted all that often.

For the next two SQL injection and second order SQL injection the risk that comes from this varies as to what the attacker can do. SQL injection involves getting malicious code into a request being made to a database. This type of vulnerability would likely be exploited if it allowed creating a new WordPress Administrator users or allowed placing malware on the website’s page. But the most common action that can be taken is to slowly extract information stored in the database, while that could be a big concern with a website doing eCommerce, we don’t seem much of the way attempts to exploit this type of thing, so again not a high-risk.

The final type, file manipulation, is something we are not clear as to what they are referring to. Since it seems they are referring to something that actual encompasses a fair amount of different vulnerabilities that could impact files. Their description doesn’t clear up what they might be referring to:

File manipulation vulnerabilities occur when files, or directories are able to be manipulated in ways that the developer did not intend them to be, thus giving the user, or malicious party, access to modify either the file or directory which could lead to devastating consequences from either the plugin other users.

There description of the potential impact makes things even less clear:

Cyber criminals could exploit a file manipulation vulnerabilities contained within a shopping cart plugin and adjust the files to change the prices during the checkout stage of processing.

Pricing information is usually stored in the database, so we are not sure what files would have to do with it, unless it involved modifying hard coded values or changing pricing calculations.

Beyond the type of vulnerability, the severity of the SQL injection vulnerabilities and the file manipulation vulnerabilities could be greatly impacted by what level of access is need to exploit them.

Based on what was present in the report Threat Post’s claim that severe security vulnerabilities were found is not supported.

21 Nov

CWIS Antivirus Scanner Plugin Spreading False Reports of Vulnerabilities In WordPress Plugins

One of the things we state about our service is that we provide our customers with the best data on vulnerabilities in WordPress plugins. To show an example what difference that makes let look at a recently created plugin that also provides data on plugin vulnerabilities.

The plugin is named CWIS Antivirus Scanner, which we became aware of it severals day ago due to our monitoring of updates made to plugins that might be related to a security fix (so that we can include more vulnerabilities that are not otherwise disclosed in our data). An update to that plugin showed up in that. Just by looking over the vulnerabilities added in that update we could already see the data provided was of poor quality. One of the vulnerabilities listed was a claimed cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in the plugin Newsletter, which, according to wordpress.org, has 200,000+ active installs.

As we discussed over a month ago when the report of this claimed vulnerability was released the supposed cross-site request forgery issue that would have lead to this vulnerability didn’t actually exist. It looks as though the discoverer had not understood what was going on, as there proof of concept to exploit this actually included the protection against that type of vulnerability.

Looking through the other claimed vulnerabilities we had put out posts that detailed how they were false we found that the plugin also includes false vulnerabilities for WP Job Manager (80,000+ active installs) and Robo Gallery (20,000+ active installs). Including false vulnerabilities is on its own problematic, since we have seen people become convinced that their websites was were hacked through vulnerabilities that didn’t exist (leaving the actual vulnerability unaddressed and leading to in some instances, the website being hacked again) and because developers of plugins have their time wasted having to explain multiple times that the plugin did not have the vulnerability.

The larger issue though is that including these false reports indicates that the developers of this plugin are not thoroughly reviewing vulnerability reports before adding them. Beyond the issue of false reports, that is a problem because we frequently find that vulnerabilities have not been fixed despite the report stating they have been. Since hackers usually would not check if you are using a certain version of a plugin before trying to exploit, so if the unfixed vulnerability is something hackers would target then being told that it has been fixed isn’t going to protect you. So to fully protect yourself you would need to review vulnerabilities in the plugins you use when using a data source that doesn’t do that. The other option is to use our data, because as far as we are aware we are the only ones that actually review each vulnerability before adding it to our data set (we are usually are eventually successful in getting those unfixed vulnerabilities fixed, so even if you don’t use the service you are not left vulnerable forever in those instances).

We did one other quick of their vulnerability data, which showed a bigger issue with their data. While we provide our full data set to paying customers, we are not leaving the wider community out in the cold. In the companion plugin for the service we provide data for vulnerabilities in plugins we see hacker trying to exploit, so even if you are not using the service yet you will get warned if you are using vulnerable version of those. Of the 18 vulnerabilities we added in the last month, the CWIS Antivirus Scanner included none of them. Making this more problematic is 16 of those vulnerabilities exist in the most recently available version of the plugin, so even if you keep your plugins up to date you would be vulnerable.

One more thing we thought worth noting, since we always find it to be red flag as to trustworthiness of a plugin’s developer, is if they review their own plugin. That is the case with this plugin, were the developer titled their review “Excellent!” and the body of the review is “Just installed and scanned my website’s database and files, and it works!”. Also, why is the Plugin Directory even allowing people to review their own plugins, as it obviously isn’t going to provide an accurate assessment of the plugin?