The
techniques we've discussed in this article regarding blind SQL
injection enable the extraction and retrieval of database contents in a
highly automated manner using either inference techniques or
alternative channels. A number of tools are available to help an
attacker exploit blind SQL injection vulnerabilities. We'll discuss
five popular tools in the following subsections.
Absinthe
The
Absinthe GPL tool (previously known as SQLSqueal) was one of the first
automated inference tools in widespread use and is thus a good starting
point for examining automated blind SQL injection exploitation.
URL: www.0x90.org/releases/absinthe/
Requirements: Windows/Linux/Mac (.NET Framework or Mono)
Scenario: Generic error page, controlled output
Supported databases: Oracle, PostgreSQL, SQL Server, and Sybase
Methods: Inference response-based binary search; classic errors
Absinthe
provides a handy GUI that enables an attacker to extract the full
contents of a database; in addition, it contains enough configuration
options to satisfy most injection scenarios and can utilize both
classic error methods and response-based inference methods for data
extraction. The response string that differentiates between two
inference states must be easy for Absinthe to identify. One drawback to
the tool is that the user cannot provide a customized signature for TRUE or FALSE states. Instead, the tool attempts to perform a diff on a TRUE and FALSE
request, and this causes the tool to fail in cases where the page
includes other data not influenced by the inference question. One
example is in search pages that echo the search string back in the
response. If two separate but equivalent inference exploits are
provided, the two responses will each contain a unique search string
rendering the diff meaningless. There is a tolerance you can fiddle with, but this is not as efficient as providing signatures.
Figure 1 shows the main Absinthe screen. First, you select the injection type, either Blind Injection or Error Based, and then choose the database from a list of supported plug-ins. Enter the Target URL along with whether the request is formatted as a POST or a GET. Finally, enter in the Name textbox each parameter that should be contained in the request, along with a Default Value. If the parameter is susceptible to SQL injection, select the Injectable Parameter check box; also, select the Treat Value as String check box if the parameter is of type string
in the SQL query. Do not forget to add in all parameters needed for the
vulnerable page to process the request; this includes hidden fields
such as __VIEWSTATE on .NET pages.
Once the configuration is complete, click Initialize Injection.
This sends a bunch of test requests to determine the response
difference on which the inference will be based. If no errors are
reported, click the DB Schema tab, which displays two active buttons: Retrieve Username and Load Table Info.
The first button will retrieve and display the database login used by
the vulnerable page and the second button will retrieve a list of
user-defined tables from the current database. Once table information
has been loaded, click a table name in the tree view of database
objects and then click Load Field Info, which will retrieve a list of all column names in the selected table. As soon as that has completed, click the Download Records tab, provide an output filename in the Filename textbox, select the columns you wish to retrieve by clicking the column name and then clicking Add, and finally click Download Fields to XML.
This will dump the selected columns to the output file, producing an
XML document containing all rows from the selected columns in the
target table.
BSQL Hacker
BSQL
Hacker utilizes a number of inference techniques to enable the attacker
to extract database contents, and is experimental in many of the
approaches it implements. Although it is still in beta, there are
numerous nifty features that bear exploration.
URL: http://labs.portcullis.co.uk/application/bsql-hacker/
Requirements: Windows (.NET Framework)
Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors
Supported databases: Access, MySQL, Oracle, and SQL Server
Methods: Inference time-based modified binary search; inference response-based modified binary search; classic errors
BSQL
Hacker is a graphical GPL tool designed to make exploitation of blind
SQL injection vulnerabilities trivial by separating attack templates
from the injection strings required to extract particular items from
the database. It comes with templates for different types of blind SQL
injection attacks against three databases and also stores exploits to
extract interesting data from the databases. The tool is designed to be
used by novices and experts alike; for the former an Injection Wizard
is provided that attempts to figure out all the details of a
vulnerability, and for the latter full control over the exploit string
is provided.
At the
time of this writing, BSQL Hacker is still in beta and is not
completely stable. The Injection Wizard did not correctly derive a
working exploit in most scenarios I tested and the Automated Injection
mode did not work for Oracle or MySQL, and worked only partially for
SQL Server. Given the vicarious nature of real-world vulnerabilities
the tool makes a decent effort to help the attacker out; however,
sometimes exploitation is achievable only with human insight. Other
minor nuisances include memory bloat and a crowded interface that has
interdependent options in different locations, but all in all the tool
does support a large number of attack techniques against three popular
databases, and its multithreaded model speeds up injection attacks.
After loading the tool, click File | Load
which brings up a file selection dialog containing a list of template
files for various databases. Each file contains a template for a
specific technique; for example, Template-Blind-ORACLE is used for a
blind attack against an Oracle database. Select the file matching your
database; if a second dialog is loaded enter the full URL of the
vulnerable site, including GET parameters, and click OK.
The Target URL textbox on the Dashboard tab will be populated with the attack template that was loaded from the file. Edit the Target URL such that the attack template fits the vulnerable page. For instance, when loading the Blind-Oracle template, the Target URL textbox contains the following URL:
http://www.example.com/example.php?id=100 AND
NVL(ASCII(SUBSTR(({INJECTION}),{POSITION},1)),0){OPERATION}{CHAR}--
Any
strings within {} are “magic variables” that BSQL Hacker replaces at
runtime. For the most part, we can leave these alone; instead, we will
change the URL from www.example.com to the vulnerable site along with the GET parameters (for POST requests, use the same request string, except place the parameters and their values in the Post Data table on the Request & Injection tab):
http://www.victim.com/ora-nondba-exception.jsp?txt_search=MadBob' AND
NVL(ASCII(SUBSTR((SELECT user from
dual),{POSITION},1)),0){OPERATION}{CHAR}--
Notice
that we replaced {INJECTION} with “select user from dual” in addition
to the other changes; the Oracle injection template was flawed, so it
was possible to issue only specific queries.
Once the URL is configured, select Oracle from the drop-down list in the toolbar (Figure 2). If the inference method is not response-based, you can perform further configuration on the Detection
tab. Otherwise, BSQL Hacker will attempt to determine the difference in
responses automatically. This automated detection suffers from the same
limitation as Absinthe, but BSQL Hacker will also accept user-supplied
signatures, unlike Absinthe.
Now that you have performed all of the necessary configurations, it is time to verify the settings. Click Test Injection
and a dialog should display an “Injection succeed.” message. If it
doesn't, verify that the correct database is selected in the drop-down
list and ensure that the exploit string correctly completes the
original SQL query. You can review requests and responses in the Request History pane.
Assuming all settings are correct, deselect the Automated Attacks button as these attack strings are flawed; in any case, you are just interested in the database login. Finally, click the Start button, which will execute the attack and print the extracted data into the Status pane of the Dashboard, as shown in Figure 3.
Although BSQL Hacker attempts to extract database schemas and contents
automagically, this feature was lacking reliability and the tool seems
best suited for specific queries.
SQLBrute
Attackers
who are comfortable with the fundamentals behind inference attacks use
the SQLBrute command-line tool due to its lightweight nature and
straightforward syntax.
URL: www.gdssecurity.com/l/t.php
Requirements: Python (Windows/Linux/Mac)
Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors
Supported databases: Oracle and SQL Server
Methods: Inference time-based binary search; inference response-based modified binary search
SQLBrute
relies only on a Python interpreter, and at 31 KB it is tiny compared
to the other tools examined. This makes it ideal for focused injection
scenarios or where file size is important, and its thread support
boosts speed. A drawback is that it uses a fixed alphabet from which
inference tests are drawn; if a byte in the data is not contained
within the alphabet it cannot be retrieved, which limits the tool to
text-based data.
To run the tool, you will need the full path to the vulnerable page along with any data that must be submitted (either GET or POST parameters). If you're using the response-based mode, you must supply a regular expression in the --error argument that indicates when the inference question returns false; otherwise, the timing-based mode is available. In the example depicted in Figure 4,
SQLBrute has been run in response-based mode against a vulnerable SQL
server, and two table names have been extracted from the database.
Based on our exploration, we know that when an inference question
returns FALSE,
the page contains “Review count :0”, but this could also be a regular
expression instead of a fixed string if needed. After execution
commences, the tool performs a little bit of fingerprinting and starts
to extract data and print it to the screen.
SQLBrute is best suited to experienced users who favor simplicity and unobfuscated operation.
Sqlninja
Without
going through the rest of this tool's prodigious capabilities, sqlninja
does support command execution using DNS as a return channel on SQL
Server installations, and we'll concentrate on that feature.
URL: http://sqlninja.sourceforge.net/
Requirements: Perl, plus a number of number of Perl modules (Linux)
Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors
Supported database: SQL Server
Methods: Inference time-based binary search; alternative channel = DNS
The user implements the
channel by first uploading an executable helper program onto the
vulnerable database's operating system. Once that's in place, he calls
the helper application using xp_cmdshell,
passes it a domain name (e.g., blah.attacker.com for which the
attacker's IP address is an authoritative DNS server), and provides it
with a command to execute. The helper executes the command, captures
the output, and initiates DNS lookups
by prefixing the supplied domain with the output. These DNS queries
will arrive at the attacker's address and are decoded by sqlninja and
displayed. Sqlninja includes a stand-alone DNS server component which
answers queries for the purposes of eliminating timeouts. Figure 5 shows an instance of sqlninja that was used to retrieve the account under which SQL Server was running using the whoami command. Because sqlninja relies on both xp_cmdshell and file creation, privileged database access is a must.
Squeeza
The
final tool examined for automating blind SQL injection exploitation,
squeeza is a command-line tool that supports multiple methods for
extracting information from SQL Server databases, with particular
emphasis placed on the DNS channel where a reliability layer is added.
URL: www.sensepost.com/research/squeeza
Requirements: Ruby, tcpdump for DNS channel (Linux/Mac), authoritative DNS server for any domain
Scenarios: Generic error page, controlled output; generic error page, uncontrolled output; completely blind, no errors
Supported database: SQL Server
Methods: Inference time-based bit-by-bit; alternative channel = DNS
Squeeza
takes a slightly different approach to SQL injection in general by
dividing injection into data creation (e.g., command execution, a file
from the database's file system, or an SQL query) and data extraction
(e.g., using classic errors, timing inference, and DNS). This enables
the attacker to mix and match to a large degree: command execution
using timing as the return channel, or file copy over DNS. We will
focus solely on the DNS extraction channel combined with command
execution for data generation for brevity's sake.
Squeeza's
DNS channel is handled entirely in T-SQL, meaning that there is no
requirement for privileged database access (where privileged access is
available, it is used as this speeds up extraction). Obviously, when
data is generated via command execution, privileged access is required;
likewise for file copying. Squeeza also makes every attempt to be
reliable in the face of unpredictable UDP DNS packets, and has a
transport layer that ensures that all data arrives. It can also handle
very long fields (up to 8,000 bytes) and can extract binary data.
Settings
are stored in a configuration file for persistence, with the minimum
details required being the Web server (host), a path to the vulnerable
page (URL), any GET or POST parameters (querystring), and whether the request is a GET or a POST (method). Inside the querystring, the marker X_X_X_X_X_X is used to locate where injection strings are placed. Figure 6 is a screenshot showing squeeza returning a directory listing via DNS.
