From: Craig Wright (cwright@bdosyd.com.au)
Date: Mon Mar 05 2007 - 23:13:35 EST
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=701600000008bOW
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:38 EDT