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.