Bad False Positives from Wordfence Security and Quttera Web Malware Scanner WordPress Plugins

We often have people contact us that believe that a claim that their website has been hacked is false because they ran a scanner over and it didn’t find anything. We are not really sure why they don’t ask for the evidence behind the claim and try to see if they can confirm if that is accurate or not instead of running a scanner over the website, but considering they are not doing that it might not be surprising that they are instead doing something that is likely to not produce great results.

One problem is that the even if the scanner is effective at what is attempting to scan for, it may not be able to detect the type of issue that lead to claim that the website is hacked. Let’s say a web host detects a malicious file on the website, well that probably would be be something that a scan of the website’s pages from the outside would never detect.

Another problem is lack of evidence that various scanners are actually effective at what they are attempting to scan for and from our own experience, plenty of evidence that they are not effective. One area where we have seen evidence of that going back many years is with really bad false positives that indicate that these scanners are incredibly crude, so crude in fact that if we weren’t well aware of how bad the security industry is, we would have a hard time believing that they were even occurring. Below are a couple of them in WordPress plugins that we recently ran across that show the current poor state of such tools.

Quttera Web Malware Scanner

The first comes from the plugin Quttera Web Malware Scanner, which has 10,000+ active install according to wordpress.org. In recent thread on the support forum for that someone mentioned getting a false positive for what is quite common code. The plugin will warn when matching “RewriteRule ^(.*)$ h” in a .htaccess file, which would match when do some fairly common rewriting of URLs. Just doing that rewriting is not in any way malicious. The developer’s explanation for that wasn’t that this was a mistake, but that:

We mark it as suspicious because there are multiple malware instances utilizing this technique to steal/redirect traffic from infected websites.

Simply because malware uses common coding isn’t a good reason to flag any usage of it and that will necessarily cause the results of a scanner to be of limited use.

Making it seem like the developer really doesn’t know what they are doing in general, the description for that detection is “Detected suspicious JavaScript redirection”, which makes no sense considering that type of code has nothing to do with JavaScript.

Wordfence Security

The second instance of this involves a much more popular plugin Wordfence Security, which has 2+ million active installs according to wordpress.org, that we have frequently seen people believe is much more capable than it really is (sometimes they ignored evidence right before their eyes to continue to believe that).

A thread on the support forum of the plugin Ultimate Member was recently started with:

Wordfence seems to think there is a malware URL somewhere in the file class-um-mobile-detect.php:

* File contains suspected malware URL: wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php

but on comparison, the file’s contents are exactly the same as the latest file offered on https://ultimatemember.com

Can someone comment?

In follow to a question by the developer of the mentioned plugin, the original poster wrote:

I’m using 2.0.23 but as I’ve said the file in question is identical to the one found in the latest version. So as I thought it is a false positive. Maybe Wordfence doubled up on UM after the latest malware exploit.

In reality it was just that Wordfence’s scanner incredibly crude as hinted at by another reply in the thread:

It is caused by the URL: “http://www.vonino.eu/tablets” which was reported to contain malware.

In my file, it’s only mentioned in a comment so I guess it’s safe.

What that is referring to is the following line in the file /wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php:

340
// Vonino Tablets - http://www.vonino.eu/tablets

Currently the domain vonino.eu is being flagged by Google as malicious:

That doesn’t in any way make a file that includes the domain in a commented out line in the code, which can’t run, in any way malicious. If the developer’s of Wordfence Security cared at all they could easily avoid that false positive, but considering they can get away with much worse it isn’t surprising they wouldn’t care about that. That also leaves more responsible plugin developers to have to deal with the fallout from those false claims.

The Developer of Cerber Security, Antispam & Malware Scan Gives Out Bad Advice To Push Their Plugin

When it comes the security industry around WordPress unfortunately there are many people that either don’t know what they are talking about or are intentionally peddling bad information to push products and services that provide little to no protection, while making things harder for companies that are actually doing the hard work to actually improve security.

We often run into examples of this even when we aren’t looking for them. We ran into another example just the other day when we went to look around for some information while working on a post about running into a problem with contact form due to WordPress’ REST API being disabled. That lead us to an example of someone at best not knowing what they are talking about when it comes to the basics of WordPress security while being the developer a security plugin, Cerber Security, Antispam & Malware Scan, that currently has 90,000+ active installs according to WordPress.org.

