bugtraq - Intresting case of SQL Injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 4 Dec 2003 16:39:15 -0300 (ART)
From: "Martin Sarsale (runa@...es)" <runa@...a.sytes.net>
To: bugtraq@...urityfocus.com
Subject: Intresting case of SQL Injection

Yesterday, we found an interesting case of SQL Injection.

The application was developed under PHP 4.2.1, Apache and MSSQL.

We started our tests by adding a ' (single quote) to the POST info.

Since PHP escapes ' and " , turning the ' into a \' but SQL Server uses 2
single quotes ('') to escape a quote (') we were allowed to execute our
code:

select * from users where username='\'; sql code to execute here;--

Then, we wanted to insert a record on the "users" table (fields username
and password, both varchar).

We found that the application used md5 to store the user passwords but
there was a problem: since PHP was auto escaping quotes, we couldn't set
the md5 password as a string because sending:

insert into users values ('username','password');

would be escaped into

insert into users values (\'username\',\'password\');

resulting in a sql error.

So, we had to figure out how to insert the username and password as
numeric values. Since both fields are varchar, when inserting a number SQL
server will cast the number into a string.

This is:
inserting 123 (numeric) into a varchar field is the same as inserting
'123' (string).

The username part is easy, we could insert '12345' as the username (any
number will work here), but we found a problem with the password: We need
a known string which it's md5 hash is ALL NUMERIC.

Then, we coded a simple PHP script and found that md5(1518375) =
93240121540327474319550261818423

After that, we sent to the app:

'; insert into users (username,password) values
(12345,93240121540327474319550261818423);--

which escaped became into:

\'; insert into users (username,password) values
(12345,93240121540327474319550261818423);--

(valid SQL)

Finally, we logged into the webapp using '12345' as username and '1518375'
as password.

The main problem here was that developers where trusting in PHP auto
escaping which worked in MySQL (and probably PostgreSQL) but not in MSSQL.

Alejandro Pomeraniec (apomeraniec at buenosaires.gov.ar)
Martin Sarsale (msarsale at buenosaires.gov.ar)