Hunting the Hunters

Drive-by downloads are one of the more prevalent attacks you’ll face during your daily browsing. Some Bad Guy somewhere compromises AuntSuesKnittingTips.com such that it now has a hidden iframe on the first page that downloads something nasty that exploits a flaw in one of my browser’s plugins that downloads something even nastier that tells me that my computer has a zillion problems that can be fixed if only I’ll part with £££ for fake-AV-du-jour.

I’ll never get that sweater knitted at this rate…

One of the benefits of the NSM methodology is that you’re able to retrace someone’s steps. When we get a drive-by download, we can examine the evidence at our disposal and determine the initial point of compromise (usually a legitimate web page with a hidden iframe or obfuscated JavaScript on it).

At this point we can, if we choose, put on our malware-analysis hats and follow the initial hostile link. I’ll write about this more in a future post, but it usually involves de-obfuscating lots of JavaScript and working around anti-forensic traps that do silly things like redirect you to MSN.com if you’ve not specified the correct referrer.

Finally, you’ll reach some hostile code. This will typically attempt to exploit a number of flaws on your machine, but the Baddies only need for one of them to be successful. A successful exploit will run a tiny bit of shellcode that normally downloads and executes something a bit bigger (fake-AV-du-jour, for example).

This secondary download will come from a server operated by the surprisingly well-organised Baddies. As well as serving up the malware, they’re keeping tabs on the progress of their malware “campaigns” in terms of the number of people exposed, the percentage of those successfully exploited, the types of successful exploit, etc etc (Dancho Danchev is the man when it comes to tracking this kind of stuff down, and sites like Wepawet and Unmask Parasites are great for spotting hidden badness on websites).

If the baddies hit you with half a dozen exploits, they’ll typically use a cookie or URL token to keep track of which one actually did the damage. And so we come to today’s story.

We were investigating a PDF-based compromise – a suspected SQL Injection attack had been used to compromise a website which was now laden with hidden, hostile, iframes leading to a malicious PDF document. We had worked our way through umpteen levels of obfuscated JavaScript etc until we had reached the point where we were able to download the second-stage payload from the Baddies’ server at will. The URL looked something like this:

http://very.bad.server/fs/file7.exee

The 7 in the URL denotes to the Baddies which exploit was succesful, and it really did have two e’s in exee. Because we were able to fetch this exe at will, we could observe it over the course of time to see if the Baddies kept the exploits the same but varied the payloads. This they did; over the course of a week or so we saw these files downloaded (these links are safe to click!):

http://www.virustotal.com/analisis/8577ab81e73bdb05cad68824221e3205

http://www.virustotal.com/analisis/7e279e42b77b5c50f3f8572a2272e156

http://www.virustotal.com/analisis/ab46f8764558c0fa27ba2f120a601000

The filename reported by VirusTotal varies too, indicating that the same exes were being distributed at the same time by different means.

However, one day our download was a lot smaller than usual. A quick peek inside the file reveals plain ASCII. HTML, in fact:

<?xml version=”1.0″ encoding=”iso-8859-1″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<head>
<title>MySQL Fatal Error</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251″/>
<style type=”text/css”>
<!–
body {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 10px;
font-style: normal;
color: #000000;
}
–>
</style>
</head>
<body>
<font size=”4″>MySQL Error!</font>
<br/>————————<br/>
<br/>

<u>The Error returned was:</u>
<br/>
<strong>Table ‘servtst_test.sploits’ doesn’t exist</strong>

<br/><br/>
</strong><u>Error Number:</u>
<br/>
<strong>1146</strong>
<br/>
<br/>

<textarea name=”” rows=”10″ cols=”52″ wrap=”virtual”>UPDATE `sploits` SET `loads`=`loads`+1 WHERE id=7</textarea><br/>

</body>
</html>

Aha! An error message! The Baddies are having trouble with their malware server! Boo hoo, no sympathy from me!

By looking at the SQL, we can see how the Baddies are keeping tabs on successful exploits:

UPDATE `sploits` SET `loads`=`loads`+1 WHERE id=7

Pretty simple stuff – the 7 in our URL denotes a specific exploit, and they’re just incrementing a counter whenever it’s successful. But it’s not working – the table isn’t there:

Table ‘servtst_test.sploits’ doesn’t exist

I wonder where it went? Now, I’m not a pentester by trade, nor am I a MySQL expert, but that SQL looks like it might be vulnerable to a SQL Injection attack. I wonder if someone out there asked for this URL:

http://very.bad.server/fs/file7;DROP+TABLE+servtst_test.sploits.exee

Which might have caused it to execute the following SQL:

UPDATE `sploits` SET `loads`=`loads`+1 WHERE id=7;DROP TABLE `servtst_test.sploits`

It seems that if you live by the SQL Injection, you die by the SQL Injection. It’s just a theory, but if that’s what actually happened, it wasn’t me who did it! Anyone want to own up?


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: