Web Application Disassembly with Odbc Error Messages
Join now to read essay Web Application Disassembly with Odbc Error Messages
Web Application Disassembly with ODBC Error Messages
Juleanus Spetember
CTO Hellringer Enterprises
Introduction
This document describes how to subvert the security of a Microsoft Internet Information Web Server that feeds into a SQL database. The document assumes that the web application uses Active Server Pages technology with Active Data Objects (ADO), though the same techniques can be used with other technologies. The techniques discussed here can be used to disassemble the SQL databases structure, by-pass login pages, and retrieve and modify data. This does assume that attackers can run arbitrary SQL queries, which unfortunately is all too common due to a lack of understanding, or even a complete ignorance of this problem and subsequent coding techniques in an ASP page. For example – consider the following ASP code – from a login page:
<%@ LANGUAGE="VBSCRIPT" %>
Dim oCONv, oRSu
Set oCONv = Server.CreateObject(“ADODB.Connection”)
oCONv.Open “DRIVER={SQL Server};SERVER=aeneas;UID=sa;PWD=;DATABASE=paper”
Set oRSu = oCONv.Execute(“SELECT * FROM tblUsers WHERE username = ” & Request.Querystring(“UserID”) & ” AND password = ” & Request.Querystring(“Password”) & “”)
if not oRSu.EOF then
Session(“UserID”) = oRSu (“username”)
Response.Redirect “loginsucceeded.asp”
else
Response.Redirect “loginfailed.asp”
end if
There are several problems with this page but before getting to those examine how it works. The client enters a user ID and password, which are passed into an SQL query, which is then executed. If the user ID and password exist in the tblUsers the SQL servers response, known as a recordset, would be populated. If the user ID and/or password do not exist then the recordset would not be populated. The ASP code then checks to see if it has and redirects the user to loginsucceeded.asp and if the recordset has not been populated the user is redirected to loginfailed.asp.
As was already stated there are several problems with this ASP page – theres an SQL login and password embedded in the code, that SQL login happens to be the most powerful account in the database and its password is still the default blank. As far as the coding is concerned though it is extremely dangerous: due to the fact that user supplied ID and password are being passed straight into the SQL query with out first being sanitised it gives an attacker bypass this login page. All she would need to do is populate the record set and to do this, without knowing a valid user ID and password is make the following request:
Rather than executing the SQL query the server was supposed to i.e.
SELECT * FROM tblUsers WHERE username = foo AND password = bar
it executed
SELECT * FROM tblUsers WHERE username = or 1=1–
Due to the “or” condition in this query always evaluating to true the recordset would be populated and the attacker would be logged in.
The reason that the SQL query has been so drastically modified is because of the single quote mark in the parameter. In SQL queries strings are delimited by single quotes. Tacking on a — on the end of the query stops SQL complaining about unclosed quote marks. This page is easy to by-pass using this “or” technique.
Extended Introduction
If this code was modified however such that an UPDATE occurred after to set, say, audit information this “or” technique would fail:
Dim oCONv, oRSu
Set oCONv = Server.CreateObject(“ADODB.Connection”)