A big tell that developer doesn’t have a basic clue as to security surrounding WordPress is that a main feature of their plugin is blocking brute force attacks despite the fact that those are not happening. They also make this brute force related claim in the marketing materials for plugin:

By default, WordPress allows unlimited login attempts through the login form, XML-RPC or by sending special cookies. This allows passwords to be cracked with relative ease via brute force attack.

Saying that brute force attacks could crack a password relative ease is belied by the number of login attempts needed to actually test out all of the password combinations. Here is what we wrote about that previously:

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

The post that we had run across was “Why it’s important to restrict access to the WP REST API”. The post is riddled with errors, for example citing someone as having discovered a vulnerability they didn’t.

The general problem was that they were suggesting disabling the REST API, which not at all coincidentally they touted their plugin did, because there could be security issues with it since it is new. But that is true of anything. In reality the vulnerability they discussed in the post actually showed how WordPress does a good job in handling security in one important way, since the auto update mechanism that has been in WordPress 3.7 allows the vast majority of WordPress website to be updated to a new security release in a very short time. Normally WordPress checks for updates every 12 hours and that can be shortened when a security update is being released, so most of the websites would likely have been updated in around 12 hours. With this vulnerability there was no evidence of it being exploited until after it was disclosed that it had been fixed a week after the version that fixed it was released (while the information on this vulnerability was held back for a week, other security updates were mentioned when it was released).

The developer though put forward a very different impression:

Unfortunately, the REST API bug had not yet been fixed. That leaves unprotected millions of websites around the world. It’s hard to believe but updating WordPress on shared hostings may take up to several weeks. How many websites have been hacked and infected?

That it may take several weeks to for WordPress on shared hosting to update is actually hard to believe, since it doesn’t appear to be true and no evidence was presented to back up a claim even they claim is counter-intuitive. The developer provides no evidence that any websites were hacked before the vulnerability was disclosed as having been fixed a week before, which as far as we are aware they couldn’t have since it doesn’t appear any were. That all probably shouldn’t be surprising since the developer apparently had never checked to see if brute force attacks were actually happening before building a plugin to protect against that.

For website where the auto update mechanism was disabled or didn’t work they did get mildy hacked due to this vulnerability, but that is the only vulnerability in more than a decade that we are aware of where there was any sizable number of websites hacked (in that time outdated WordPress installation have been frequently falsely blamed for the hacking of websites by security companies that either didn’t know what they were talking about or intentionally lying to get themselves press coverage). So disabling the REST API subsequent to this vulnerability being fixed has not actually improve the security of websites in any meaningful way.

There also was the issue of the developer conflating bugs and security vulnerabilities, which is important since having a lot of bugs fixed in something doesn’t mean that there was security risk.

The downside of disabling the REST API can be seen in that, like with the other plugin we mentioned in the post from earlier this week, this plugin can cause Contact Form 7 based forms to stop functioning. This exactly the kind of downside that often isn’t considered when people indiscriminately use WordPress security plugins and services without finding out first if there is any evidence that they provide effective protection. In this case what makes this stand out more to us is that our Plugin Vulnerabilities plugin, which is designed to help protect against a real issue, is much less popular than this plugin. It could be worse though, as another security plugin just designed to protect against brute force attacks has 2+ million active installs according to wordpress.org and it not only doesn’t protect against a real threat, but contains a security vulnerability of its own.

Disabling WordPress’ REST API Can Cause Contact Form 7 to Not Work

In our work for our Plugin Vulnerabilities service we frequently need to contact developers of WordPress plugins to let them know about security vulnerabilities in their plugins (either that we have discovered or that others have disclosed) and that often means submitting messages through contact forms (not surprisingly these are often handled by WordPress plugins). We have all too frequently run into situations where the contact forms didn’t work, which seems like a good reason for people managing websites with a low volume of contacts to periodically make sure that contact forms work, otherwise you could be missing out on messages.

In a recent instance of this, a loading graphic showed up after hitting Send and then that didn’t change to a message about the form being successfully sent. Pulling up the web browser’s console showed an error:

Failed to load resource: the server responded with a status of 401 (Unauthorized)

The page that related to was /wp-json/contact-form-7/v1/contact-forms/193/feedback, which would indicate the Contact Form 7 plugin was being used to handle the contact form. Visiting that page showed the following message:

{“code”:”rest_cannot_access”,”message”:”DRA: Only authenticated users can access the REST API.”,”data”:{“status”:401}}

Based on that it seems that disabling of WordPress’ REST API for those not logged in to WordPress caused the contact form to not work. A quick search showed that message was generated by another plugin, Disable REST API, which as the name suggest disables WordPress’ REST API.

As this shows, using something like that that disables the REST API can have some serious downsides. Not surprisingly for us, while looking into this we found someone in the WordPress security industry that doesn’t seem to have a clue about WordPress security pushing disabling it (and promoting using their plugin to do it), which we will discuss in a follow up post.

cWatch Makes False Claims About Security of WordPress Themes While Touting Their Security Analysts

When we previously discussed a service named cWatch we noted how the people behind it didn’t seem to understand what they were talking about when it came to security. We recently happened to take a look at them again and found things haven’t changed. Previously they falsely claimed that it isn’t possible to fully clean up hacked websites, despite them offering to do website malware removal for free (which seems like it explains the price). This time they are making false claims about the security of WordPress themes.

In a June 11 blog post titled “Infected WordPress Themes Still on WordPress.org” they start by stating:

Having come across many exploits and vulnerabilities it is no surprise that WordPress, being one of the most common themes used, seems to be a hacker favorite.

In order to stay proactive, we researched wordpress.org Apache Subversion (SVN) and discovered some major commonalities within some infected themes.

This presents a major concern as these infected files can be quite easily installed from the wordpress.org site directly.

During the next couple of blog posts we will publish a series of articlestitled INFECTED WORDPRESS THEMES STILL ON WORPRESS.ORG, where we will share with you our findings in the hopes of helping stop the spread of these infections through awareness.

That sounds concerning, but a little odd. If there was really some issue wouldn’t they want to work with WordPress to resolve it instead of trying deal with it through “awareness”? From what we have seen of the security industry, awareness is usually a euphemism for making false or misleading security claims to get coverage for yourself and that is the case here.

The next section of the post though seems to indicate that cWatch didn’t really know what they are talking about:

The following is a list of the infected WordPress themes we have discovered:

What they are linking to there are not themes, but individual files that contained malicious code in themes. That seems like a big detail to miss, but there’s more. The first five files are from various versions of one theme, Delish. In each link the number listed is the version number of the theme. Based on that it seemed that only versions up to 1.3.3 would have been impacted. The current version is 1.6, so five of the seven “themes” they claim infected are in fact not. In fact, version 1.3.4 was released on March 31, 2015 (and did in fact remove the malicious file). So it wasn’t like this was dealt with after the claim by cWatch or even recently. There is another issue with the claim that theme was infected, which we will get to in a moment.

The two other themes are not even available anymore and it doesn’t look like they were available recently. One of them, Neworld, had the malicious file removed in a version that was released on June 8, 2015. The other theme “Elgrande (shared on wplocker.com)” never had fix released, so that is the closest there is a current issue, but it still doesn’t live up to cWatch’s claim that “these infected files can be quite easily installed from the wordpress.org site directly” since it can’t be easily downloaded from there anymore and you can’t install themes from there at all.

In looking into those themes we noticed another rather large issue with cWatch’s claims here, which they completely missed, despite it seeming like it should be obvious to anyone that claims to have the expertise they claim to have. All of the infected files have .png extension, which will cause web servers to see them as image files, so the malicious PHP code that had been in them would not run. There would need to additional code to make that code run, which is missing in all but “Elgrande (shared on wplocker.com)”. So there wasn’t a threat from the other two themes even in the versions that contained the malicious files.

What all that seem to make more glaring is at the end of the post there is this ad for cWatch:

Having security analysts as a resource to inspect and investigate all code would be ideal. Connect with us if you are looking to have a security analyst on your side for less than a cup of coffee a day.

Unless you want a security analyst that doesn’t seem mildly component, you would probably want to avoid them.

Poor Copy and Paste

The poor quality of the content of their blog isn’t a one off issue, as can be seen in another recent post. The post is odd to start with since it is about malware that was claimed to have impacted “700 WordPress and Joomla websites”. We don’t know why something like that would merit coverage, unless there was some new vulnerability that was exploited to hack those websites. Strangely the source of the hacks was not discussed at all in their post or the original source they lightly rewrote to create their post. Speaking of the original source, what really stood out to us in the post was the strange headline in the last section:

