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…
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.
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!):
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”>
<title>MySQL Fatal Error</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=windows-1251″/>
font-family: Verdana, Arial, Helvetica, sans-serif;
<font size=”4″>MySQL Error!</font>
<u>The Error returned was:</u>
<strong>Table ‘servtst_test.sploits’ doesn’t exist</strong>
<textarea name=”" rows=”10″ cols=”52″ wrap=”virtual”>UPDATE `sploits` SET `loads`=`loads`+1 WHERE id=7</textarea><br/>
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:
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