From: Erez Metula (erezmetula@2bsecure.co.il)
Date: Fri Mar 09 2007 - 08:25:23 EST
Hi Craig,
It is totally possible to attack the DB server (when there's no errors),
without having "detailed insider knowledge" as you claim.
Using blind sql, you can "ask" true/false questions and virtually
extract every bit from the database. As you probably know, each sentence
can be logically expressed with Boolean operators only.
The "boolean answers" can be implemented as a true/false page (attaching
"and 1=1" / "and 1=2") or with a delay that will act if the answer is
"true". for example, asking if the current user has high privileges(in
MS SQL server): '; if user ='dbo' waitfor delay '0:0:5 '--
It is possible to the get the database system without error message,
using blind sql only.
The way to get the db system is very simple, and is based on the
differences between the systems sql syntax.
For example, null replace is implemented in mysql with "ifnull()", in
access with "iff(isnull())", in MS SQL with "isnull()", in postgres with
"coalesce()", and in oracle with "ifnull().
Another example is char positioning - in MS SQL with "charindex", in
mysql with "locate", and in oracle with "instr".
There are other differences, that can help you to detect the correct
system. All you need to do is build a "detection" query that will
succeed only on a specific DB, and you get the answer regarding which
type of db system you have.
After you get the db system, the rest is simple. Yon know the db system,
therefore you know its system tables.
Example - mssql: sysobjects, syscolumns, sysdatabases
Oracle: SYS.ALL_TABLES
Access: MsysObjects
Etc.
So you can read the table full structure, get the table names, columns,
etc.
All with no DB errors, just using logic manipulations.
Hope it helps!
Best regards,
Erez.
________________________________
Erez Metula, CISSP
Application Security Department Manager
Security Software Engineer
erezmetula@2bsecure.co.il Mobile: 972-54-2108830 Office: 972-39007530
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Craig Wright
Sent: Tuesday, March 06, 2007 6:14 AM
To: pen-test@securityfocus.com
Subject: SQL injection attacks
Hello,
There seems to be some level of incomprehension as to the nature of SQL
injection based attacks.
It is possible to exploit SQL using injection methods without detailed
error messages. It is not however possible to attack the SQL server
without either detailed insider knowledge or a minimal reaction of the
server. Web based SQL injections rely on the response from the server.
There is a form of more complex SQL attack known as Blind SQL Injection.
This attack is not as is suggested totally blind. This is an attack
against a forms based web server and associated database which has the
SQL server error messages suppressed. The more standard SQL injection
attack is reliant on the SQL server error messages. These are used by
the attacker to craft packets targeted towards the specific SQL server.
To make an SQL injection work the attacker must first identify the
system being targeted. The attacker must first establish some sort of
indication regarding errors in the system or other indicators which will
enable the identification. In blind SQL injection, an analysis of the
responses is used in place of the (easier) method of analysing the
errors.
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.
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.
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:
(1) SELECT * FROM EmployeeID WHERE DeptID = 'Accounts'
(2) SELECT * FROM EmployeeID WHERE DeptID = 'A' + 'ccounts'
Select ... Where ... and other statements used to enact the injection
will not work on non-existent data fields and entities. Knowing not only
the name of the entity and relations, but also the database instance is
crucial to the success of this attack.
It has been common to speculate in the industry about injection attacks
over input streams other than the web. There are valid reasons for this.
Direct access to TCP port 1433 (for MS SQL) allows the attack to
function without web access. All these attacks require an interactive
response form the SQL server.
In cases where the database is "accessed" non-interactively, such as a
phone IVR system (which uses speech to text technologies), Forms based
OCR input and other "feed and forget" systems, the attacker gains no
response and thus is supplied with no information in regards to the
server.
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.
So the next time that somebody tries to tell you that your
"non-interactive" database is not safe from remote exploit, ask them how
the attacker gets information on the server. If the response is the web,
well than the server is interactive and the attack will also follow this
format. If the only access is (for instance) an OCR'd form with no user
feedback, than just nod politely.
Regards,
Craig
Dr Craig S Wright DTh MNSA MMIT CISA CISM CISSP ISSMP ISSAP G7799 GCFA
AFAIM
Nam et ipsa scientia potestas es - Knowledge is power. (Sir Francis
Bacon)
Manager - Computer Assurance Services
BDO Chartered Accountants & Advisers
Level 19, 2 Market Street,
Sydney, NSW 2001
Telephone: +61 2 9286 5555
Fax: +61 2 9993 9705
Direct: +61 2 9286 5497
<Mailto:CWright@bdosyd.com.au>
Liability limited by a scheme approved under Professional Standards
Legislation in respect of matters arising within those States and
Territories of Australia where such legislation exists.
DISCLAIMER
The information contained in this email and any attachments is
confidential. If you are not the intended recipient, you must not use or
disclose the information. If you have received this email in error,
please inform us promptly by reply email or by telephoning +61 2 9286
5555. Please delete the email and destroy any printed copy.
Any views expressed in this message are those of the individual sender.
You may not rely on this message as advice unless it has been
electronically signed by a Partner of BDO or it is subsequently
confirmed by letter or fax signed by a Partner of BDO.
BDO accepts no liability for any damage caused by this email or its
attachments due to viruses, interference, interception, corruption or
unauthorised access.
------------------------------------------------------------------------
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=7016
00000008bOW
------------------------------------------------------------------------
------------------------------------------------------------------------
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:39 EDT