The Overstated Security Risks of Using an Outdated Version of WordPress

In dealing with hacked websites we often not only have to deal with cleaning up the hack but also trying to clear up misinformation that people hiring us have run across before coming to us. One area of that we used to deal with a lot, were people that were sure there websites were hacked due to usage of outdated software, often the software in question being WordPress, despite there not being any vulnerability in the version in use that would have been likely to be something that a hacker would actually try to exploit. That wasn’t all that surprising since you often have, among other things, security companies that don’t properly deal with hacked websites that will simply claim that outdated software was the cause of a hack instead of trying to determine how websites actually were hacked.

Misinformation continues to be put out along those lines, as a blog post on the The SSL Store that recently showed up in a Google Alert, which we have to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service, shows. In looking at that we saw two key things that we thought were worth pointing out about the security of WordPress and security in general.

Outdated Doesn’t Necessarily Mean Insecure When It Comes To WordPress

While there certainly problems with the handling of security of WordPress, other things are done better than other web software, which you might not know of due to the poor quality of coverage of its security.

One area that WordPress has been ahead of other software is in its update mechanism. WordPress has long allowed easy updating of itself. Things got better in WordPress 3.7, which introduced automatic background updates. While that features allows doing any type of update automatically, by default what it does is automatically apply minor WordPress updates without requiring any action the people managing the website. So for example WordPress would normally automatically update from 4.9.4 to 4.9.5, but wouldn’t go to 5.0 automatically.

Alongside that feature WordPress started releasing security updates for older versions of the software as minor updates. So even websites still running versions back to 3.7 are currently getting security updates. That post missed that entirely. Instead treating websites that were running the latest minor releases of version 4.7 and 4.8 as if they were insecure, despite having the same security update as the latest version of 4.9.

Most Vulnerabilities Are Not a Major Threat

One of the problems we see not just with WordPress, but in general is that people don’t have an understanding that not all vulnerabilities are of equal concern and risk of being exploited. What certainly doesn’t help that is that security companies often vastly overstate the threat from vulnerabilities they discover or are discussing.

The reality is that most vulnerabilities out there are not likely to be exploited. With WordPress there was about a decade where despite numerous vulnerabilities being found and fixed there wasn’t any successful hacking at any significant scale of those vulnerabilities. That streak was broken early last year with a vulnerability that had existed in WordPress 4.7.0 and 4.7.1. But even with that vulnerability the impact was fairly limited, as most websites had been automatically updated to 4.7.2 before exploitation started and for most websites still vulnerable, it only lead to the contents of post or pages being modified. That meant that cleanup was easy as all you had to was replace that content and normally WordPress have prior versions stored that could be reverted to. So the even for websites where the automatic background updates were not working for some reason and the website was not manually updated before exploitation started, the vulnerability was more of a nuisance.

You wouldn’t know that from that post since there was this inaccurate quote from a security professional:

When a vulnerability is found in a version of WordPress, hackers will create an exploit for that vulnerability and then cast a wide net, usually in an automated fashion, looking to see who is not up to date. Realize the importance of a “wide net”, they don’t care who you are or what you do, just that you have a site.  Once compromised, the hacker will then see what they can get from their site such as account information and then maybe try to use that information to attack other systems that you may have.  At the very least, the hacker will trash your site or use it to store data of importance to them (stolen data, illegal pictures, etc.).  The result, at the very least, is a bad public image when it is discovered that your site was compromised.

Again, a lot of vulnerabilities in WordPress simply would not lead to hackers doing anything that would impact the average website. Also, when it comes to the average website getting hacked, the hacker is usually using it as part of spam or malware campaign (with spam being more common these days with the hacked websites we are brought in to deal with) and the hacker doesn’t care about any data on the website.

Another inaccurate quote in that post from a web develope is as follows:

Once your website is hacked it’s very difficult to repair. Essentially, hackers who get in to your website will create new hidden entry points and unless you close them all, it’s easy for them find a way back in. The results are horrible for the business.

As the example of the vulnerability in WordPress 4.7.0 and 4.7.1 shows, the impact can be less than what they described there. It also important to note, because we sometimes have people that contact us that believe their only option is to start over with a new website, if you hire someone that properly cleans up websites (which unfortunately isn’t the case with many security companies), it shouldn’t be too difficult for them to get the website fully cleaned up in almost all cases. It would be much better to do the things that will actually keep a website secure than hiring someone to clean it after not doing those things or spending money on a security service that isn’t actually focused on keeping websites secure, though.

