WordPress Pharma Hack 2013 Fixed

WASHINGTON DC WordPress development company – Herndon, Virginia

Recently, one of our clients contacted us about his Google search results showing up with a notice saying that “This site may be compromised.”

That text linked to a page on Google, which provided information and steps to get rid of that notice. We followed those steps, as well as running a Sucuri security scan on the website, which suggested updating WordPress. We did so, and also installed the WP Better Security plugin, and after running the Sucuri scan again, it came up clean. Additionally, Google Webmaster Tools’ Health check reported no malware. All good, right?

Wrong. A few days later, the client came back again reporting that the Google search results were including some very strange terms beneath the page title–things that had nothing to do with his website. Specifically, the description read, “Bankers tend to individuals get back in generic cialis generic cialis proof and when these services.Payday loans are fine option available exclusively Levitra …”. Very odd, indeed.

So after doing a little research, we came across this blog post detailing a fix for a very clever security vulnerability that, in brief, modifies how your WordPress website looks to search engines, such as Google, but leaves your site alone as far as how you and your users see it. And, lo-and-behold, when we compared the page source with the source code returned by the “Fetch as Google” tool in Google Webmaster Tools, there was some extra javascript and a div, which I’ll come back to later.

Anyway, the blog post to which I just linked is from 2010, so the hack has had time to evolve from how it was described. And even though there are several, more recent blogs from other people about similar issues, our situation was different still. I suspect that whomever is responsible for this hack likes to change things up periodically so that we have to keep figuring out how to fix it.

Several of the blog posts I read talked about code obfuscating using base64_decode() and/or eval() with a string of hex values. In my case, there was none of that. It is still something you should check if you are experiencing these issues, just in case.

Here is the situation we found ourselves in. Almost all plugin folders (except the plugins installed very recently, such as Better WP Security) and almost all theme folders, as well as the wp-includes and wp-admin directories (and sub-directories thereof), we found some very suspect files. If you would like to see some of the malicious code, here is an example. For reference, almost all of the files I found looked pretty much like that, just with different specific variable names and values characters. All of the files were between 4 and 6 kilobytes and followed some sort of naming convention. Some were appended with “-locale.php” or “-meta.php”. A few were called “locale.php” or “meta.

php”. There were some “general.php” and some “api.php”. One was “category.php” and one was “class-wp-option.php” (in one of the admin directories). While you can’t necessarily rely on the files to be named like that in your specific scenario, it can save some time if you look for files that are “trying too hard” to fit in, if you know what I mean.

One very interesting thing I found was, in only one of the theme folders, incidentally the one that was being used by the client, was a file called karisa.php. This one, sprecifically, was very different from the other malicious files. It had a last updated date of this past April (so by far the most recently changed file in the folder, the rest being <= 2011) and the permissions were the same as the other malicious files, whereas the rest of the theme’s files had the normal permissions. I originally ignored it because it had a somewhat reasonable file header and looked like it could plausibly be a part of the core. However, then I actually looked at the code and checked for the file in a backup but didn’t find it. From what I can tell, it is a pseudo-cron job creator that does some odd things. For instance, one of the functions is responsible for appears to be determining the most common last updated date in the directory or (if it can’t find dates) some date in the past.

The above all happened on Day 1. However, even after deleting all of those files and putting the matter to rest for the night, when I came back into the office on Day 2, the search results were still as described before, and there was still that JavaScript code injecting the div. It took me four hours of poring back over the entirety of the WordPress installation to find the issue: somehow, some code was added to the end of the functions.php file in the custom theme we were using. Here it is. The only way I found that was by comparing the file size of that file to the size of the same file in a backup and noticing it was different. Once I deleted that code, Fetch as Google immediately stopped showing the offending source code. We’re still waiting for the Google search results to update, but that should not take too much longer.

Looking back at this whole ordeal, it took me way too many hours over the course of two days to go through the entire filesystem of the WordPress installation, look in virtually every file to locate the bad ones, and finally decide to look in legitimate files for malicious code. Near the end of that time, I realized some things to look for while searching the files to make things faster. For one, I noticed that in the wp-admin and wp-includes directories (an

d their sub-directories), legitimate files had a Last Updated or Changed date of the most recent WordPress update, whereas the malicious files had some arbitrary dates in the past. Of course, in the wp-content folder this was not as clear cut because those files were not modified when WordPress was last updated so the last changed time of legitimate files varied and was often the same as the malicious files. Anyway, if you do a sort by Last Modified, that might make it easier to pinpoint malicious files.

Another thing I suggest for streamlining the process is to download the latest version of wordpress, any plugins (both active and inactive) and any themes you have running on your site, and then open up your FTP, SCP, or whatever file transfer software you are using, side by side with your local file explorer. It might also be good to open up a backup from before the issue began. This way you can compare the number of files in each folder, the size of the files, etc. When it comes to files in wp-admin and wp-includes, all files should be identical to those in the original WordPress package. As for files in wp-content, you will need to compare them to each original plugin and theme package. If you find any *.php files in wp-content/uploads, they should be removed. Whenever you find a malicious file, download it to a local folder to quarantine it, and delete it from your remote server. This will allow you to put it back if you notice your site not running properly in case you just accidentally deleted a file you actually needed.

Also, it can save time if you keep an eye on the file permissions. In my case, all of the legitimate WordPress, plugin, and theme files had rw-r–r– and all of the malicious files had rw—-r–. While this may not be the case for you, it is still a good thing to try to sort by file permissions and last updated date.

Now that we’ve got this taken care of, here are some steps we took to prevent this from reoccuring:

  • Properly configured Better WP Security – We have it notify us when files are changed in the WordPress folders so that we can keep an eye on anything sneaky.
  • Make sure permissions are correct. Directorys should be 755 and files should be 644.
  • Follow the advice detailed here.

Do you need some help?

Let's get started. Tell us a little about yourself and your organization
and we can start a conversation about your needs and our capabilities.

Related Posts