Pharma Hack: Infected Again but Resolved

Damn I was infected by the Pharma hack yet again. While my web site content was without error, page titles into Google were being hacked, appearing as if I was flogging pharmaceuticals. I assure you that I do not do this. Google stated that my site might be infected, yet in Google Webmaster Tools they saw no malware and there were no fetch errors. This time I found four offending files and two offending SQL table entries. Here’s what I found and how I found them.

The first time I was infected with the Pharma Hack I upgraded WordPress and it seemed to fix itself but I could not find anything irregular, making me very uneasy. To not find the offending files means the virus was still there, possibly dormant. I added a bunch of security plugins, all of which did not prevent reinfection. I understand that hack strategies change and so should these tools.

This time I used Google Webmaster Tools. They stated that I had no malware, but a Google fetch yielded this for my front page: no content! This is not good nor correct.

HTTP/1.1 301 Moved Permanently
Date: Tue, 10 Jul 2012 11:54:10 GMT
Server: Apache
X-Pingback: http://dontai.com/wp/xmlrpc.php
Location: http://dontai.com/wp/
Content-Length: 0
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

As I have gone through the research on how to fix the Pharma Hack, I was somewhat familiar with the cleaning process. This time I downloaded WordPress and all my plugins into a directory on my computer and used my FTP client to compare the number of directories, file names, and file sizes. In this side-by-side comparison within the FTP client I was able to find four files that were extra. These files I have now moved to a quarantine area away from my WP directory. All these files were located in my plugins directories.

None of these extra files contain the text “eval(” or “base64”, as stated in some older web articles on the Pharma Hack. New strategies have been used.

I also found two infected entries in my SQL table: wp_check_hash and class_generic_support, both of which I deleted.

I still do not know how extra php code was inserted into my plugins directories, but now know an efficient way to compare the defacto plugin and the plugin on my site. Automatic updates to plugins overwrite existing file names, but do not highlight nor remove files that may still be in the directory. This is a danger that has been exploited by the Pharma Hack. Maybe when plugins are automatically updated, they should check the directory and report on any extra files that should not be there.

Until we find out how Pharma Hack injects code into our plugin directories we will never be able to prevent this from reoccurring.

Addendum July 11 2012: I contacted my Site5, my ISP and they did a security report. It seems that FTP was not used in this attack. In a way this is good but it means there is still no resolution of how the virus got into my WordPress.

There is a theory that these attacks use simple comments to inject code into WordPress. You would think that WordPress would be able to screen these things out. I will check to see if my editor will only allow simple HTML and no php. The attack uses base64 to encode the attack, so all you see in the file is a mass of unreadable text. The code can also be encoded backwards. Upon injection the code is reversed, decoded and then executed. These injections are large and cannot be easily hidden in the file. If it looks large and strange, then be cautious.

Addendum July 30 2012: I believe I found the source of entry for the Pharma Hack: WordPress’ “Incoming Links” widget. When I try to configure the standard google GET request for incoming links I find links to pharma drugs from another site to mine. This is how they inject evil code into WordPress. It is interesting as well because Incoming Links are a built-in WordPress widget, so there are no plugins that can filter the content. Here is the standard Incoming Links GET request, which for my site reveals sites selling pharma products.

http://blogsearch.google.com/blogsearch_feeds?hl=en&q=link%3A[your-domain]&scoring=d&ie=utf-8&num=10&output=rss

If I go to http://blogsearch.google.com/ and type in my web address, the true “Incoming Links” links, i.e., other sites that link to my site, is displayed, and all without any connections to selling pharma products. Alas there is no way to get an RSS feed for this output. I am unsure why there are such different results pages from the Google GET request and the manual blogsearch search. If you have such divergent search results, it would be wise to turn off your incoming links, or to use a different google GET request when configuring your incoming links.

Addendum Oct 02 2012: Reinfected using ext-akismet.php, database entries include: wp_check_hash, class_generic_support