Cleaning Up After StudioPress Sites and Sucuri Didn’t Protect or Properly Clean a Website

Two weeks ago we wrote about how StudioPress Sites and Sucuri hadn’t properly dealt with a hacked website, leading it to being hacked again. Subsequent to that we were hired to re-clean the website, which allowed us to see more of what had and hadn’t happened. The results, which we will get to in a moment, are not just a reminder that a security company being well known, as Sucuri is, doesn’t mean that they have any business being involved with security, but also the limits of automated security solutions in general.

Probably the most striking thing that we found, is that based on evidence we ran across in an error log file, the hack had been going on for more than year.

We often find that when we are brought in to clean up hacked websites the hack goes back much further then the website’s owner was aware of. That could be a good reason to use a service that is designed to detect the presence of malicious code on website, if used in conjunction with doing security basics, as that could give you better assurance that the website is secure. The problem with that is we have yet to see evidence presented that solutions that attempt to do that are all that effective. The one time we ran across a security company claiming that independent testing had been done, the result was that their product was 100% effective. That sounded unbelievable to us. One of the important questions as to validity of that was how the samples tested were chosen. It turned out the security company had provided the malicious code that was used to test their service against. That meant it wasn’t independent testing and also made it meaningless that they detected 100% of it, since they could choose things they knew the service could detect.

One of the most worrisome indications of the quality of services to detect malicious code on websites is that we have seen companies providing them having marketed them as if they will protect website from being hacked in the first place, which obviously isn’t remotely possible since they only come in to play after the website is hacked. Either the developers don’t understand really basic elements of what they are providing or they are rather blatantly lying, neither of which seems like something that should be true about a company that has anything to do with security.

In the case of this website that type of detection was supposed to be happening:

Finally, we partner with Sucuri for continuous malware monitoring, scanning and remediation. If malware is found we take the responsibility of removing it so you don’t have to worry about it. Additionally, we also scan for advanced threats, including conditional malware and the latest cyber intrusions.

But it wasn’t, as neither StudioPress Site nor Sucuri were the ones that finally detected the issue, instead person managing the website noticed the issue.

As we mentioned in the previous post, how the StudioPress Sites service is promoted though made it strange that detection and cleanup would even be needed to be provide with the service, because it was claimed that service would protect websites from being hacked in the first place:

Our “always on” proprietary intrusion prevention technology works continuously to keep your WordPress install safe from vulnerabilities, intrusions, and exploits. Our years of experience, plus audit input from multiple third parties, allows us to create configurations and settings that keep the bad guys away without handcuffing your working style.

Clearly it didn’t.

While re-cleaning the website we saw a several issues with what looks to be an automated cleanup done by Sucuri.

The first was a much less serious issue, but it was rather annoying for us, as Sucuri had left numerous empty files all over the website. It looks like if they remove all the code in the file because it is all malicious they don’t then remove the file. That created a couple of issues. The first being that when we did file comparisons to identify any changes made by the hack we had all of these empty files coming up in addition to files that still contained malicious code. The second being that when we started reviewing the log files to see how the hacker was able to continue to access the website, it looked at first glance that they were successfully able to access quite a few files, that actually were empty, that increased the time it took to find the logging of successful requests to malicious files that still existed.

Along those same lines we found that in other instances while Sucuri looks to have removed malicious code they left other content that had been added by the hacker, including comments that had been before or after malicious code. Those all then needed to be checked over during file comparisons, slowing down getting to the serious issues.

Those things then tie it the much more serious issue. We were able to easily find the files that were being missed by Sucuri’s automated tools, which were allowing additional malicious files to return that they were able to catch (and then remove again and again). Simply doing some file comparisons, some quick checking over the files in some directories, and looking at the logging, allowed us quickly find what Sucuri’s tools were missing. None of those things are by any means advance solutions (it isn’t the first time simply solutions used by us have caught things they missed).

Takeaways

First and foremost, this situation should be a reminder that claims made about security whether by security companies or other companies should be viewed with great skepticism. If there isn’t evidence backing a claim there is good chance that, at best, it is being made without any idea if it is true or not.

