SQL Injection Attacks and Defense - 2009

220 Chapter 5 • Blind SQL Injection Exploitation
Introduction
So, you’ve found an SQL injection point, but the application gives you only a generic
error page. Or perhaps it gives you the page as normal, but there is a small difference in
what you get back, visible or not. These are examples of blind SQL injection, where you
exploit without any of the useful error messages or feedback that you may be used to,
as you saw in Chapter 4. Don’t worry; you can still reliably exploit SQL injection even
in these scenarios.
You saw a number of classic SQL injection examples in Chapter 4 that relied on verbose
error messages to extract data, and this was the first widely used attack technique for data
extraction in these vulnerabilities. Before SQL injection was well understood, developers
were advised to disable all verbose error messages in the mistaken belief that without error
messages the attacker’s data retrieval goal was next to impossible to achieve. In some cases
developers would trap errors within the application and display generic error messages,
whereas in other cases no errors would be shown to the user. However, attackers soon realized
that even though the error-based channel was no longer available, the root cause still
remained: Attacker-supplied SQL was executing within a database query. Figuring out new
channels was left to the ingenuity of the attackers and a number of channels were discovered
and published. Along the way, the term blind SQL injection entered into common usage with
slight differences in the definition used by each author. Chris Anley first introduced a blind
SQL injection technique in a 2002 paper that demonstrated how disabling verbose error
messages could still lead to injection attacks, and he provided several examples. Ofer Maor
and Amichai Shulman’s definition required that verbose errors be disabled but that broken
SQL syntax would yield a generic error page, and implicitly assumed that the vulnerable
statement was a SELECT query whose result set was ultimately displayed to the user.
The query’s result (either success or failure) was then used to first derive the vulnerable
statement and then to extract data through a UNION SELECT. Kevin Spett’s definition was
similar in that verbose error messages were disabled and injection occurred in a SELECT
statement; however, instead of relying on generic error pages, his technique altered content
within the page through SQL logic manipulations to infer data on a byte-by-byte basis,
which was identical to Cameron Hotchkies’ usage.
It is clear that blind SQL injection has received significant attention from attackers, and
its techniques are a key component in any SQL injection arsenal; however, before delving
into the specifics, we need to define blind SQL injection and explore the scenarios in which
it commonly occurs. Toward that end, in this chapter we will cover techniques for extracting
information from the back-end database through the use inference and alternative channels,
including time delays, errors, domain name system (DNS) queries, and HTML responses.
This will give you flexible ways to communicate with the database, even in situations where
the application is catching exceptions properly and you do not have any feedback from the
Web interface that your exploits are working.