From: Aditya K Sood (zeroknock@metaeye.org)
Date: Tue Mar 06 2007 - 22:53:47 EST
Craig Wright wrote:
> 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
> ------------------------------------------------------------------------
>
>
>
hi craig
Regarding SQL injections , i think this concept
more relates
to dig errors in the sql enabled applications.This is a chain phenomenon of
hit and trail of input validations.More precisely if you look at the
core than
finding errors and rogue outputs lead to information disclosure that enlarge
the input validation sector that makes the exploitation vector more intense.
You have also encountered some of the sql injections are not exploitable.
The error generation in the web applications remain as the finest priority
of attackers to disseminate the internal layout.
Rest the it depends how the vector shifts.
Regards
Adi
------------------------------------------------------------------------
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