From: Aaron C. Newman (aaron@newman-family.com)
Date: Mon May 17 2004 - 16:24:26 EDT
Here is a detailed white paper describing how a SQL Injection hole can
be used pump enough data back to the client through the firewall to
reverse-engineer the database completely and even pull the contents of
the tables. There is absolutely no need to know any table or column
names. This is done by the magic of the OPENROWSET command.
http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL
_Injection.pdf
As well you can download the proof of concept tool Data Thief from
http://www.appsecinc.com/resources/freetools/. This implements these
ideas to show how this could be accomplished.
So the answer to your question is "this is a critical vulnerability".
Regards,
Aaron C. Newman
CTO/Founder
Application Security, Inc.
-----Original Message-----
From: Calvin Wood [mailto:calvin_wood2004@hotmail.com]
Sent: Friday, May 14, 2004 11:14 PM
To: pen-test@securityfocus.com
Subject: Security assessment on stored proc vulnerability
I have just started on a security audit for a client, and through the
course
of my work, I have discovered one vulnerability associated with the
client's
web user authentication page.
The page authenticates the user using HTTPS by transmitting username and
password to a back end MS SQL 2000 db via a form. The authentication is
then
carried out by a stored proc. It would return a recordset object to the
front end ASP page if the username/password combination is valid. The
ASP
page essentially does this
SQLStr="exec IdentifyUser '" & UserName & "','" & Password & "'"
conn.open connstr
set cmd.ActiveConnection=conn
set rs=cmd.Execute SQLStr
if rs.EOF
invalid username/password combination
else
valid username/password
end if
...
Now I noticed that the SQLStr is built from the form variable, and it is
vulnerable to SQL injection. This is a definite vulnerability. However,
in
my report, I need to specify whether the risk is low/moderate/high. This
is
the area I need help on.
The database user associated with the asp page has full access right to
all
the tables - however, it can not drop/create objects (i.e., stored proc,
tables, triggers what have you). While it's possible to inject another
sql
statement, I believe it would be hard to inject a valid statement. You
would
need to guess the table name/column name. And you wouldn't know whether
you
guessed it correctly due to deferred name resolution of SQL Server.
I am currently tempted to classify it as a low security risk. However, I
just want to find out if anyone else would disagree.
Thanks in advance
_________________________________________________________________
Personalise your mobile chart ringtones and polyphonics. Go to
http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp
------------------------------------------------------------------------
------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545
off
any course! All of our class sizes are guaranteed to be 10 students or
less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of
in-the-field
pen testing experience in our state of the art hacking lab. Master the
skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
------------------------------------------------------------------------
-------
------------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field
pen testing experience in our state of the art hacking lab. Master the skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:54 EDT