Backups Made With WordPress Plugins Might Not Back Up All of Your Website

When it comes to dealing with a hacked website, one of the recommended solutions is to revert the website to a clean backup. There are multiple possible issues with that, including not knowing whether a backup is clean or not, as well as that reverting to a backup doesn’t resolve the underlying issue that caused the hack in the first place.

Another problem we noticed while dealing with a recent clean up of a hacked WordPress website is that backup plugins for WordPress don’t necessarily backup of all the website if there is content that isn’t handled through WordPress. While that makes sense from the perspective of the backup plugin, it is something that is necessarily going to be thought by those using them, until they run into a problem that requires the backup.

Whether that situation applies to your website or not, it is a good idea to check to make sure that backups being made are complete, as you can also run into issues with backups being incomplete for other reasons.

Wix Doesn’t Currently Support Importing WordPress Websites or Blogs

One of the services we offer is to do transfers of websites from one web host to another, though we often have people that contact us about this service looking to transfer the content of a website to or from a website design platform, like Weebly or Squarespace. We recently had someone contact us about moving a WordPress based website to one of those platforms, Wix. We did a quick to see if it was possible to do that, so we could at least let them know if that is possible, even though we don’t offer that. After we did that we tried to email them that information, but it turned out they hadn’t provided a valid email address, but we can at least share this information with others.

Currently Wix doesn’t support importing websites in to their service:

Currently, importing a site created outside of Wix is not supported.

They also don’t currently support importing blog content in to their service either:

Currently, importing blog content or data from an external source or blog is not supported.
So either you would need to do the transfer manually or look for a third-party solution for that.

These Security Rules Are Not an Indication Your WordPress Website is Hacked

Recently we mentioned the importance of security companies checking to make sure that websites they are being contacted about cleaning are in fact hacked. The reason for that is often problems unrelated to a hack are believed to beloved to be caused one, leading to people looking for unnecessary cleanups.

In one reason situation the person who contacted us was sure that their WordPress website was hacked due to rules (or code) in the web.config, which is a configuration for websites being hosted on IIS web servers, for the website that actually were there to protect the website.

As an example of what was at issue, the following rule would restrict accessing .php files in the WordPress uploads directory, which would prevent a hacker from running code if they could upload .php files through some vulnerability:

<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

The rules may have been generated by the Plesk control panel.

Here are all the rules in question in case someone else is searching for information on this:

<rule name="Block wp-config.php for WordPress instances" enabled="true" stopProcessing="true">
	<match url="wp-config.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-includes for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-includes/.+\.php" />
	<conditions>
		<add input="{REQUEST_URI}" pattern="^/wp-includes/js/tinymce/wp-tinymce\.php$" ignoreCase="false" negate="true" />
	</conditions>
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>
<rule name="Deny scripts from wp-content/uploads for WordPress instance #6" enabled="true" stopProcessing="true">
	<match url="^wp-content/uploads/.+\.php" />
	<conditions />
	<serverVariables />
	<action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />
</rule>

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 in with 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.