Clean Up “Cannot redeclare” Hack
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
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:
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
- include long strings of encoded gibberish
- consist of
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 Smashing Magazine’s 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.
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.
Got nailed with the timthumb vulnerability a few weeks ago! Pain in the proverbial but managed to fix things quickly with a little help from @danfast, great end to your post on ‘Securing your WordPress site’ ;-)
So what is the vulnerable file that allowed this to happen in the first place?
I see no point in going through fixing all the files unless I know how they got in the first place.
Is this exploit known yet?
Great questions. More info is needed about the mechanism behind this exploit, but at this time it looks like the root cause is an insecure hosting environment (e.g., shared hosting). For example, the attacker finds an exploit through some site on a shared server. Once access is gained, every site/file on the shared account is vulnerable. So there may or may not be a “vulnerable file” per se, and if so, it may only exist on one site on the server.
The point in cleaning up a hacked site is to prevent the attackers from doing further damage by running malicious scripts from your site (sending spam, cloaking links, phishing, etc.). As discussed in the article, first clean up the mess and then tighten security as much as possible, starting with better (non-shared) hosting, if possible.
All shared hosting is not created equal, and there *are* hosting companies who care about security. Any host worth anything is going to have suPHP/open_base_dir/etc enabled, so that in the unlikely event one account is compromised, that’s as far as it goes.
It bothers me to see a blanket statement implying that all shared hosting is a security risk, just as it bothers me to read comments on support forums of open source scripts, where the “support” people tell their users that if the host has “disabled x,y,z due to security, then find another host who will allow it.”
Typically those are the type of scripts (with sloppy coding) that get hacked. And then, of course, it’s the web hosts’ fault.
Hosts have a responsibility to provide a secure server environment. Developers have a responsibility to write secure code. And users have a responsibility to make informed choices on the software they install, and to be a part OF securing their site by using common sense (using secure passwords, updating scripts, etc).
I can list dozens of major data breaches from large companies…who clearly weren’t using shared hosting.
So please. Stop taking the easy way out and just blaming the hosting company, k?
You’re absolutely right, Mara. This is not a problem (yet, knock wood) on sites I manage on good, reputable hosts.
But clients who stuck with sketchy hosting against my recommendations are suffering.
In at least one case of this specific exploit I’ve read so far, one of the affected users found a root-privilege-escalation exploit on the server. So the hacker got access to some account, elevated himself to root, then hit every site on the server.
The root-exploit in question was fixed in Linux 2 years ago or so. So the server OS installation running hadn’t been updated in at least that long. Sorry, but that’s a hosting company flub.
Security has many aspects. You do need to make sure your hosting company is on top of the ball as well.
thanks for the info, to bad to hear that it’s not an explicit exploit that can easily be patched. Thankfully i run my own servers, never use ftp, and never ever upload skanky themes or plugins. I’ll keep my fingers crossed that they leave me alone this time. Timthumb was a nightmare last time and I don’t look forward to another day like that one.
I’ve posted a blog post with a decoded version of the
eval(gzuncompress(base64_decode(code posted above, as well as a writeup on how I decoded it. Hope it’s useful for someone. :)
Dude, nice. :)
Based on your work, it looks like “Cannot redeclare” and “TimThumb” are closely related, if not variations of the same hack.
Either way, thanks for taking the time to shed some light on it.
Glad you found it useful! I thought it’d be a good topic for a blog post, haha.
They could be related – The TimThumb hack let attackers run any PHP code on the server. The PHP code ran could easily be code that left this payload behind.
Unfortunately, decoding the payload rarely gives any insight into the exploit being used. Those are easily de-coupled, and so often you’ll see multiple exploits using the same payload. So, probably not related to the TimThumb thing at all, really, other than similar payloads.
Yeah, that was what I was trying to say, although I didn’t say it very well. What I was trying to say what that because the TimThumb exploit let people run any PHP code on the server, they could have left *any* payload behind. This could have been one of them.
this happened to many times;at that i thought it was error setting up on multiple WordPress sites.Anyway this isn’t happened to my ordinary Wp’s
Great article :)
what’s that program that you are using to search inside the files? (That program in the screenshot.)
Nice info ….keep it up…..:)
Nice, thank for the tut :).
Nice info…..keep up the good workAnd by the way you can have a look at my blog too if you would like.
And have a great day mate.