Bonet SQL Injection & Conficker

Nowadays most organizations are familiar with SQL Injection - even if only as a "critical" vulnerability that happens to get the techies hot under the collar. Most CxO's I encounter understand the significance of the threat, even if they have no idea as to it's nature.

That said, even amongst most techies, the general perception is that SQL Injection is difficult and noisy - i.e. you need to understand the database/table structures to successfully hack it, and the repeated attempts to hack/enumerate the database would quickly be detected. Which, to my mind, is a rather strange (and sorry) state of affairs if that's their argument counterpoint to investing in more advanced protection.

Regardless, the real situation concerning the threat is that both arguments (or "defenses") are flawed - particularly so when you understand how botnet-based SQL Injection attacks occur.

Many people are unfamiliar with the current state of botnet-based attacks and just how advanced they've become over the last couple of years. So, with that in mind, I wanted to chat about the state of SQL Injection attacks launched from botnets.

Older SQL Injection Bots
Mid-2008 saw a number of press alerts and media stories covering the Asprox botnet (at the time estimated to be between 200k-600k bot agents) getting updated with a new module called "msscntr32.exe" which contained a automated SQL Injection attack kit. The Asprox botnet had gained notoriety the previous year due to its robust fast-flux command and control (C&C) structure that made it an incredibly reliable spam source.

At the time, the Asprox botnet was using the SQL Injection module mainly for injecting new drive-by-download iframes into vulnerable websites - thereby helping to build a bigger botnet.

The general process for Asprox (and several subsequent copy-cat botnet engines) was:

1. Armed with a "seed" SQL vulnerability (e.g. a known page type or URL parameter structure), the attack engine queries Google for other pages that contain the key words/structures.
2. A list of potentially vulnerable pages are identified within the returned search findings.
3. A preformatted SQL Injection string is constructed, and the attack engine iterates through each search finding - sending the SQL Injection exploit to each page/host.
4. Part of the exploit string contains the content that the attacker wants to inject in to the vulnerable application database - typically an iframe containing a URL that would direct potential drive-by-download victims to a host that botnet operator has prepared specially to serve Web browser exploit material and install bot agents.
   

In general, the attacks were unsophisticated. Each bot agent was largely left to its own devices to locate and attack vulnerable Web applications, and there was no intelligent load-balancing between bot agents via the C&C - so many vulnerable sites fell victim multiple times. While unsophisticated, they were quite successful - with some botnets successfully compromising hundreds-of-thousands of vulnerable Web applications.

Botnets agents like Conficker have been regularly updated with modules capable of operating in this fashion and have been observed launching these kinds of unimaginative SQL Injection attacks. Check your HTTP Web logs for User-Agent strings such as "NV32ts" to see if someone's pointed the botnet at your Web application.

Newer SQL Injection Bots
As is so typical in botnet development, "cool" features mature and morph really quickly. While the first Asprox botnets (and their clones) operated more akin to Zombie agents than bot agents, their botnet operators quickly added better centralized control of the SQL Injection mass attacks.

The SQL Injection attacks conducted by the more advanced bot agents (or downloaded malware) make better use of scripting engines and consequently are much more versatile attack platforms. A limitation of early generation bot SQL Injection resulted in the same vulnerable Web applications being hit multiple times by the same botnet - better scripting language use and more coordinated CnC overcomes this.

Consider the newer twist on the attack...

1. The bot master conducts a Google search for Web applications/sites potentially vulnerable to a new SQL Injection vulnerability. Typically this would be done via an open proxy or sacrificial bot agent so that the CnC doesn't give away it's position.
2. The bot master divides the list of potentially vulnerable sites in to batches (of the order 10-20 hosts) and allocates the sub-list to a particular bot agent along with the specific attack string.
3. The bot agent itterates its way through the batch it was given and reports its status/success to the CnC server - whereupon it is given a new batch to attack.

In this model, there is no duplication of effort and the botnet operator can change the dynamics of the attack (and iframe details) at anystage.

Blind SQL Injection
Given the pace of evolution its probable that the threat is already evolving to include blind SQL Injection tooling as well. With blind SQLi, the resultant enumeration or alteration of the backend database are not visible directly from the page's content - and the attack must effectively "brute force" it's way through an enumeration process.

The tools to conduct this class of attack have been available for a couple of years within the pentesting community - however, beyond proof-of-concept, they've never really amounted to much because it's a time consuming attack. However, given the capability to batch attack processes to distributed bot agents and improvements in CnC management systems it's now become much more feasible for criminals to launch blind SQL Injection attacks against vulnerable sites.

I haven't been asked to investigate any notable database hacks for a while now so I've not seen evidence of botnets bening used in this way to date - but from following discussions on various underground boards, the potential for attack hasn't been lost on the bad guys, so it's only a matter of time (if not already happening).

For the timebeing though, the bad guys will probably persist with single string SQL Injection attacks (i.e. send GET/POST a single string of SQL Injection commands to a server with an embedded iframe) rather than more sophisticated enumeration and data egress attacks - mainly because it's easier and there's still money to be had that way. However, I'd expect some of the more cutting edge botnet operators to up their game and pursue the data theft route in the later stages of the year - mainly because it's becoming more profitable and they've almost perfected their systems.