Mitigation by SiteLock

If ionCube-encoded files have not been intentionally or specifically installed by you or your developer, then any file claiming to use ionCube is likely to be suspicious since the effective usage of IonCube generally needs manual server configuration. Moreover,  cross-compatibility with varied versions of PHP is found to be minimal, thus decreasing the viability of use as malware.

SiteLock is the name of another security company that isn’t exactly known providing accurate information when it comes to this sort of thing, so you wouldn’t want to be blindly repeating their claims. cWatch though takes it further by simply lightly rewriting SiteLock’s post. Here is SiteLock’s version of the above paragraph:

If you or your developer have not specifically and intentionally installed ionCube-encoded files, it is likely that any files claiming to be using ionCube are suspicious, as successfully making use of ionCube typically requires manual server configuration. Also, cross-compatibility with different versions of PHP is minimal, reducing the viability of use as malware.

What is worth reiterating is that you have two security companies there that offer services that they claim protect websites, but they seem to be uninterested in how these websites were hacked, despite the obvious relevancy to what they claim to offer. In reality SiteLock at least actually thinks that protecting websites involves leaving them vulnerable to being hacked, they are not alone in that belief.

Data on Previous Logins Stored in Database Can Help Determine How WordPress Websites Were Hacked

While trying to determine how websites are hacked is one of the three important components of a proper hack cleanup, what have seen is that many security companies fail to even attempt to do that. There are a number of possible reasons why that is, including people doing work they don’t have the necessary skills to handle (which seems to be a general issue when it comes to web development) and security companies realizing they can get away with cutting corners even if produces a bad result of their customers. Another possibility, though one that would assume that these companies had ever attempted to try to actually do things properly, is that often important evidence is no longer available once you are bought in to clean things up and therefore your ability to say with certainty what happened will be limited.

One of the most important items to have access to determine how the website was hacked is logging of requests for the website. In some cases though there is only logging available for requests made to the website from within the last 24 hours, while the hacker may have first gained access days, weeks, months, or even years before that.

Depending on the software being used on a website there may be separate logging made by it that is still available even if the other logging is no longer available. For example, Drupal logs recent events including logins and provides the username and IP address that was used to log in. That is stored in its database and then viewable through the admin interface of the software.

For WordPress websites there are plugins that provide similar capability to Drupal’s built in logging, but one of those isn’t likely to have been installed on a hacked website before it was hacked. But it turns out there is a more limited logging of logins that is stored in the database. That has been helpful to us as it has allowed us to be able to provide better information on what has happened with hacked WordPress websites we have been hired to clean up, so we thought it would be worthwhile sharing information on that, using a website were recently cleaning up as an example.

With WordPress, data on user accounts is stored in two tables in the database. The first _users includes the basic details on the accounts, like the username and when the account was created. That info looks like this when viewed in the phpMyAdmin database administration tool:

Additional user data created by WordPress and plugins is stored in the _usermeta table. One of those is the session_tokens, which is data to keep track of logins. An entry of that looks like this in phpMyAdmin:

The user_id value in that is the equivalent of the ID value in the _users table. So that entry would relate to the user “admin” shown before.

The full value of meta_value entry there is:

a:1:{s:64:"[redacted]";a:4:{s:10:"expiration";i:1528715599;s:2:"ip";s:14:"139.228.121.62";s:2:"ua";s:77:"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/D47D";s:5:"login";i:1528542799;}}

For the purposes of trying to get better understanding of a hack, two pieces of that are usually of importance.

The first is the listing of the IP address that the login came from. Which looks like this  ‘”ip”;s:14:”139.228.121.62″‘ in our example. The IP address there is from Indonesia, which isn’t where anyone should have been logging in to this website should be coming from.

The second is the listing of when the login occurred.  Which looks like this  ‘”login”;i:1528542799’ in our example. The time value there is in Unix time, which can be converted to normal date and time format using a tool this one.

With those two things you can gather more information on what accounts where recently logged in to and from where. That is particularly useful in confirming that a hacker had access to admin area of WordPress and then you can use data from the _user to get a better idea of how they might have gained access.

With that website we could see that a hacker was able to log in to a legitimate WordPress admin account and also had logged in to another account that was created after the hacking had started.

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.