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.