Second, relying on a service that will try to detect and remove the result of a hack instead of making sure you are doing the security basics, which will prevent many hacks, is not a good idea since you can run into a situation like this where the hack goes on and on.

Third, any company that is offering to do cleanups with just automatic tools is probably a company you don’t want having anything to do with cleaning them up since they either don’t understand what they are doing or they are providing a service that they know can’t get the job done.

Finally, if your website is hacked, you want to make sure you hire someone that will properly clean it up. The three components of that are cleaning up the malicious code and anything else the hacker added, securing the website (which usually means getting the software on it up to date), and trying to determine how the website was hacked (which not only helps to prevent it happening again, but as we have found repeatedly, helps to make sure that the hack is fully cleaned up). One simple way to insure you are hiring someone that does that is to hire us, since we have always done those things throughout the many years we have been dealing with hacked websites.

Wordfence Employee Ridiculously Claims You Can Make Sites “invincible against all the attack methods that are associated with WordPress sites”

While we have seen the bad side of the security industry for a long time, certain things continue to be surprising to us despite having seen them many times before. One of those is sheer amount of lying that goes on (that is on top of the amount of the massive amount false and misleading claims that are not clearly lies), despite trust being an important part of security. One area we frequently see that with is claims that products and services can provide a level protection that they can’t possibly provide.

When it comes to WordPress security plugins two are tied for the most popular in terms of active installations according to WordPress.org. One of them, Limit Login Attempts, is focused on a threat that isn’t of real concern and the current version contains a security we discovered and disclosed through our Plugin Vulnerabilities service last week (that security plugins frequently are found to have security vulnerabilities is a good indication of the poor state of the security industry). The other, Wordfence Security, owes at least some of its popularity and maybe a lot of it to marketing it with the unqualified claim that it “stops you from getting hacked”:

The WordPress security plugin provides the best protection available for your website. Powered by the constantly updated Threat Defense Feed, WordFence Firewall stops you from getting hacked.

That claim used to be the second sentence of description of the plugin on the page for it on the Plugin Directory and more recently has been found in the answer to the second FAQ question on that page.

The reality is that security plugins can’t possibly stop a lot of hacks, Wordfence intentionally leaves websites not using their service as well as the plugin vulnerable to being hacked, and in testing over at our Plugin Vulnerabilities service we found that the plugin provided no protection or the protection was easily bypassed when attempting to exploit real vulnerabilities in other plugins.

Once again in our monitoring of the WordPress.org Support Forum to keep track of information vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service we ran across a Wordfence employee admitting that the plugin doesn’t do what they claim. This time it had the added element that even while admitting to that, they were still claiming a level of protection that is contradicted by what they were responding to.

The Wordfence employee wrote this:

Sorry we didn’t get back to you sooner! Unfortunately, there are many attack vectors associated with WordPress sites that lie outside of your WordPress installation like insecure servers, insecure passwords, encryption flaws, shared hosting, and many others; all these things combined make your site vulnerable to attacks. Wordfence helps protect and secure the WordPress installation side of your site and it does quite an excellent job at that. No security plugin can help protect your site against every vulnerability that lives there out in the wild, we can only help mitigate the risks associated with a vast majority of them. I recommend taking some time to go through these articles that will help you better understand WordPress security and how you can make your site invincible against all the attack methods that are associated with WordPress sites.

One of the problems with that is that the failure of Wordfence Security in this instance related to the WordPress installation:

I found this morning that someone from India logged into my WordPress admin panel on Jan. 11th using by login.
I am surprised that Wordfence did not stop this since it had been blocking the ip address range this login occurred from.

That seems like something it should have been able to protect against if it truly “does quite an excellent job at” security of the “WordPress installation side of your site”.

Something else that stood out in the Wordfence employee’s statement is this:

go through these articles that will help you better understand WordPress security and how you can make your site invincible against all the attack methods that are associated with WordPress sites

Below that were links to several pages on Wordfence’s website. Nobody that knows and or cares much about WordPress security would possibly make a claim of invincibility like that, but Wordfence seems to have no qualms about telling lies to public to promote themselves. That unfortunately comes at the expense of the security of websites since people are being mislead about the security Wordfence can provide versus other solutions like our Plugin Vulnerabilities service, which provides real protection that Wordfence doesn’t provide, and our service helps to actually make the WordPress ecosystem more secure even for those not using it.

