WordPress Exploit Immunization

by Seeker7  (seeker8306@gmail.com)

For years I have used the WordPress platform to design and run multiple personal websites.

It is a simple platform to set up and generally has the flexibility that I need to configure and run a website that will fit my needs.  Many other people use the same platform for their websites due to its simple one-click installation design from cPanel on most shared hosting platforms.

Overall, it is a great way to set up and run a website.

The only problem with this simplicity of installation and the multitude of plug-ins, themes, and options is that when something goes wrong, or the site gets compromised, nobody knows what to do.

Most shared hosting companies such as Bluehost, DreamHost, or GoDaddy (yes, I included them), despite their various levels of customer service, either do not offer services to help users with virus, malware, or cross-site scripting attacks or they charge a greater amount for a virus scanning or malware service.  This leaves the actual users with very little options in terms of fighting an ongoing attack or infection on their website.

This was my scenario.

About a year ago, someone began injecting malicious PHP code into the headers of my website.

This code automatically directed a visitor's browser to a JAR file on another site containing a virus.  I deleted all of my site files and uploaded clean ones, only to have the same thing happen again.  I changed every password and did a full reinstall of WordPress with new database names and passwords - no dice.  I even switched web hosts, which stopped the problem for only a month.  Whoever this was and whatever they were doing, they were getting around every possible attempt I made to correct their exploits on my site.

I finally dove deeper into the problem and found a solution.

However, I had to find a solution on my own, as most of the sites having solutions for the problem only gave steps I had already tried.  I will now present to everyone what the exact cause of my particular problem was and the steps I took to resolve and prevent further issues.  It might not be foolproof, but it worked for me.

The Root Causes

A Base64 eval() attack initiated through cross-site scripting.  O.K., let me break that down a bit.

The Base64 attack is one that can actually be used against virtually any PHP/SQL-based website, not just WordPress.  A string of code is inserted into the index of a theme file or another PHP file in the website.

The code will look like the following:

(base64_decode("lots of jumbled characters"))

What this essentially tells PHP is this: "This is a 64-bit string of code.  Please evaluate it and execute any commands within it."

There are sites such as www.opinionatedgeek.com/dotnet/tools/base64decode, which will allow a user to copy this text from their website and translate it back into what the code actually says, giving the web address of the redirect and/or other vital information about what the code in question does.  It is also helpful because once a user finds the web address, they can run a WHOIS lookup, find the host or nameserver, and report it.

A cross-site scripting attack is when someone makes it appear that a change has been requested by one of the existing files in your website.  Your website thinks it has gotten a request from a theme file to be edited, however, the request is not coming from the file itself, but from another computer or server somewhere else.  In my case, this was how I could change every password I had and yet kept getting infected/exploited.

The Fix

If a WordPress site has been compromised, there are several steps that need to be taken to rid the site of the infection for good.  Some involve plug-ins that, in fact, should be used to secure non-infected sites as well.

First, get clean versions of WordPress, all of the plug-in files, and the theme you are actually actively using on the site.  As it turns out, the cross-site scripting attacks tend to happen on themes and plug-ins that are not being used, so a user shouldn't plan to re-upload anything that isn't currently being actively used by their site.

The user will also need to download the configuration file from their existing installation via FTP.  This file may be infected, but the user will need the SQL database name and password in this file to make a clean version.

The second step is to download some additional plug-ins that will be uploaded with the clean files:

Virus Scanner:  Performs a daily scan of your theme files for malicious code.  (Links)

BulletProof Security:  A quick and easy way to restrict access to specific folders on the website using .htaccess files.  It will also list your web host's suggested folder permissions, which can be updated through a FTP client by right clicking on the folder the user wishes to modify.  (Links)

Mute Screamer:  This plug-in detects and blocks cross-site scripting attacks on nonexistent plug-in or theme files.  A word of warning: it may also block legitimate admin activity on your site.

WordPress File Monitor:  Monitors any changes - authorized or unauthorized - to files in a WordPress installation.  Emails can be annoying, but it is better to be sure that only log files are being modified than theme files.  (Links)

Step three is to delete all of the WordPress files via FTP.  A user should also keep an eye out to ensure that all of the files and folders are deleted as some attackers will put a PHP file with different permissions into a folder in order to carry out the attack.

Step four is to upload all of the clean WordPress files and configurations back onto the server.  Again, upload only the plug-ins and themes that are needed for the site.

Step five is to ignore any warnings about missing plug-ins, as the plug-ins that are no longer there might still be listed in the SQL database.  Turn on/activate the BulletProof Security, Virus Scanner, WordPress File Monitor, and Mute Screamer plug-ins.

Step six is to follow every possible step in the BulletProof Security plug-in.  This will protect critical folders on the site from outside access.  BulletProof also gives users a security status page that has other suggestions for ways to improve site security.  The paid version has even more options, but the free version will work fine in this case.

Step seven is to update Mute Screamer to the latest definitions to ensure the site is protected against the most recent attack types.  Also, a user should be sure to look into the settings of Mute Screamer to fit their needs.

Step eight is to pay close attention to any emails received after the fresh setup.  There is a good chance that the Mute Screamer plug-in will pick up on the cross-site scripting attacks now that the unused files are out of the site files.  The Mute Screamer alert provides the type of attack, time of attack and, the best part, the IP address of the attack.  A user can then trace down the IP address to the website or ISP it belongs to.  They can then choose to report the IP address to the ISP/web host or, if they so choose, enact vigilante justice on their own.  Users can also block the IP address through cPanel or other WordPress plug-ins, but the effectiveness of this is questionable because the request "appears" to be coming from the user's own site.

Also, a user will want to monitor the file change emails they receive for at least the first week, in order to get an idea of which files should be reported.  It's normal to get email reporting log files and the temp files generated by Mute Screamer.  However, a user should keep an eye out for any plug-in or theme file changes not initiated by them.  Sometimes, despite thinking all unused files are deleted, there are still some hanging around, and the WordPress File Monitor actually alerted me to some files that changed which I wasn't using.  I deleted them and caught another attack before it could do any damage.

Step nine is to repeat the above process for any infected sites on the same host and/or apply the plug-ins to non-infected sites.

Again, the above steps aren't foolproof and need to be coupled with additional common sense.  A user should have complex passwords for any database and the same goes for administrator passwords.  They should also perform regular backups of all of their files and databases to ensure that if the inevitable happens, they already have clean files to upload.

My hope and goal with this article is to help those who have experienced attacks like these and to offer some overall suggestions of plug-ins and practices to make WordPress more secure.  While the attacks haven't stopped for me, they no longer affect my site and my users.  I get Mute Screamer updates from time to time, advising me that an IP has attempted to use a nonexistent file to modify my site, but the site itself remains secure.

Overall, I am happy with the results.  I only hope that by sharing the information here, I can help others avoid a week, month, or even year of suffering.

Websites are designed to get information out there and to be fun for those running them.  They shouldn't be a burden or even a fear to run.  The attacks on my site almost killed my love of poking around with websites.  I wouldn't wish that on anyone else.