[WEB SECURITY] RE: Methods of quick exploitation of blind SQL Injection

Juan Carlos Calderon Rojas juan.calderon at softtek.com
Tue Feb 2 10:50:08 EST 2010


Hello Again Dmitry

I agree on the addition on Error Based subcategory, I forgot about that in the previous post.

Yet on Blind Sql injection searching for one symbol in one HTTP request it is not clear to me, I can figure out multiple comparisons (using WHEN statements on Sql server for example) but still it is a binary search (with multiple tests at once). Can you translate a small example in particular from Russian to English and send it to me. Y used babel fish to translate the page content but the real "sauce" is in the Slideshare presentation.

Regards,
JC



De: Dmitry Evteev
Enviado el: Vie 29/01/2010 5:27
Para: Juan Carlos Calderon Rojas; Chris Eng; websecurity at webappsec.org
Asunto: RE: [WEB SECURITY] RE: Methods of quick exploitation of blind SQL Injection


Dear Mr. Calderon,
 
Thank you for your comment. I agree with you that it is reasonable to divide SQL Injection vulnerabilities (including Blind SQL Injection class!) into Selection-based, Modification-based, and Execution-based weaknesses according to the exploitation method. As for Blind SQL Injection class, I beg to suggest the following classification:
 
Error-Based - a DBMS displays an error message, which may allow attackers to exploit a Blind SQL Injection vulnerability in some cases (similarly to the technique of applying "union" or combining SQL-queries (;)).
 
Content Change-Based - depending on the incoming values received by an application, different content is obtained (e.g. and 1=1, and 1=2). That is, Content Change-Based Blind SQL Injection represents Blind SQL Injection in the form people have got used to perceive it. It should be mentioned that an application may return much more than two (true/false) possible variants of content. It allows one to optimize vulnerability exploitation using other models than binary trees. Searching for one symbol within one http request becomes possible. See the following proof of concept (Russia): http://devteev.blogspot.com/2009/12/sqli-hackday-2.html
 
Time-based - here, everything is clear. By the way, there is an optimization method;) - considering the phonetic features of the desired data. I'm going to make a publication devoted to this theme soon.
 
Together with Sergey Gordeychik, we have defined classes of SQL Injection vulnerabilities considering the possibility of their detection with automated tools using black-box method and have compared the obtained classes with available methods of attack conduction. See the table in the file: http://www.ptsecurity.com/download/PT-devteev-FAST-blind-SQL-Injection.pdf
 
- - - - - - - - - - - - - - - 
Best Regards, Dmitry Evteev 
Positive Technologies Co. 
Tel.: (495) 744-0144 
Web: http://www.ptsecurity.com; http://ptresearch.blogspot.com/
 
From: Juan Carlos Calderon Rojas [mailto:juan.calderon at softtek.com] 
Sent: Thursday, January 28, 2010 10:25 PM
To: Dmitry Evteev; Chris Eng; websecurity at webappsec.org
Subject: RE: [WEB SECURITY] RE: Methods of quick exploitation of blind SQL Injection
 
Hello Dmitry 
 
I agree with you that what you call a "Double Blind Sql injection" is a subtype of Blind Sql Injection, then why not just call it as that. I will dare to propose a different categorization to the list:
 
1. Sql Injection. Regardless of error disclosure, they will be:
      - Selection Based. addition of more select Sql statement, e.g. Union, second recordset, etc.
      - Modification Based. Can be used to extract or tamper data in an insert or update statement. e.g. entering ' + @@version + ' or ' + user + ' when creating a record in a web app, the information will be displayed as content of the field. An example of tampering data injecting XSS or CSRF to fields. like those used for massive Sql injections.
      - Execution based. Can be used to extract information via alternative method (like file dumps or email), tamper data (both DB and OS) or perform calls to other interpreters or servers (like command line, linked servers, etc). e.g. calls to xp_cmshell SP in Sql Server or Data file dumps in MySql.
2. Blind Sql Injection. Limited Sql injection for Information extraction piece by piece, modification of information or execution of additional commands obtaining a binary type (Yes/No) response from server on successful execution:
     - Page Response Based. No = Page 1, Yes = Page 2 (which could be an application error page)
     - Content Change Based. No = Same content, Yes = Page Content Changed
     - Time Based. No = immediate response, Yes = response delayed x seconds
NOTE: In practice, there is a third answer on a Blind Sql Injection, that is, the Error response when a crafted query fails due to a syntax "mistake" or an application design "limitation, like when information returned as result of the injection is invalid for a second operation in the same page. However, that response could be seen in the format of a Server Error page (HTTP 500 error), an application error page or a page change/no-change (thus it might be used as, or confused with, a Yes or No), everything depends on the actual application implementation.
 
Regards,
Juan Carlos Calderon



De: Dmitry Evteev
Enviado el: Mié 27/01/2010 7:19
Para: Chris Eng; websecurity at webappsec.org
Asunto: [WEB SECURITY] RE: Methods of quick exploitation of blind SQL Injection
Chris,
 
To see the value of further materials, let us delve deeply into the terminology for a while. According to the exploitation technique, SQL Injection vulnerabilities can be divided into three groups:
 
1. Classical SQL Injection;
2. Blind SQL Injection;
2.1 Error-based blind SQL Injection;
2.2 Classical blind SQL Injection;
3. Double Blind SQL Injection/Time-based.
 