StudioPress Sites And Sucuri Didn’t Properly Deal With a Hacked Website

Recently we have gotten quite a few questions related to web hosts that include a security service with their hosting service. Considering that web hosts seem to have problems handling the basics of their own security this type of offering seems like it might not be a great idea. Furthermore, most of what needs to be done to keep websites secure isn’t best handled by a security service.

Another issue is that we haven’t seen evidence presented that those types of services are effective at protecting websites and plenty that they are not. One of the pieces of evidence that we have seen that they are not effective is that companies that provide those services often don’t do an important part of properly cleaning up hacked websites. One of the basic components of a proper cleanup is trying to determine how the website has been hacked. If you don’t do that, it leaves open the possibility that the vulnerability is still on the website and can be exploited again. If you are a service that is supposed to protect websites and you don’t even know how they are hacked, you unlikely to do a good job of protecting them.

Security companies can often get away with all of that because the public doesn’t have a good understanding of security and when it comes to the lack of protection, people will often say that such services have been successfully protecting them because they assume that if the website hasn’t been hacked that means the service worked. In reality most websites don’t get hacked, so a service can get credit for providing protection when it does little to nothing to protect websites.

One prominent web security company that all of that would apply to is Sucuri. From what we have seen over the years they don’t seem to have even a basic understanding of security (amazingly one time they warned people to beware of companies that don’t have that). They fail to even handle even more basics elements of cleaning up hacked websites than determining how the website was hacked.

Those kinds of things haven’t stopped the web hosting service StudioPress Sites (previously known as Synthesis) from partnering with them, which they promote in this way:

Finally, we partner with Sucuri for continuous malware monitoring, scanning and remediation. If malware is found we take the responsibility of removing it so you don’t have to worry about it. Additionally, we also scan for advanced threats, including conditional malware and the latest cyber intrusions.

Right before that in their marketing they make this claim:

Our “always on” proprietary intrusion prevention technology works continuously to keep your WordPress install safe from vulnerabilities, intrusions, and exploits. Our years of experience, plus audit input from multiple third parties, allows us to create configurations and settings that keep the bad guys away without handcuffing your working style.

If they were actually able to keep the bad guys out, why would what Sucuri is supposed to be providing be needed? The reality is that when it comes to WordPress, while you see everybody and their brother making claims about their great security, our Plugin Vulnerabilities service seems to be out there alone in catching the kind of serious vulnerabilities in WordPress plugins that would be exploited before there is evidence that they have been exploited (we disclosed two of those just in the last few days). Considering those are a major source of WordPress based websites being hacked, it seems to be a good indications that others are not really do much when it comes to protecting WordPress sites.

We became aware of the partnership between those two companies when someone recently contacted us about a hacked website and mentioned that the website been hacked again after having using Sucuri’s service to clean it up by way of StudioPress Sites. In a situation like that, the first thing we always ask is if the previous company that did the cleanup determined how the website was hacked, since if the source hasn’t been determined and fixed it could explain why the website got hacked again. They responded that they got some generic security advice, but no information about how the website had been hacked or any indication there was an attempt to do that. So it really isn’t all that surprising that it got hacked again.

Out of line with how that hosting is promoted, neither the web host nor Sucuri had been the ones that spotted the hack in the first place. That really isn’t all that surprising since it seems that Sucuri’s scanner is to put it politely, incredibly simplistic, which we base in part on the terrible false positives we have seen it produce.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, but we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities. We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

Hacker(s) Using File Manager Plugin to Assist in Taking Malicious Actions with Hacked WordPress Websites

Recently we have done cleanups of a number of hacked WordPress websites where part of what the hacker did after they have gained access to the website involved something we think would be useful to share with others in case they have even less information to go in trying to figure out how the website got hacked (attempting to determine how they were hacked is one of three basic steps in a proper hack cleanup).

In looking at the logging and other data, we have seen that the hackers were logging in to WordPress using existing WordPress accounts on the websites. From there they would install the plugin File Manager (WP File Manager). Here are the set of log entries where that occurred on one of the websites:

