Warning: Something’s Not Right Here!

Google malware warning screen

Greetings dear readers, I was anticipating bringing you a lovely write-up of my recently purchased Amstrad 6128 Plus vintage computer tonight, instead, you’re getting an installment of “Oh my god I’ve been hacked goddammit!” – aren’t you the lucky ones eh? Indeed as I strolled confidentially to my WordPress login page earlier this evening, I was (not so) delighted to find that my site had been compromised by the catchily-named #c3284# malware virus, promoting the sudden exclamation of “Oh crap!” (well something like that anyway).

#c3284# is a delightful little beast, which upon finding its way onto your WordPress site, injects itself into one of the PHP files (in my case header.PHP) and from there will open your htaccess file (a directory level configuration file present on a Linux web server) when it’s executed and rewrite it so that your site’s URL directs your precious visitors to a dodgy website which is almost certainly selling Viagra or some form of body augmentation.

Since you almost certainly have no intention of selling Viagra to your users (face it, it’s already a crowded marketplace), this needs to be sorted and quickly. The first indication you’ll get that an attack has taken place will likely be a prompt from Google safe browsing stating that your site contains suspected malware and has been blacklisted. In fact you’ll get something that looks very much like the picture above. This is your prompt to get off your backside and log into your Google Webmaster Tools account. If you don’t have a Webmaster account already, I strongly recommend you sign up right now; it’s an invaluable tool for checking the general health of your site, along with providing a whole host of tools for analysing your website in detail, including traffic, page loading issues and so on.

If you do have a Google Webmaster account, you can quickly browse to the health section for your site, where if a problem as been detected (which it will have if Google has taken the trouble to blacklist your site) it will actually tell you what malicious code it has detected. This will look something like this:

Malware code

This is a script “cleverly” designed to elude the user of its intended purpose. Unfortunately so “clever” is the design that it actually makes it pretty blatantly obvious that its presence is anything but usual, trustworthy or desirable. Indeed, I was able to confirm Google’s finding by visiting my site and viewing the source. Sure enough, right near the top of the pages was the suspicious JavaScript boldly mocking me with its devious intentions. To quote a bunch of dudes who got stuck in a few years back, “Huston, we have a problem!”.

The standard course of action is usually to take your website offline, download a copy of the files, then use a tool such as the excellent Grep, which can search a whole load of files in a directory (including those in a sub-directory) and look for a string match. Search for all or part of the malicious code that Google has detected and with any luck Grep will swiftly list the files that have been infected. From there it’s just a case of replacing the affected files from a backup (I cannot stress enough the importance of regular backups) or if you’re well versed in JavaScript/PHP/don’t have a backup (DOH!), removing the malicious code yourself manually.

Of course in the real world things are never quite so easy and indeed this particular infection is rather more sophisticated than simply writing blatantly malicious Javascript to certain the affected files (cue disappointed “awww”). After several hours of playing around with the site, including replacing files/groups of files in my installation with known good ones and replacing the database with a clean one, I was finally able to narrow down the location of the malicious code to the header.PHP file. Looking through the code I came across this very suspect piece of PHP code there:

#c3284d#
echo(gzinflate(base64_decode(“dVr7c9s2tv5XnB86pCPaIZ4EK8F30iS97fY6aZrdtruezA4tUSJtiVR etc.

What do we have here then? Well, essentially this is a piece of Base64 (binary data encoded as a string of ASCII characters) compressed data. When the PHP file is executed, it calls the PHP gzinflate function (which is a PHP version of the popular Unix/Linux Gunzip compressor) which then deflates the Base64 code into a malicious Javascript script which is then promptly executed, resulting in the aforementioned redirection changes being made to the htaccess file – phew! The clever part is that it’s only once the code has been unpacked that the true identity of the virus is revealed, which explains why a string search failed to reveal it but a Google crawl did. As a side venture, the virus had neatly duplicated itself across all of the installed themes and almost certainly used the wp-head() PHP tag to find a suitable injection location.

So code isolated, it’s simply a matter of removing it. The delete key is my preferred tool for the job, though equally the backspace tool can be used to similar effect. Remove the code, upload the file back to the server and check the page source again to confirm that the code is now clean – job done. Ironically, since my sites run on an IIS Windows server, I lack the vital htaccess file required by this virus to deliver its payload, so I’m effectively immune to this type of attack (perhaps explaining why all other online malware scanners failed to pick it up…). However, since the site’s source (at the time of scanning) did contain malicious JavaScript, htaccess file or no htaccess file, Google will (quite rightly) blacklist it anyway.

Now the site is clean, how can an attack like this be prevented in the future? Well, usually as a matter of course, excluding the ‘Content’ folder, I set access to all of the files on my WordPress sites to read-only (i.e. set permissions of the files and thus those of the web-server account to read only). For pretty much all WordPress day-to-day tasks such as writing posts this doesn’t matter since WordPress writes most of its information to the database. Obviously read-only will prevent you from being able to edit the structure of site itself, i.e. update plugins or install new themes. For that you will have to re-enable write access for a short time. In my case I’d stupidly forgotten to re-enable read-only support after I’d made some theme changes so the virus had a potential way in.

It’s also wise to install a few of the various firewall and security plugins that are available. My favorites include OSE Firewall and Wordfence. These won’t always prevent an attack, but they can secure your site against some of the more common attack types. It’s also important to keep your themes and plugins up-to-date and be wary of free themes that use a lot of JavaScript, these can be poorly written with JavaScript that doesn’t validate input, which can lead to all kinds of security holes.

Following an attack, it’s always a good idea to give your host a quick call to report the issue and get them to run a scan on their server. If you’re on a shared site, there is every chance that another site on that server is infected and in that case it may well be possible for the malware virus to gain access to an account with sufficient privileges and write to your files using an account that has write privileges. While your at it, change your FTP password. Finally inform Google (via the Webmaster Tools) that your site is now clean. This will prompt them to automatically run another scan and if indeed if they confirm this is the case, it will be removed from the blacklist.

So there you go, sadly no write-up on the Amstrad Plus, but alas all is not lost, you now have the benefit of my several hours delving into the dark recesses of the world of hacking, which has hopefully revealed some of the tricks the hackers use and will save your some time should you ever come up against this nasty little bugger, or maybe its brother, cousin or mother, at some time in the future.

Thank you and goodnight!

Comments
2 Responses to “Warning: Something’s Not Right Here!”
  1. Phil Emerson says:

    I saw this beasty just last week as I had to disinfect a Joomla-based website with a very dirty .htaccess file.

    The most annoying part was having to find the entry point as every time I cleaned the .htaccess and saved it, it became reinfected within minutes. Once the infected script was located and dealt with it was soon sorted. Now, if only Google would reclassify the site, the client will be happy again. :)

  2. endangermice says:

    Yes it has been been infecting a lot of sites recently – the attacks usually originate from Russia. I think in this case it got in via FTP, and since I changed the password all has been well though I’m running practically the whole site in ReadOnly mode.

    Running on a Windows IIS server I don’t have the htaccess file but of course the suspect code is still there for all to see!

    The best protection in most cases is regular backups. No WordPress install or combination of plugins can make a site invulnerable, the best we can do is make it very hard!

    Google usually removes its warning messages fairly quickly once you submit a review. On the times I’ve had to do it they usually remove the warnings within 24 hours.

Leave A Comment