About a week ago I received a very insightful email from one webmaster where he described a recent attack that his site was subject to and showed how Google’s Webmaster Tools helped him notice the hack.
With Jim’s permission, I publish this email here:
Around Dec 22 an attacker with a Russian IP deposited some files on my
webserver. My hosting provider said access was gained through a since
updated version of WordPress, although my view of the logs indicates it was
through an unsecured version of OSCommerce.
The attacker left 3 files on my server. No other files were changed. The
main domain that was attacked is http://wanlesstennis.com
the files were-
bety.php – a script with the title GoogleF#cker v1
sh1.php – some kind of redirect
The purpose seems to be to fool Googlebot into seeing non-existent links
within my domain in the generic form
I first noticed this a few days after the attack when looking at Webmaster
Tools for this domain and seeing that the top keywords had all of a sudden
changed to tiger, woods, nordgren, nfl, etc., all words that don’t even exist
on any of my webpages. Also the top search queries list pages like
formville.com, holy days of obligation catholic church, weather network
vancouver, etc., again things that have nothing to do with my site.
Once I noticed this I removed the offending files.
From that point on the number of reported Not Found errors in WMTools
started increasing . . . it is over 500 currently as all of these garbage
links are no longer accessible since the php files have been removed.
While researching some of the broken links I found a few pages in community
forums in russia that had posts that contained thousands of links to these
garbage links – once such page is here
Since then I have added a line in my robots.txt file to disallow /bety.php*
which of course is causing my URLS blocked by robots.txt to start
increasing in tandem with Not Found URLs.
The upside is that this has sent me scurrying to upgrade my security, the
downside is that it will take a while to have this garbage disappear from
Jim sent me the rogue .php files and access logs for his sites. They helped me investigate the hack and now I can share the details here.
1. His sites were not the only sites hit by this attack. I could easily find similarly hacked sites using the following Google Search: http://www.google.com/search?q=inurl%3Abety.php
2. Most of the affected sites run osCommerce. Moreover, Jim’s logs proved that a known vulnerability in osCommerce 2.2 RC2a (Secunia advisory) was used to upload rogue files to his sites.
The purpose of the attack is to drive traffic from Google to these intermediary bety.php?q=keywords pages that in turn, redirect unsuspecting web surfers to scareware (fake AV) sites. Here’s a description of the trojan downloaded from one of those sites (when I downloaded it, only 4 out of 40 anti-virus tools detected it).
Hackers upload their files into directories that are writable for webserver processes. This usually means directories with 777 permissions. However on certain host that use suPHP, all user directories are writable for PHP scripts since they run with the user’s permissions and 755 cannot stop them. Moreover, if a webmaster have multiple sites (domains) under the same account, not only will they create malicious files in the site running vulnerable version of osCommerce but also in every other website with writable directories.
To detect this particular hack, scan all your server directories for the following files:
In addition to the above files, I noticed the following files created after successful attack exploiting the same osCommerce vulnerability: flop.php and fly.php (the latter executes arbitrary PHP code passed to it in a POST request)
You can also analyze your server logs (Google Analytics won’t do since rogue files don’t include the Analytics’ code). Check them for the above files. Take special attention to POST requests. You can notice attacks trying to exploit the osCommerce vulneravilities if you search for POST request to /admin/file_manager.php/login.php?a=1&action=save. (actual URL depends on the location of the osCommerse admin directory)
Finally, as Jim mentioned in his email, Google Webmaster Tools can help you detect this attack. Their “search queries” report has also proven to reveal many other security problems, so it’s a good idea to use GWT at least once a week.
You can find many more osCommerce security best practices in this thread. Among other things, the post suggests that your rename the admin directory and remove the file-manager.php file and shows how to properly do it (these two steps can save you from this file_manager.php vulnerability). Must read for osCommerce users.
If your know any other good osCommerce security resources, please share them here in comments.
In the second part, I will provide more interesting details (incuding some black hat SEO tricks) about this attack. Stay tuned.