Botnets have had a long association with mass-flood attacks and particularly with distributed denial-of-service attacks and spam.
However, criminals have changed the way they use bot agents, with larger botnets commonly used for another kind of mass-attack: exploiting Web site vulnerabilities to send commands to the back-end database, an attack known as SQL injection. While SQL injection itself is a rather old class of Internet attack, it has proved to be an extremely successful vector for compromising Web applications and retrieving confidential business data, as evidenced in the most recent court documents filed following the Heartland Payment Systems and Hannaford data breaches.
Moreover, year on year the number of SQL injection attacks have increased. The attacks rose 50 percent in the first quarter of 2009, and then doubled in the second quarter.
While most SQL-injection (SQLi) attacks have traditionally been conducted manually using automated tools, bot clients have become more sophisticated and have inherited a wider variety of plug-in features. The overall trend appears to be towards distributed attacks that leverage existing botnet infrastructures, offering efficiencies in targeted SQL injection attacks and, most importantly, massively reducing the time needed to both compromise the back-end database server and extract valuable information. As such, the probability of continued increases in database attacks is high.
Looking back, the first criminals to apply SQL injection to botnets appear to have wanted to increase botnet propagation through drive-by-download attacks. This tactic exploited the back-end databases of vulnerable Web applications to inject malicious HTML frames into dynamic page-generation repositories. At the same time, individual bot agents had to be updated with new modules capable of performing specialized SQL injection attacks. For example, in mid-2008, the Asprox botnet was updated with a module called msscntr32.exe which contained an auto-seeking database attack kit.
Early attacks would search Google for vulnerable Web applications, but the process often targeted and exploited multiple times by bot agents from the same botnet. This high degree of overlap did not matter much to botnet operators because counts of 100,000 successful frame injections were not uncommon at the time. In fact, a handful of operators managed to reach volumes of over a million successful compromises due to particularly well-constructed exploits for widespread and vulnerable Web application platforms.
Bot operators were quick to improve their SQL injection attack modules, and it was not long before the duplication between bot agents was largely eliminated. Several of the modules now distributed to, or embedded within, bot agents employ improved tactics for attacks and make greater use of command-and-control coordination. Key to this evolution is the systems ability to operate from a master list of potentially vulnerable URLs harvested from Google, which the central server doled out.
SQL injection tools and tactics have continued to evolve. Improved scripting language logic within bot agents and the adoption of more advanced scripting languages on the compromised host allow the agents some autonomy when constructing an attack. Some of this sophistication has clearly been adapted from password brute-force tactics, and some SQL-injection modules are capable of intelligently generating dynamic attack strings to enumerate and eventually exploit vulnerable Web applications. Several botnets already have the capability to fully enumerate databases of vulnerable Web applications and to automatically extract large volumes of confidential or personal data by simultaneously employing multiple bot agents against a single vulnerable Web application.
The complexity of database systems and their temperamental responses to the application of patches and security updates often results in a kid-glove approach by system operators in keeping them secure. However delays in patching backend databases and the trusted applications that interface with them are increasingly seized upon by hackers, making it critical for organizations to hone their processes and patch systems within hours of a solution becoming available.
Despite this, most database vulnerabilities exploited by SQL injection lie predominantly within the custom routines and processing logic of the public application. Organizations need to regularly assess their applications for newly introduced vulnerabilities and original attack vectors. While developing fixes for these kinds of custom vulnerabilities can take time, a mix of in-bound request filtering and backend rate-limiting technologies can help slow down or prevent many automated attack vectors from being successful while more specific security patches are tested and deployed.
Unfortunately, the bot operators hold the upper hand over those responsible for protecting corporate Web applications. The speed at which attacks can be launched using new exploit material will most often defeat those responsible for patching newly disclosed vulnerabilities. Meanwhile, the rapid pace with which even smaller botnets can brute-force database authentication credentials and enumerate a database is staggering.
In short, the SQL injection technologies used by botnet operators will continue to advance. Their design quite intentionally makes it impractical to block or filter based upon the attackers IP addresses. For the time being, its still mostly a green-field environment for botnet operators.
Organizations seeking to defuse these threats must reevaluate their Web application defenses, ensuring that any intrusion prevention systems (IPS) or Web application firewall (WAF) technologies are robust against high-volume and obfuscated SQL-injection strings. Several top-tier intrusion prevention technologies have already begun to move on from signature-based systems and have been incorporating more advanced detection algorithms.
That said, the arms war is only just beginning over this emerging technique. More heavily obfuscated SQL attack formats will continue to evolve as the technologies capable of protecting against an attack become widely deployed. Until then we can all expect to hear more frequently about data breaches due to successful botnet attacks.