In the first place, classical exploitation of SQL Injection vulnerabilities provides an opportunity to merge two SQL queries for the purpose of obtaining additional data from a certain table. If it is possible to conduct a classical SQL Injection attack, then it becomes much easier to get useful information from the database management system (DBMS). Attack conduction using classic technique of SQL Injection exploitation involves application of the «union» operator or separation of SQL queries (semicolon, «;»). However, sometimes, it is impossible to exploit an SQL Injection vulnerability using this technique. In such cases, a blind method of vulnerability exploitation is applied.
 
A Blind SQL Injection vulnerability appears in the following cases:
- the application logic doesn't include returning of processed data in the context of a vulnerable query
- injection gets into two different SELECT queries that in turn implement selection from tables with different numbers of columns
- filtering of query concatenation is used (e.g. WAF)
 
Capabilities of Blind SQL Injection are comparable with those of classical SQL Injection technique. Just like the classical technique of exploitation, blind SQL Injection exploitation allows one to write and read files and get data from tables, only the entries are read symbol-by-symbol. Classical blind exploitation is based on analysis of true/false logical expression. If the expression is true, then the web application will return a certain content, and if it is false, the application will return another content.  If we consider the difference of outputs for true and false statements in the query, we will be able to conduct symbol-by-symbol search for data in a table or a file. 
Error-Based Blind SQL Injection is the quickest technique of SQL Injection exploitation. The essence of this method is that various DBMSs can place some valuable information (e.g. the database version) into the error messages in case of receiving illegal SQL expression. This technique can be used if any error of SQL expression processing occurred in the DBMS is returned back by the vulnerable application.
 
Sometimes not only all error messages are excluded from the page returned by the web application, but the vulnerable query itself is used only for certain internal purposes. For example, it can serve for some event logging or internal optimization. These SQL Injection vulnerabilities belong to the Double Blind class. Exploitation of Double Blind SQL Injection vulnerabilities uses only time delays under SQL query processing; i.e., if an SQL query is executed immediately, it is false, but if it is executed with an N-second delay, then it is true. The described technique provides for symbol-by-symbol data reading only.
 
- - - - - - - - - - - - - - - 
Best Regards, Dmitry Evteev 
Positive Technologies Co. 
Tel.: (495) 744-0144 
Web: http://www.ptsecurity.ru
 
From: Chris Eng [mailto:ceng at Veracode.com] 
Sent: Wednesday, January 27, 2010 12:47 AM
To: Dmitry Evteev; websecurity at webappsec.org
Subject: RE: Methods of quick exploitation of blind SQL Injection
 
If you do a search for "Double Blind SQL Injection" Google returns 6 hits, most of which are items that your company has written.  It is pretty evident that you are using non-standard terminology and classification.  I'd rather not clutter the list with a battle of semantics, I just want to avoid confusing readers of this list who may be new to the field. 
 
 
From: Dmitry Evteev [mailto:devteev at ptsecurity.com] 
Sent: Tuesday, January 26, 2010 4:20 PM
To: Chris Eng; websecurity at webappsec.org
Subject: RE: Methods of quick exploitation of blind SQL Injection
 
You are mistaken. If the error message come back it can be as classical SQL Injection and blind SQL Injection. An another matter what in certain cases probably to use an error as the container (error based blind SQL Injection).
 
SQL Injections can be divided into the following three groups according to the exploitation techniques:
1. Classical SQL Injection;
2. Blind SQL Injection;
                2.1 Error-based blind SQL Injection;
                2.2 Classical blind SQL Injection;
3. Double Blind SQL Injection/Time-based.
 
Blind SQL Injection appears when the vulnerable query reflects the application logic, but doesn't allow one to output any data into the page returned by the web application. Here is an example of vulnerable code in php containing a (error-based) Blind SQL Injection vulnerability:
...
$result = mysql_query("SELECT user FROM users where id = ".$_GET['id']) or die('Query failed: ' . mysql_error());
if(mysql_num_rows($result)>0)
{
                ...
                some application logic, e.g. exploitation of another select query
                ...
}
else
{
                echo "error";
}
...
 
- - - - - - - - - - - - - - - 
Best Regards, Dmitry Evteev 
Positive Technologies Co. 
Tel.: (495) 744-0144 
Web: http://www.ptsecurity.ru
 
From: Chris Eng [mailto:ceng at Veracode.com] 
Sent: Tuesday, January 26, 2010 8:54 PM
To: Dmitry Evteev; websecurity at webappsec.org
Subject: RE: Methods of quick exploitation of blind SQL Injection
 
Nice writeup, but if you're getting back verbose error messages, as the screenshots show, it's really not considered Blind SQL Injection.
 
 
 
From: Dmitry Evteev [mailto:devteev at ptsecurity.com] 
Sent: Monday, January 25, 2010 5:51 PM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] Methods of quick exploitation of blind SQL Injection
 
In this paper, the quickest methods of Blind SQL Injection (error-based) exploitation are collected and considered by examples of several widespread databases.
 
See reference:
http://ptresearch.blogspot.com/2010/01/methods-of-quick-exploitation-of-blind_25.html
http://ptresearch.blogspot.com/2010/01/methods-of-quick-exploitation-of-blind.html
 
- - - - - - - - - - - - - - - 
Best Regards, Dmitry Evteev 
Positive Technologies Co. 
Tel.: (495) 744-0144 
Web: http://www.ptsecurity.ru
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20100202/df54afc5/attachment.html>


More information about the websecurity mailing list