121.118.203.38 – – [15/Jan/2018:14:41:04 -0700] “GET /wp-login.php HTTP/1.1” 200 1693 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:07 -0700] “POST /wp-login.php HTTP/1.1” 302 1258 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:09 -0700] “GET /wp-admin/ HTTP/1.1” 200 22557 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:24 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 553 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:26 -0700] “GET /wp-admin/plugin-install.php?tab=plugin-information&plugin=wp-file-manager& HTTP/1.1” 200 9499 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:31 -0700] “GET /wp-admin/update.php?action=install-plugin&plugin=wp-file-manager&_wpnonce=c0ba6299b7 HTTP/1.1” 200 10849 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:37 -0700] “GET /wp-admin/plugins.php?action=activate&plugin=wp-file-manager%2Ffile_folder_manager.php&_wpnonce=67fdf3eee0 HTTP/1.1” 302 480 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”

As you can guess from the name that plugin is a file manager. The hackers then use the legitimate capabilities of that to modify existing files or add new files with malicious code. Here are the log entries from the same website where the same hacker looks to have logged in from another IP address and accessed the plugins functionality:

189.72.69.203 – – [15/Jan/2018:15:11:14 -0700] “GET /wp-login.php HTTP/1.0” 200 1731 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:18 -0700] “POST /wp-login.php HTTP/1.0” 302 1296 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:21 -0700] “GET /wp-admin/ HTTP/1.1” 200 22745 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:26 -0700] “GET /wp-admin/admin.php?page=wp_file_manager HTTP/1.1” 200 12922 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:31 -0700] “GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=4028a67f1f&cmd=open&target=&init=1&tree=1 HTTP/1.1” 200 3150 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:35 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 2068 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”

The most important question in all this is how the hackers got access to the logins for the websites, since without access they couldn’t have installed the plugin or done anything else. Unfortunately the cause is something we haven’t been able to say for sure since the evidence we have is somewhat limited when it comes to determining that part of these hacks.

In at least some of the cases the website were using extremely weak passwords (on one website the password was “admin1234”), so it is possible that a previous dictionary attack had determined the password. A dictionary attack involves try to log in using common passwords. Those types of attacks are fairly common, unlike brute force attacks, which despite inaccurate claims frequently made by security companies, are, based on those companies own evidence, not happening. The logging available so far hasn’t shown that occurring though, but it could have occurred outside the time period that there was logging available (the longer websites store logging the easier it would be to trace the original source of hacks).

In some instances the password being used was also used as the password for other services as well, so it possible that it was compromised somewhere else and the hackers tried it on the websites.

That all leads to the first take away from this, which is to make sure to use strong passwords (something WordPress does a good of making sure you can do) and to use separate password for each login connected to a website.

The second is that if you are dealing with a hacked website where the plugin File Manager was recently installed and it wasn’t installed by someone involved with the website, a compromise of a WordPress account with the Administrator role should be considered a possible source of the hack and further investigated. In one of the websites the plugin was later removed by the hacker, so you if see logging showing it being used, but it isn’t currently installed, that could have occurred on the website you are dealing with as well.

The third is that is that trying limit hackers once they have high level access is not necessarily very useful. In the past we have seen it suggested disabling the plugin and theme editors, since hackers could use those to modify files with malicious code. But as what happened here shows, hackers can easily get around that possible limitation.

Unlike Wordfence, We Fully Guarantee Our Hack Cleanups of WordPress Websites

One of the things that we often get asked about when it comes to hack cleanups, is how long we guarantee them. The answer is quite simple, if the issue comes back that means that we didn’t do something right and we wouldn’t charge anything additional to get it properly resolved. We would think that would be true of any upstanding company, but clearly most of the web security industry doesn’t feel that way, as we recently noticed with Wordfence.

When we discuss cleaning up hacked websites on our blog we don’t say that you should hire us, but that should hire someone that does things properly. That isn’t the case with Wordfence, which probably tells you a lot about them, as we saw recently with a blog post they wrote:

The most reliable way to recover if your website is hacked is to use our site cleaning service. Our team of experts will clean your site and get it back online as quickly as possible, and the service includes a detailed report and a 90-day guarantee.

What also stood out was there was their 90-day guarantee.

Looking at the page for that service, the backing they offer for their service is even more limited, as they say:

Work guaranteed for 90 days from service only if post-service recommendations are followed.

