From: Sir Mordred (sir.mordred.lists@gmail.com)
Date: Wed Mar 07 2007 - 05:25:05 EST
Hello.
> It is necessary that some information is returned to the attacker. The
> process involved separating valid requests from invalid requests on the
> server which enable the attacker to identify these responses.
> Error responses include monitoring the HTTP 500: Internal Server Error
> messages, 'Internal Server Error' messages (which are still linked to
> valid 200 Ok responses) and any application handles errors generated by
> the SQL server.
A quite common technique is to inject a conditional with a call to
BENCHMARK() and measure the time delay. Even if the appliation handles
errors gracefully and displays no information, the time delay still
leaks one bit of information. This will also work for statements
like DELETE and INSERT. With well-prepared statements, you can do
binary search on unknown values, meaning ~16 attempts per byte
(assuming we try both the condition and its reverse and measure the
time difference between two, this can be optimised of course).
> To exploit the SQL injection, it is necessary to have identified the
> specific database in use. Normal SQL injection testing techniques, such
> as adding SQL keywords (OR, AND, etc.), and META characters (such as; or
> ') rely on the knowledge of the system that the attacker has gained in
> the afore mentioned stages.
We can identify the DBS not only by its use of syntactic characters,
but by trying to call system-specific functions.
> Without the knowledge of the system, it is not possible to determine the
> database, the entity names, relationships or any other database field.
> This is important as the attacker has to craft the Select statement
> along the lines of valid input fields. An example would be:
(snip)
> Without this information, the attacker can not hope to "guess" the
> database and entity names. Blank entries on a form do nothing to help
> identify either a database instance used or the naming structure in
> play.
Some of the DBS (MS SQL and MySQL (>5 I think) for sure) have
meta-tables with known names, which can be accessed to learn more
about the table structure. This is also another mechanism to identify
the DBS.
That said, guessing table and field names is by no means out of the
question. First, people are remarkably uninventive when they need to
name something, and second, they would often reuse the name in other
places - for example HTTP variable names for column names and script
names for table names (update_member.php?member_id=123)
Cheers,
Mordred
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:38 EDT