Website Security

Google Adds “This site may be compromised.” Warnings To Search Results

In the last several weeks Google has begun to show “This site may be compromised.” warnings, for websites they “believe may have been hacked or otherwise compromised”, in their search results. According to Google’s article about of the warning they have been added “To protect the safety of our users” and they recommend users “should be careful about providing personal information to the site” being flagged.

In the past when Google has detected websites they believe to be hacked and violate their Webmaster Guidelines, they have removed the websites from their index and placed a “Notice of Suspected Hacking” message in their Webmaster Tools to let the webmaster know. It’s unclear at this point if Google has replaced doing that with the new warning or if the warning is only for websites that have been hacked in such a way that does not warrant being removed for their search index. Unlike the malware warning (“This site may harm your computer.”) Google places in their search results, which sends users to an interstitial page when they click search result for an affected website, users are still able to directly access the website.

For websites which display the warning, after the hack has been removed reconsideration needs to be requested from Google to have the warning message removed. According to a post by Google employee John Mueller “These requests are processed fairly quickly (usually within a day, though it’s not possible to give an exact timeframe). “

osCommerce 2.3 and 2.3.1 Do Not Contain Vulnerability in categories.php

It was recently reported that the /admin/categories.php file in osCommerce contained a vulnerability that would allow someone to remotely add files to an osCommerce installation without. This could be used to add backdoor script, which would allow the hacker access to all the website files and the ability to run code on server. This could be used for a number of malicious purposes including added spam or malware to website. osCommerce has been a frequent target for hackers lately, mainly being used to spread malware, due to a number of security vulnerabilities in older versions. In SecurityFocus’s advisory it was stated that version 2.3.1, which is the most recent version of osCommerce, is the vulnerable version. Using the exploit code they provided we tested the exploit and we found that version 2.3.1 is not vulnerable. Version 2.3, which included fixes for a number of security vulnerabilities and a number security enhancements, is also not vulnerable. Version 2.2rc2a and probably versions older than that are vulnerable if the workaround to secure the admin area has not been applied to them.

WordPress 3.0.2 Fixes SQL Injection Vulnerability

WordPress 3.0.2, which was released yesterday, fixes a SQL injection vulnerability that would allow Author-level and above users to view any information stored in the WordPress database. This could be used to view email address, hashed passwords, and other sensitive information stored in the database. WordPress rates this vulnerability as a moderate security issue. The vulnerability existed due to the fact that the “do_trackbacks() function in wp-includes/comment.php does not properly escape the input that comes from the user”. According to Vladimir Kolesnikov, who discovered it, the vulnerability seems to have existed since WordPress 2.x. Further details of the vulnerability can be found in Vladimir’s blog post.

The new version also includes fixes for several minor cross-site scripting (XSS) vulnerabilities and a number of bug fixes.

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 One Fairly Simple Step To Keep WordPress Secure

We have seen many guides that list many steps that are claimed that you need to take to secure WordPress. There are also companies out there that will charge hundreds of dollars to secure your WordPress installation. But the truth is that there is only one fairly simple step to secure WordPress, keep WordPress and any installed plugins updated. The developers of WordPress agree with us, in blog post about keeping WordPress secure they said:

There is only one real solution. The only thing that I can promise will keep your blog secure today and in the future is upgrading.

The upgrade process involves making a backup of the websites files and database, disabling plugins, and then performing the update of the WordPress installation. WordPress provides a helpful guide that detail the process. If you are currently running version 2.7 or above, WordPress includes an Automatic Update feature that takes care of the updating part of the upgrade for you. If you are running version 2.6.5 or below, you made need to make one or more incremental upgrades to avoid potential issues. If you need help upgrading, especially if you are currently running a very outdated version, we can perform the upgrade of WordPress for you.

Will This Protect You From All Hackings?

The simple answer is no. Many hackings occur because of the FTP credentials for the website have been compromised or through a hosting provider being hacked. Nothing you do to WordPress installation will prevent these from happening because they do not take advantage of a vulnerability in WordPress. You can find our suggestion on the steps the steps you need to take to prevent those types of hackings here.

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 Sites Hosts Files Used In Attempted Hackings

Since June, Google has provided hosting for files used in attempted hackings of websites through an account with their Google Sites services. A listing of all the files hosted is available at http://sites.google.com/site/nurhayatisatu/system/app/pages/recentChanges?offset=25. Some of those files are used in remote files inclusion (RFI) attacks which seek exploit vulnerabilities in software that allow remotely hosted files to be be executed. If the attacks are successful modifications are made to website that place spam or malware on the website, or allows the hacker remote access to the website. Attempting hackings utilizing these files have occurred at least as recently as three days ago. We have reported this to Google using the “Report Abuse” link multiple times but the files have continued to remain up.