Who knows what those recommendations are, but that sounds like a way for them to weasel out of making things right if things went wrong.

There is another problem with a guarantee like this, based on what we have seen in often being brought in re-clean up hacked websites after someone else didn’t do it properly. Often times people haven’t realized that the issue hasn’t been properly fixed until after 90 days. When we are contacted about re-cleaning a website we always suggest that people go back to the people that originally did the cleanup and get them to do it right (even though if the previous company does that, it means less money for us), since if it was us, we would want to make things right . But with Wordfence if you noticed the issue outside of 90 days, you would be stuck paying them again if you did that (or needing to hire someone else to do it again).

Something else about how they promote their service really needs to be noted:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

Having the most popular security plugin doesn’t mean that they have the most expertise, it just means they have the most popular plugin. As we have mentioned in the past, the reality is that Wordfence has a scary lack of security knowledge. So how do they have the most popular security plugin? Part of the answer is to just blatantly lie. For example, the second sentence of the description of the plugin on wordpress.org until two weeks ago (and is now in the answer to the FAQ question “How does Wordfence Security protect sites from attackers?”) was this unqualified claim that it will protect your website from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

The reality is that a WordPress plugin couldn’t possibly stop websites from being hacked in some ways (which Wordfence is well aware of) and Wordfence actually promotes their paid service as leaving people relying only on their plugin insecure. It seems like a bad idea to trust a company to clean up a hack when they have show that they have no qualms about lying to you and everyone else.

The second most popular plugin indicates that plugin popularity is not necessarily synonymous with a company that you want have anything to do with as that plugin uses a non-existent threat to collect users’ email addresses and had a “One-Click Secure” Button that did nothing except claim the website has been “Secured”.

Another element of Wordfence’s marketing stood out to us as well:

By work with them, they really mean they request a review through the same automated process as you or anyone else can use to do that.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, which based on some of stuff we have seen from Wordfence seems less likely. But we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities (with Wordfence you get widely inaccurate data on plugin vulnerabilities). We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

Wordfence Employee Admits the Company Knows Wordfence Security Won’t Stop All Hacks as They Continue To Claim Otherwise

What we have been noticing more and more is how much lying is done by the security industry. Considering that trust is an important part of security and you often have to rely on their claims about what protection their products and services might provide, that is a big issue.

One glaring example of this when it comes to WordPress related security, is a prominent claim made about the most popular security plugin, Wordfence Security. The second sentence of the description on its page on wordpress.org is:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

Could a WordPress security plugin stop some hacks? Sure. Can it stop all them, as this unqualified statement by the makers of the plugin would lead to you believe? No.

People do believe that claim though, as we were recently reminded by a topic on the WordPress Support Forum that we ran across while doing monitoring for our Plugin Vulnerabilities service. The topic is titled “Hacked anyway!” and the message reads:

Well.
I installed Wordfence, and got hacked anyway.
Not sure whether or not to trust it anymore.
A defacement hack by the look of it.
Yet, when I run a full scan, it tells me all is OK.
WTF?
Any suggetions?

The reply from a Wordfence employee reads in part:

Often when we see sites get hacked despite having Wordfence, or we see them getting hacked repeatedly it’s because of a vulnerability on the server.

So they know how they promote the plugin isn’t accurate, but they continue to market it that way anyway. This is far from the only lie that we have seen from the company behind Wordfence Security. We wonder if and when the public will realize that the company behind it isn’t trustworthy?

The other thing worth noting about this situation is that it is also a reminder that Wordfence Security isn’t all that great at detecting that websites are hacked, which is also contrary to what people have been lead to believe. If it was better at that, someone could try to make an argument that while the plugin can’t stop a number of types of hack, it could provide effective mitigation against the damage caused by those hacks.

SiteLock Report Leads to False Claims About the Security of WordPress Websites

One of the problems when it comes to improving security is there is so little accurate information out there. Often times security companies are putting out misleading or outright false claims. When their information is repeated by security journalists the quality of it usually degrades from the already often low quality. As example of what happens when security journalists repeat security companies’ claims was something we recently ran across related to SiteLock.

In an article on CISO MAG the following claim was made that seem unlikely to be true:

SiteLock’s analysis also showed that a website’s content management system had an impact on overall security. Forty-four percent of websites using WordPress CMS had not been updated for over a year at the time of filing this report.

