Penetration Testing mailing list archives
RE: Security assessment on stored proc vulnerability
From: "Michael Howard" <mikehow () microsoft com>
Date: Sun, 16 May 2004 23:07:24 -0700
Sprocs help prevent: Sproc or 2>1 attacks But not Sproc select * from sysobjects where type = 'U' Now I know all the tables! In short, this is high severity - a 'must fix' Cheers, Michael [Writing Secure Code 2nd Edition] http://www.microsoft.com/mspress/books/5957.asp [Protect Your PC] http://www.microsoft.com/protect [Blog] http://blogs.msdn.com/michael_howard [Annual Security Training] http://mste/training/offerings.asp?offeringid=7142 -----Original Message----- From: Calvin Wood [mailto:calvin_wood2004 () hotmail com] Sent: Friday, May 14, 2004 8: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 -------------------------------------------------------------------------------
Current thread:
- Security assessment on stored proc vulnerability Calvin Wood (May 16)
- RE: Security assessment on stored proc vulnerability Aaron C. Newman (May 17)
- Re: Security assessment on stored proc vulnerability Frank Knobbe (May 17)
- <Possible follow-ups>
- RE: Security assessment on stored proc vulnerability Michael Howard (May 17)
- RE: Security assessment on stored proc vulnerability Brett Moore (May 18)