SQL Injection Attacks and Defense - 2009

226 Chapter 5 • Blind SQL Injection Exploitation
Choosing which technique is best for a particular vulnerability depends on the behavior
of the vulnerable resource. The types of questions you might ask are whether the resource
returns a generic error page on submission of broken SQL snippets, and whether the
resource allows you to control the output of the page to some degree.
Inference Techniques
At their core, all the inference techniques can extract at least one bit of information by observing
the response to a specific query. Observation is key, as the response will have a particular signature
when the bit in question is 1 and a different response when the bit is 0. The actual difference
in response depends on the inference device you choose to use, but the chosen means are almost
always based on response time, page content, or page errors, or a combination of these.
Inference techniques allow you to inject a conditional branch into an SQL statement,
offering two paths where the branch condition is rooted in the status of the bit you are
interested in. In other words, you insert a pseudo IF statement into the SQL query: IF x
THEN y ELSE z. Typically, x (converted into the appropriate SQL) says something along
the lines of “Is the value of Bit 2 of Byte 1 of Column 1 of Row 1 equal to 1?” and y and z
are two separate branches whose behavior is sufficiently different that the attacker can infer
which branch was taken. After the inference exploit is submitted, the attacker observes which
response was returned, y or z. If the y branch was followed the attacker knows the value of
the bit was 1; otherwise, the bit was 0. The same request is then repeated, except that the
next bit under examination is shifted one over.
Keep in mind that the conditional branch does not have an explicit conditional syntax
element such as an IF statement. Although it is possible to use a “proper” conditional statement,
this will generally increase the complexity and length of the exploit; often you can get
equivalent results with simpler SQL that approximates a formal conditional statement.
The bit of extracted information is not necessarily a bit of data stored in the database
(although that is the common usage); you can also ask questions such as “Are we connecting to
the database as the administrator?” or “Is this an SQL Server 2005 database?” or “Is the value of a
given byte greater than 127?” Here the bit of information that is extracted is not a bit of a database
record; rather, it is configuration information or information about data in the database. However,
asking these questions still relies on the fact that you can supply a conditional branch into the
exploit so that the answer to the question is either TRUE or FALSE. Thus, the inference question is
an SQL snippet that returns TRUE or FALSE based on a condition supplied by the attacker.
Let’s distill this into a concrete example using a simple technique. We’ll focus on an example
page, count_chickens.aspx, which is used to track the well-being of chicken eggs on an egg farm.
Each egg has an entry in the chickens table, and among various columns is the status column that
takes the value Incubating for unhatched eggs. The counting page has a status parameter that is
vulnerable to blind SQL injection. When requested, the page queries the database with the
following SELECT statement (where $input takes its value from the status parameter):
SELECT COUNT(chick_id) FROM chickens WHERE status='$input'