We went to look into that because that because it seemed like it would be a good example of SiteLock getting stuff wrong, but in looking at the report what SiteLock actually claim was very different. What they said hasn’t been updated in a year are plugins in the Plugin Directory:

44% of plugins in the WordPress repository have not been updated in over a year

It is important to note that doesn’t mean that those plugins are somehow insecure, though if plugins are not at least being updated to list them being compatible with newer versions of WordPress there is a greater chance that if there is a security vulnerability found that it will not be fixed promptly or at all (though in reporting many vulnerabilities to WordPress plugin developers through our Plugin Vulnerabilities service even very recently updated plugins are not always fixed in a timely manner or at all).

Making that incorrect claim seem odder is the beginning of the next paragraph of the CISO MAG article:

Nearly seven in 10 infected WordPress websites had the latest security patches installed, but were compromised because of vulnerable plugins.

If “nearly 7 in 10 had the latest security patches” then it wouldn’t make much sense that 44 percent of them hadn’t been updated in the last year.

The claim that the website “compromised because of vulnerable plugins” is also not what the report says. Instead it says:

69% of infected WordPress websites were running the latest security patches for WordPress core at the time of compromise.

This data illustrates that even when running a version of WordPress with all of the latest security patches, a vulnerable plugin or theme can just as easily lead to a compromise.

Looking at the rest of the report there were a couple of other WordPress related items that stood out. The first thing is a mention of “publications” that “inaccurately implied that WordPress websites which aren’t running the newest version of WordPress are insecure”:

NOTE: Many publications have inaccurately implied that WordPress websites which aren’t running the newest version of WordPress are insecure. As of the end of Q2 2017, the WordPress community actively provided security fixes for all versions of WordPress from v3.7 to the current v4.8. Our research takes into account each security patch release for every version of WordPress in Q2 2017. For example, WordPress v3.7.21 contains all of the same security fixes implemented in the current version, v4.8. In theory, this makes v3.7.21 as safe as v4.8.

We are not sure what publications they are referring to, but one security company comes to mind, SiteLock, which has been falsely claiming that websites are insecure when running the latest version of older versions of WordPress. We first noticed this back in September of last year and SiteLock was clearly aware of that post, but as of at least June they were still doing this.

Another element of the report repeats a WordPress related falsehood from SiteLock that we debunked in April:

Fake Plugins: Trend Maricopa

In what SiteLock Research would call an “oldie but a baddie,” we saw a trend in the first week of April that centered on the return of an old trick targeting WordPress websites where malware disguised itself as a legitimate forum plugin in the WordPress plugin directory. This ruse, while easily dispatched by specialized malware detection systems, would just as easily escape the concern of an untrained eye. Fake plugin malware iterations continue to be developed and deployed because, quite simply, most people don’t notice them. In a world where the majority of website owners don’t take a proactive approach to malware prevention or remediation, persistent infections continue to be common.

The reality is the supposed legitimate plugin, WordPress SEO Tools, has never existed, whether in the Plugin Directory or otherwise. We don’t understand why SiteLock is continuing to peddle that falsehood when it is so easy to confirm it to be false.

OneHourSiteFix’s Crazy Claims About WordPress Websites Being Hacked

Recently we got a spam comment on one of our posts that was meant to provide a link to onehoursitefix.com. The name given with the comment was “how to fix a hacked site” and the comment, which was irrelevant to the post, was:

You might be scratching your head at this point because you are
certainly not sure what tattoo. It is also a classical technique, which started out
for the dancers to seem weightless. s always preferable to let someone
know your location going and which route you.

It probably doesn’t say great things about that website, OneHourSiteFix, that they appear to need to promote themselves in that way, but that turns out to be much less concerning than the blog post we noticed linked to from their homepage.

The title of the post in the title HTML tag is “WordPress Website Defaced ? Due To A Well Known Security Company ?” and the on page title is “WORDPRESS PLUGIN VULNERABILITY MEANS MILLIONS FIND THEIR WORDPRESS WEBSITE DEFACED BY HACKERS”. The post is listed as being put out on June 26, 2017.

The first paragraph seems to be written by someone who has absolutely no idea what they are talking about:

Free open-source website and blog creation tool ‘WordPress’ has left millions of pages defaced, due to a remote code execution (RCE) feature being added to the package. This feature has allowed hackers to take control of pages using WordPress plugins allowing attackers control over editorial features in order to vandalize pages or even worse execute malicious payloads. Plugins are those great bits of extra software you can add to your WordPress site to do everything from show a map of visitors to show a fancy photo gallery. Plugins however, have always been a l known and documented ‘attack vector’ for hackers. An attack vector being ‘a way in’ or path into a website. The end result is millions of site owners have found their WordPress website defaced by hackers.

What it sounds like this person might referring to is a vulnerability that had existed in WordPress 4.7.0 and 4.7.1 that allowed attackers to change the content of posts and was fixed in January. It wasn’t a “remote code execution (RCE) feature” and there hasn’t been something like that added to WordPress. The vulnerability could have had more serious consequences if certain plugins that allow PHP code to be run in posts, which might be what the reference to plugins there is trying to refer to. There was nothing that could remotely be what is described there that happened in June, what did happen in January also doesn’t appear to have impacted millions of websites.

That explanation seems more likely based on the next paragraph (though it again doesn’t make much sense as written):

A well known security firm released a statement saying they had detected multiple hackers seizing control of sites. A backdoor in the protocol allows attackers to inject ads, spam and affiliate links. The security firm expects many more attacks to follow and even advised users to disable the plugins due to attackers using these them to insert malware into any affected website More often than not the old, ‘Hacked By GeNErAL’ ! types of defacement are being replaced by monetising hacks with compromised sites being used to make money for the hacker via the use of paid ads (selling everything from viagra, research chemicals to fake crypto currency exchanges) or redirect them to an ‘online pharmacy’
The fourth paragraph claims, which is below, would seem to confusedly reference what happened as well. As the exploitation only started after it was disclosed that WordPress 4.7.2 had included a fix for the vulnerability a week after that version was released.
What is also interesting is that before the security company released the details of the hack, very few WordPress websites had actually been compromised. The timeline in which the hack was detected, details released and then the fix released – does arouse suspicions amongst the conspiracy theorists amongst us.
The third paragraph makes a claim that seems crazy:
In March alone, over 45 million of WordPress websites were defaced and infectd. Many websites are still affected with many of their users not even realising that hidden within their blog there is a page that is selling some seedy pharmaceutical product . Often these hacked website pages are only found by using very specific search terms in google so blog owners are blissfully unaware that their sweet and innocent cupcake blog is actually harbouring a deep secret within the blog pages…
If it were true that 45 million WordPress website had been “defaced and infected” in just that month that would likely mean that a majority of WordPress had that happen to them. While the numbers seem to be a bit of an estimate, there are figures out there for the total number of WordPress websites at figures like 75 million according to a Forbes article from December. Clearly over half of WordPress websites were not hit during that month.

Another Very Odd Claim

In looking at their service there is another element that makes it sound like something is very amiss. One part of their service is cleaning up hacked websites and the other is a web application firewall (WAF) that is supposed to stop them from being hacked again. What is missing is the thing that should tie those together, determining how they website got hacked. If you don’t do that you can insure the vulnerability that was exploited has been fixed and the website won’t get hit again. That would also seem important to make a WAF effective.

Instead of doing what would actually prevent the website from being hacked again they make a claim that doesn’t sound believable:

 IN ADDITION – our security experts manually analyse EVERY element of your site – every row in your database and every line of your files is checked and cleaned. This layered approach ensures we don’t just throw the hackers off a site – we slam the door on them as well.

That would take a very long time to do on most websites, yet somehow they are also going to fix the website in an hour, and it would likely be very ineffective since the sheer amount of information being reviewed would make it less likely that someone would spot a real issue among everything else.

On the page about their cleanup service there was a linked review that while giving them five-stars and seemed positive, indicated that this person’s websites have been repeatedly hacked:

Always quick, always clean.

OneHourSiteFix staff goes above and beyond everytime we’ve had an issue. Quick service, speedy cleaning, and even making sure sites like Google rank you site as safe again. We can’t thank them enough for keeping our servers from getting shut down by our service provider due to infections/spam. Top notch, our go to company for website cleaning everytime! Need help, look no further!
Which isn’t surprising based on what else we saw.

Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from WordPress.org asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by WordPress.com, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin: