Sqlninja user manual

rel. 0.2.2 - This manual is also provided in the sqlninja tarball

1. Introduction

• 1.1 Requirements
• 1.2 Background
• 1.3 How to use it

2. Attack modes

• 2.1 test
• 2.2 fingerprint
• 2.3 bruteforce
• 2.4 escalation
• 2.5 resurrectxp
• 2.6 upload
• 2.7 dirshell
• 2.8 backscan
• 2.9 revshell
• 2.10 dnstunnel
• 2.11 sqlcmd

3. Configuration file

• 3.1 Basic options
• 3.2 Advanced options

4. Other useful information

• 4.1 Useful links
• 4.2 Credits
• 4.3 Disclaimer
• 4.4 Feedback
• 4.5 Wisdom
• 4.6 Author

---

1. Introduction

Sqlninja's goal is to exploit SQL injection vulnerabilities on web applications that use Microsoft SQL Server as back end. It is released under the GPLv2.

There are a lot of other SQL injection tools out there but sqlninja, instead of extracting the data, focuses on getting an interactive shell on the remote DB server and using it as a foothold in the target network. In a nutshell, here's what it does:

• Fingerprint of the remote SQL Server (version, user performing the queries, user privileges, xp_cmdshell availability, DB Server authentication mode)
• Bruteforce of the 'sa' password
• Privilege escalation to 'sa'
• Creation of a custom xp_cmdshell if the original one has been disabled
• Upload of executables
• Reverse scan in order to look for a port that can be used for a reverse shell
• Direct and reverse shell, both TCP and UDP
• DNS tunneled pseudoshell, when no ports are available for a bindshell
• All of the above can be done with obfuscated SQL code, in order to confuse IDS/IPS systems

As you probably have figured out, sqlninja does not look for SQL injection vulnerabilities. Again, there are already several tools that perform that task already, like WebScarab.

For the latest release and a flash demo (very recommended to get a general idea of the tool), check out the address http://sqlninja.sourceforge.net.

Read this manual carefully (yes, I mean all of it), as it will explain you what it is all about and how to make your way through all sqlninja options. Yes, I know that it's terribly long and boring, but since sqlninja has a plethora of options to play with (and no shiny red buttons), try to read the whole thing: it will help you to get the most of the tool and will save you a lot of time later.

1.1 Requirements

Since sqlninja is completely written in Perl, there is not much to install, except Perl itself and the following modules, if missing:

• NetPacket
• Net-Pcap
• Net-DNS
• Net-RawIP
• IO-Socket-SSL

If something goes wrong, activating verbose output (-v option) and/or debugging (-d) should provide some hints. Developed on a Gentoo box, sqlninja has been reported to work on the following operating systems:

• Linux
• FreeBSD
• Mac OS X

1.2 Background

We all know how a SQL Server "vanilla takeover" pattern goes like: you find a SQL Injection vulnerability, you verify that xp_cmdshell has not been disabled, then you make the server download netcat (via ftp or tftp) and finally obtain your direct or reverse shell. Cool, but reality is different: maybe the firewall filters all inbound/outbound connections, or a reverse shell is only allowed on some obscure service, or xp_cmdshell isn't there, or your queries are executed with low privileges. Or maybe all these things together ;). Sqlninja offers some help in getting the deserved remote shell even in these cases.

I am assuming that you have a good grasp of SQL Injection techniques and of Microsoft SQL Server internals. If you have troubles understanding what follows, I recommend you to read the papers listed in the Links section.

1.3 How to use it

Sqlninja's behaviour is controlled via the configuration file (default: sqlninja.conf), which tells sqlninja what to attack and how (target host, vulnerable page, exploit strings, ...), and some command line options, which tell sqlninja what action to perform. These command line options are the following:

• -m <attack mode> : specifies the attack mode. Basically, tells sqlninja what to do. Possible values are:
  • test
  • fingerprint
  • bruteforce
  • escalation
  • resurrectxp
  • upload
  • dirshell
  • backscan
  • revshell
  • dnstunnel
  • sqlcmd
• -v : verbose output
• -f <configuration file> : specifies a configuration file to use. If the file does not exist, a new one will be created interactively
• -p <'sa' password> : used in escalation mode to add current DB user to the sysadmin group, and in other modes to run the query as administrator, if the DB user does not belong to such group. This option is rarely used, as bruteforce mode by default adds the DB user to the sysadmin group when the 'sa' password is found. For more information about when to use this parameter, refer to the escalation mode
• -w <wordlist> : wordlist to use in bruteforce mode
• -d <debug mode> : activates debug, to see what is going on under the hood. Possible values are:
  • 1 : print each SQL command that is being injected
  • 2 : print each HTTP request that is sent to the target
  • 3 : print each HTTP response that is received from the target
  • all : all of the above

See the description of the various modes to see when each parameter must be used.

2. Attack modes

Sqlninja has currently 11 attack modes. The mode to use can be specified by its name:

sqlninja -m upload

or by its shortcut:

sqlninja -m u

The list with the available modes and their corresponding shortcuts can be retrieved by launching sqlninja with no parameters.

To get a first grasp of the different attack modes, here's a typical way of using sqlninja:

1. Setup the configuration file, and use test mode to check that SQL code is being correctly injected
2. fingerprint the remote DB server, using fingerprint mode
3. if needed, use bruteforce mode to find the 'sa' password and escalate privileges
4. if needed, use resurrectxp mode to re-create the xp_cmdshell extended procedure
5. upload netcat, using upload mode
6. if it is possible to contact the DB Server on some port, use dirshell mode and get a direct shell
7. otherwise, use backscan mode to find an allowed "outbound" tcp/udp port
8. if step 7 is successful, use revshell mode to obtain a reverse shell
9. if step 7 failed, upload dnstun.exe and start dnstunnel mode

2.1 test

• Shortcut: t
• Parameters: none

This mode simply injects a simple WAITFOR DELAY and checks whether it is successfully executed by the remote server. Use this mode to test whether your configuration file is correct and the injection is working.

2.2 fingerprint

• Shortcut: f
• Parameters: -p <sa password> (optional)

Using WAITFOR-based blind injection, this mode fingerprints the remote server. The following pieces of information can be obtained:

• Database version (2000/2005)
• User that is performing the queries
• Whether that user belongs to the sysadmin group
• Whether xp_cmdshell is available to that user
• Whether the remote server uses mixed or Windows-only authentication (you need to know this if you want to bruteforce the 'sa' password)

If the current DB user does not belong to the sysadmin group, but the right 'sa' password is specified as a parameter, the fingerprint is performed with administrative rights. The WAITFOR technique is much slower compared to other inference methods, but it's by far the most flexible. However, since external factors like network traffic and server load could interfere with the time measurements, you might want to repeat the fingerprint a couple of times, if the first result doesn't look right, or play with the blindtime parameter in the configuration file.

2.3 bruteforce

• Shortcut: b
• Parameters: -w <wordlist> (optional)

This mode is to be used if the user that performs the queries does not belong to the sysadmin group (see fingerprint mode). If this is the case, we need to escalate our privileges. Since by using OPENROWSET we can make the target database connect to itself with alternate credentials, we can attempt to bruteforce the 'sa' password. If the correct password is found, current user is automatically added to the sysadmin group. For this attack to work, the remote SQL Server must use "mixed authentication". Use fingerprint mode to check if this is the case.

This attack mode can use two different methods: "dictionary" and "incremental". You are free to use the method that best suits your needs.

Dictionary

This method is used when a wordlist is specified, using the -w option. Using this method, potential passwords are fetched from the wordlist, and each one is tried in a separate request. Be sure that your wordlist contains 'sa' and the empty password, two all-times favourites for MS SQL Server installations.

Pros:

• Very effective if the password is a dictionary word
• Does not put a heavy load on the DB Server

Cons:

• Not effective against passwords that are not dictionary based. If the password is not in your wordlist, you are out of the game
• Needs a lot of network connections, so the attack is very easy to spot by looking at the logs of the web server

Incremental

This method is used when a wordlist is not specified. Sqlninja submits a set of queries that try *ALL* possible combinations of characters up to a certain length that is specified by the user. The cool aspect of this tactic is that since the queries run on the DB server, the bruteforce is actually performed using the target's CPU resources.

Pros:

• Extremely effective in finding passwords that are not dictionary based
• Needs relatively few connections, so there are very few entries in the web server logs

Cons:

• If the password is long, it might take ages
• It might push the CPU usage of the DB Server up to 100% for the whole time, which can be dangerous with a live application. Also keep in mind that critical servers have alarms that are triggered if the CPU usage remains very high for a certain time. As a security measure, sqlninja splits the task in small chunks (each chunk trying n^3 passwords, with n being the length of the charset used). If something goes wrong, just stop sqlninja, and the remote bruteforce will stop at the end of the current chunk
• Depending on how the application connects to the DB Server, this technique might not work (e.g.: ODBC is known to create trouble). Sqlninja tries to figure it out almost immediately and alerts the user, so no precious time is lost

Important notes

• On SQL Server 2005, OPENROWSET is disabled by default for non-administrative users. If the fingerprint mode told you that you are dealing with SQL Server 2005 and that you are not 'sa', then you are likely out of luck
• In SQL Server 2000, passwords are case insensitive, which massively simplifies the cracking job.
• The escalation bit might be impacted if the application uses ODBC (see escalation mode)

2.4 escalation

• Shortcut: e
• Parameters: -p <sa password> (required)

When the correct 'sa' password is specified, the current DB user is added to the sysadmin group.

In general, you should not need this method, as sqlninja takes care of the escalation in the bruteforce mode already. However, there might be cases in which you need to perform this bit independently (maybe you found the password with a social engineering attack).

If you want to know how the escalation works, or if you have found the 'sa' password but the escalation seems not to work, keep reading. Otherwise, you can skip to resurrectxp mode.

The escalation is performed combining OPENROWSET, the right 'sa' password, and sp_addsrvrolemember, by adding the current DB user to the sysadmin group. It is quite unlikely that sp_addsrvrolemember has been disabled, so the trick should work pretty much always. If it doesn't work, there might be 2 cases:

1. The server uses ODBC, and you are using old ODBC connections from the connection pool, which still use the old privileges
2. The sp_addsrvrolemember procedure has been disabled

In the first case, you can just have a couple of pints waiting for the old ODBC connection to timeout and be dropped: by default, an ODBC connection is dropped after 60 idle seconds, and the chance of such an event depends on how many clients are connecting to the web application and how this number varies over time.

In the second case (or also in the first, if you don't want to wait), you only need to specify the -p <sa password> parameter in all the following steps of the attack: that will tell sqlninja to use OPENROWSET in each connection, running each command as 'sa' rather than as the current user.

2.5 resurrectxp

• Shortcut: x
• Parameters: -p <sa password> (optional)

This mode is to be used when the following conditions are both met:

• We have sysadmin privileges or at least know the 'sa' password
• xp_cmdshell has been disabled

The goal of this mode is, of course, to recreate the xp_cmdshell extended procedure. There are quite a lot of variables that come to play here and depending on them this mode will behave in different ways. So read carefully, as here are the things you must keep in mind:

• The methods: there are two ways to get the xp_cmdshell back:
  1. restore it with a stored procedure (sp_addextendedproc on SQLServer 2000 and sp_configure on SQLServer 2005). This method requires one simple SQL command, but requires xplog70.dll to still be there
  2. create a custom one with "CREATE PROCEDURE", sp_oacreate, sp_oamethod and sp_oadestroy. This method requires more code, but works no matter if xplog70.dll has been removed for security reasons.
• The xp_cmdshell name: re-enabling xp_cmdshell might not go unnoticed. Or maybe the application developers might have strictly followed what MS recommends, which is to filter the "xp_*" string, without saying nothing about "sp_*" (check http://msdn.microsoft.com/library/en-us/bldgapps/ba_highprog_11kk.asp). In these cases, we can use CREATE PROCEDURE and a more discrete name (e.g.: "sp_sqlbackup"). You can choose the procedure name with the xp_name option of the configuration file.
• The user privileges: if the privilege escalation didn't work (see escalation mode for the possible reasons), then you must use the -p <sa password> parameter, in order to use OPENROWSET to escalate privileges in each connection, and this leads to the following point
• OPENROWSET and CREATE PROCEDURE cannot be combined. Therefore, if you are using the -p parameter you cannot use the "CREATE PROCEDURE" trick. However, there is a workaround: you can include the whole procedure code in each request that is sent to the DB Server, without creating an extended procedure at all. Let's call this trick "inline procedure injection".

That said, here are the steps that sqlninja follows when this method is used:

1. If the extended procedure name, specified in the configuration file, is xp_cmdshell (which is the default value), then sqlninja starts by trying to re-enable it with sp_addextendedproc/sp_configure. You will be asked the version of the remote SQL Server. If you forgot to use fingerprint mode, sqlninja will find this info on its own. If this whole thing works, we have our xp_cmdshell back.
2. If the extended procedure name is not set to xp_cmdshell (maybe because you want to be more sneaky) in the configuration file, or step #1 has failed (e.g.: because xplog70.dll has been removed), then:
   • if we have native admin privileges (meaning we didn't have to specify the password in the command line) the CREATE PROCEDURE method is attempted. If it works, we have our custom procedure, whatever we have named it
   • if we do not have native admin privileges (meaning we had to specify the password in the command line) the inline procedure injection is tried. If it works, then you will have to set xp_name to NULL in the configuration file. This will tell sqlninja to use the inline procedure injection in all subsequent steps

I hope it is clear. If it is, you should not have any problem in having back your xp_cmdshell (or something perfectly equivalent) in almost every situation. If it is not clear, I am afraid you will have to read the whole thing again.

Note: the code used by sqlninja for the custom procedure is a slight modification of Antonin Foller's code, that you can find at the address http://www.motobit.com/tips/detpg_cmdshell/

2.6 upload

• Shortcut: u
• Parameters: -p <sa password> (optional)

This mode uploads an executable file using only GET or POST http requests to the web server, so no ftp/tftp or whatever other connections are needed. The file is uploaded in the directory specified by the server's %TEMP% variable, so that the attack works when MSSQL can't write on the default directory (which seems to be sometimes the case with MSDE). You will be prompted for the file name to upload, which must be in scr (debug.exe script) format; for your comfort, netcat.scr and dnstun.scr are already available in the scripts directory. You need to upload the former to use backscan, dirshell and revshell modes. The latter needs to be uploaded to use dnstunnel mode. You need to specify the password parameter when you do not have native sysadmin privileges (see escalation mode).

If you want to upload other toys (pwdump etc.), there are several tools to convert an executable to a debug script, but I especially like dbgtool, that provides the most compact scripts. You might also want to compress the original executable file with upx in order to minimize upload time and web/DB logs.

Keep in mind that a lot of things can go wrong here: if a single line of the debug script fails to get uploaded, the executable will not be correctly generated. Therefore, at the end of the process sqlninja checks whether the executable file is there, and if it is not it also tries to figure out how many lines have been uploaded: this should provide some hints on what went wrong. For instance, in a work engagement it came out that the resulting number of lines was exactly twice the correct value, meaning that each injected query was executed twice. The trick was to create a temporary table that acted as a counter, appending the line to the script file only when the counter was even.

2.7 dirshell

• Shortcut: s
• Parameters: -p <sa password> (optional)

Use this method when the remote DB Server is directly reachable on some TCP or UDP port. Sqlninja asks for the remote port, the protocol, tells the DB server to bind a command prompt to such port and then starts the connection. Of course, netcat must have been uploaded on the remote server. The password parameter is to be used when we do not have native sysadmin privileges (see escalation mode).

2.8 backscan

• Shortcut: k
• Parameters: -p <sa password> (optional)

Tipically, when the DB Server is behind a firewall it is not possible to directly contact it. However, it might be possible that the server is allowed to access the outside world on some port (e.g.: DNS, HTTP). This mode tells the DB Server to send SYN packets or UDP packets to our machine on a range of ports, in order to look for one that is allowed. Sqlninja will tell the user whether packets are received and on which port(s).

You need to specify, in the configuration file, the IP address of your machine ( lhost parameter) and the interface to listen on ( device parameter). Sqlninja will ask you about the protocol to use (TCP/UDP) and for the ports, that must be specified with the common netcat syntax (e.g.: "23 25 80-100" will try ports 23, 25 and all ports between 80 to 100). The password parameter is to be used when we do not have native sysadmin privileges (see escalation). In order to use this mode, netcat must have been uploaded first, and since pcap libraries need to be used you also need to be root.

2.9 revshell

• Shortcut: r
• Parameters: -p <sa password> (optional)

If a direct shell is not possible but backscan mode found an open port from the DB Server to our machine, then a reverse shell is possible. When using this mode, sqlninja asks for the local port, the protocol and then starts the connection. You need to specify, in the configuration file, the IP address of your machine ( lhost parameter). Of course, netcat must have been uploaded on the remote server. As usual, the password parameter is to be used when we do not have native sysadmin privileges (see escalation mode).

2.10 dnstunnel

• Shortcut: d
• Parameters: -p <sa password> (optional)

When no direct or reverse shell is allowed by the firewall, we can try to establish a DNS tunnel. The only requirements are:

• the DB server must be able to resolve external hostnames (which is very often the case)
• our IP must be the authoritative DNS server of some domain (you can buy one for a few bucks). We will use sqlninja.net in our example

If both conditions are met, upload dnstun.exe, start dnstunnel mode, and launch your commands. What happens is more or less the following:

1. The command is passed via SQL Injection to dnstun.exe (which acts as our remote agent) and is executed by the remote DB Server. The output is intercepted and encoded in a slightly modified base32 format
2. The encoded output is split in a series of hostnames of the domain we control (e.g.: encoded_output.sqlninja.net)
3. Those hostnames are passed to gethostbyname(), so that the DB server contacts its DNS Server to resolve them
4. The DNS Server looks for the authoritative server of sqlninja.net (our IP) and forwards the requests to our workstation
5. sqlninja receives the requests, re-orders them if necessary, decodes the hostnames and finally prints the command output. Of course, sqlninja also responds to the DNS requests (with a fake IP address) in order to make gethostbyname() quickly return.

The whole process is streamed, which means that if the command output is very long you will start seeing its output before the command has finished.

The domain to use must be specified in the configuration file. Of course, since sqlninja must create a fake DNS server and bind port 53, you need root privileges to use this mode. Keep in mind that DNS uses UDP, so packet loss might be an issue, here.

The executable version of the agent has been compiled with Msys. As always, the password parameter is to be used when we do not have native sysadmin privileges (see escalation mode).

2.11 sqlcmd

• Shortcut: c
• Parameters: none

Sometimes, even if we have sysadmin privileges and xp_cmdshell works, it is still not possible to get a shell, maybe because the executable upload fails, or because ports are all filtered and external DNS resolving is not allowed. In these cases, it can still be useful to issue single commands to the DB server, even without being able to see the output. For instance, you might want to add a local user (maybe you can RDP to the box), or a domain user, if SQL Server runs with such privileges (yes, it happens more often than one would expect). In such cases, you can use this mode: simply enter a DOS command and let sqlninja execute it remotely. Just remember: it gets executed even if you don't see its output.

Of course, you can still use timing to know what is going on:

if exists filename (ping -n 5 127.0.0.1)

If the command takes around 5 seconds to execute, the file is there.

To know whether a command succeeded, also check the value of the ERRORLEVEL variable, which is usually set to 0 if the last command did not produce an error. So, for instance, if we want to know whether the remote SQL Server is running as SYSTEM, we can use the following command:

whoami > who.txt & find /i "\system " who.txt & if not errorlevel = 1 ping -n 5 127.0.0.1 & del who.txt

If the command takes around 5 seconds to execute, you know that SQL Server is running as SYSTEM (whoami.exe is installed by default on Windows 2003 and can be found on Windows 2000 if the Resource Kit has been installed). Refresh your DOS-shaolin skills and use your fantasy: from appending commands in AUTOEXEC.BAT to starting/stopping services and adding rogue users, you can get pretty far with this!

This mode can also be useful when some other mode fails in order to understand what went wrong and how to fix the problem. Finally, this command is also very useful to show a client that you owned their DB server even if you didn't get the shell:

echo You have been owned by sqlninja > c:\sqlninja.txt

3. Configuration file

The configuration file (default: sqlninja.conf) controls most of sqlninja behaviour. Each option is in the form:

option_name = option_value

Options can be roughly divided into the following categories:

• Basic: used to configure the attack
• Advanced: used for additional fine-tuning

Option values are, more often than not, case sensitive (e.g.: URL values). When a default value is not mentioned, it means that the parameter needs to be specified. The same option can be used multiple times: sqlninja does not care and will simply use the last declaration, overriding the previous ones. Comments are allowed, and they are prepended by the '#' character. A quick recap of what follows can also be found in sqlninja.conf.example.

IMPORTANT: since version 0.2.2, sqlninja only URL-encodes the batched queries that are injected, but not the strings specified in the configuration file! This gives users a more granular control on the exploitation strings. Keep that in mind if your parameters contain non-alphanumeric characters.

3.1 Basic options

host

The target host to connect to (IP address or domain name). For example:

host = www.victim.com

port

The port to connect to. If not specified, port 80 is assumed. For example:

port = 443

ssl

There are 3 possible values here:

• yes - forces an SSL connection
• no - forces a normal HTTP cleartext connection
• auto - sqlninja automagically figures out whether the remote server uses SSL or not on the specified port. This is the default behavior, and the most flexible. But also the slowest.

Example:

ssl = yes

method

The HTTP method to use. Possible values are GET (default) and POST. For example:

method = POST

page

The vulnerable page, with the full path, and including the leading slash. So, for example:

page = /dir1/dir2/target.asp

stringstart

The start of the exploit string, to be sent in the URL if GET is used or in the body if POST is used instead. It must include the vulnerable parameter and the character sequence that allows us to start injecting commands. Othen this means, at least:

1. the vulnerable parameter (name+value)
2. a single quote (if the parameter is a string)
3. a semicolon (to end the original query)

It must also include everything that is needed to properly close the original query, as an appropriate number of closing brackets. Spaces can be used, if needed (quite a rare case), and sqlninja will take care of encoding them correctly. For instance, if we consider the following TSQL command:

exec master..xp_cmdshell 'dir c:\'

and the string to inject it is the following:

param1=1&param2=x';exec+master..xp_cmdshell+'dir+c:'

this parameter should look like this:

stringstart = param1=1&param2=x';

stringend

If you need to add some more parameters after the vulnerable one, put them here. Don't forget the leading "&" sign. So, for example:

stringend = &param3=ccc

This parameter is also useful if you need to add some more SQL code after the injected query. Usually this is not needed, since sqlninja simply appends two hyphens and comments out the remainder of the original query, but there are some (rare) cases when you need to append additional SQL code for the batched queries to work correctly. You can use this parameter for this goal too, but don't forget to also set appendcomment = no, otherwise the two hyphens will be appended and the SQL code specified here will be considered a comment.

lhost

The IP addresses or hostname that the target must try to contact in backscan and revshell mode. That is *your* machine. Of course, if the attack is performed over the Internet, this must be a public address. For example:

lhost = tester.sqlninja.net

device

The device to use for sniffing packets when in backscan mode (default: eth0). For example:

device = ppp0

domain

The attacker's controlled domain to be used with the dnstunnel mode. The IP address from which sqlninja is launched must be the authoritative DNS server for that domain. For example:

domain = sqlninja.net

evasion

Sqlninja can use a few evasion techniques, in order to confuse and bypass signature-based IPS/IDS. Currently, four techniques are implemented, which can be freely combined together:

1. Query hex-encoding: the query is hex-encoded before being run
2. Comments as separators: all spaces are substituted by the string /**/
3. Random case
4. Random URI encoding

The first technique is particularly useful. For instance, if we want to inject the following command:

exec master..xp_cmdshell 'cmd /C ping 127.0.0.1'

The actual query will become:

declare @a varchar(8000) set @a=0x65786563206d61737465722e2e78705f636d647368656c6c2027636d64202f43 2070696e67203132372e302e302e31273b exec (@a)

A much longer string, but notice the following:

• No SQL commands except DECLARE and EXEC, so bye-bye IPS's looking for xp_cmdshell and the like
• No single quotes either! This evasion technique is therefore extremely useful if you find a vulnerable numeric parameter and single quotes are filtered

As mentioned, you can combine all the techniques together with the following option:

evasion = 1234

This will generate quite cryptic code, as the following one:

%64ECl%41RE%2F%2A%2A%2F%40%61%2F%2A%2A%2F%76Ar%63%48aR%288000%29%2F%2A%2A%2F%73 ET%2F%2A%2A%2F%40A%3D%30%586%35786%3563%3206d617%33746%35%372%32e2%457870%35F63 6d647368%36%35%36%63%36c2%302%37636D%3642%30%32f%34320%37%3069%36%65%36720%331% 332372E%330%32E3%30%32%45%3312%373b%2F%2A%2A%2FeX%65%43%2F%2A%2A%2F%28%40A%29

As a default, sqlninja sets evasion to zero, and no evasion technique will be used.

Important: avoid using unnecessary obfuscation if you are using GET requests, as this might lead to URLs that are too long and that are not successfully parsed by the web server!

3.2 Advanced options

headers

A list of all headers to send in the HTTP requests. This must include the following:

• virtual host (if different from the host parameter)
• cookies or authentication headers, if needed

It is wise to add a Connection: close header to avoid the server to hang and speed things up. Using the same connection for multiple requests might be added in some future release. Headers must be listed between --headers_start-- and --headers_end--. So, for example:

--headers_start--
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Content-Type: application/x-www-form-urlencoded
Connection: close
--headers_end--

filter

A valid pcap expression to filter incoming packets in backscan mode. By default, when performing such attack, sqlninja listens for packets coming from the IP address of the remote web server and directed to the host specified in lhost. This might not work in all cases: for instance, the outbound connections of the DB server could be NATed to an IP address which is different from the IP address of the web server. Therefore, we need to override the default pcap filter with this parameter, for instance indicating the whole public subnet of the target. You only need to specify hosts/networks here, as the protocol details (e.g.: tcp flags) are handled by sqlninja. For example:

filter = src host nat.victim.com

timeout

This parameter is used when in backscan mode. It specifies how many seconds to wait for further packets after the web request has completed (default: 5 seconds). This is especially useful when specifying a very large range of ports to scan, because the web request might timeout before netcat has completed. In this case, you should increase this value. For example:

timeout = 30

However, try to avoid very large port ranges: better to split the job in multiple scans.

hostnamelength

Maximum length of FQDN of the fake hostnames that the target will try to resolve in dnstunnel mode. RFCs state that 255 characters is the limit, but I bumped into a few DNS servers that refused names longer than 253. The default value is therefore 250, which should be accepted by every DNS server, and at the same time keep an almost optimal tunnel speed. Minimum value is 40. Maximum is obviously 255. For example:

hostnamelength = 250

You can also tune this parameter to lower values when you think that very long DNS requests might be spotted. Of course, shorter values mean a slower tunnel. If unsure, leave the default value.

resolvedip

In dnstunnel mode, the IP address that is sent back to each DNS request (since we don't want gethostbyname() to hang). In general, the address you choose here doesn't have much of an impact, so choose freely. For example:

resolvedip = 10.255.255.254

xp_name

Name of the extended procedure that executes our commands. The default is obviously xp_cmdshell. This parameter is used in two different ways, depending on the current attack mode:

• resurrectxp: xp_name contains the name of the extended procedure to create. If you believe that re-enabling xp_cmdshell might be spotted, use another name here (e.g.: sp_sqlbackup)
• all other modes: the extended procedure name to use. It goes without saying that it must be the same name previously used with the resurrectxp mode.

xp_name can be set to NULL to use the inline procedure injection technique (see resurrect_xp mode for more details). For example:

xp_name = sp_sqlbackup

blindtime

The value for the WAITFOR DELAY calls that are used in fingerprint and bruteforce modes for the inference-based injection. Default value is 5 seconds, but this might be too low for very slow servers and lead to wrong results. If that happens, try increasing this value. On the other hand, if the server response time is very short, you can set a lower value to make things faster (minimum: 3). For example:

blindtime = 4

If you have no clue about what inference-based injection means, enjoy some time in the library.

errorstring

Sqlninja alerts the user when an HTTP error code is received (e.g.: 500 Server Error), but some applications return a custom page with a 200 OK message. In such cases, it is wise to provide sqlninja with a string that is present in that error page (and only in that page). The parameter value must be put between double quotes. For example:

errorstring = "an error has occurred"

appendcomment

By default, sqlninja appends two hyphens to the injected query in order to comment out any spurious SQL code. This is good and works in approximately 99% of the cases. However, you might want to change this behavior in some very specific scenarios. For example:

appendcomment = yes

Change this setting only if you really know what you are doing.

4. Other useful information

• Sqlninja is released under the GPLv2. See the LICENSE file for details.
• Netcat is included in the sqlninja package, already in scr format.
• In verbose mode you might get a "Bareword NetPacket::IP::IP_PROTO_UDP not allowed...blah blah" error. You can safely ignore it, as it seems a harmless bug of NetPacket. If you want to get rid of it, set $proto=17 in UDP.pm.
• Unless you are a beginner, snowboarding on piste is lame.

4.1 Useful links

A few things you should know before using sqlninja:

• http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
• http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf
• http://www.ngssoftware.com/research/papers/sqlinference.pdf

If you want to generate your own .scr files:

1. Compress the executable with UPX: http://upx.sf.net
2. Generate the script file with dbgtool: http://www.toolcrypt.org

I borrowed a few ideas from the following tools:

• http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html
• http://scoobygang.org/magicsql/

4.2 Credits

If sqlninja has been useful to you, either because it helped in a penetration test or because you just became a millionaire stealing credit cards from e-commerce sites, be aware that it's also thanks to:

• lele - for the sql sorcery
• julie - for the discussions about DNS tunneling
• sp0nge - for all the discussions and the coding hints
• hobbit - for netcat, of course
• Antonin Foller - for the original custom xp_cmdshell code
• WarGame - for the config file generation idea and original code
• The Spike Riders Team - see you at the snowpark, dudes !

Additional credits for {ideas|suggestions|patches|support} go to: s4tan, Stefano Di Paola, Elliot Kendall, geese, nmonkee, Philippe Schaeffer, Nico Leidecker

4.3 Disclaimer

Sqlninja is not trivial to setup, so it should be of no use for Skr1pt K1ddi3z. In any case, what you do with this tool is uniquely your business. In order to use it you are supposed to be a professional penetration tester with some written document that authorizes you to punch holes in the network you are attacking. If you don't have such authorization, feel free to have fun anyway but be aware that this might get you in trouble with a lot of law enforcement agencies. That means you. Not me.

4.4 Feedback

Since I am not paid for coding this tool, and since I work on it only when I have nothing better to do, don't flame me telling me that the code is ugly (I know it is), or that the interface sux (I know that too), etc.

However, if you have some constructive observations or ideas about current or new functionalities, or if you want to report a bug, or if sqlninja was useful in some way, please drop me a line :)

Also, if you successfully used this tool in a penetration test, and that made your boss win a few more projects that will help him buy a new Porsche, convince him that the hacking community deserves a donation to buy some booze.

4.5 Wisdom

Any damn fool can beg up some kind of job; it takes a wise man to make it without working -- Charles Bukowski

4.6 Author

icesurfer <r00t -at- northernfortress -dot- net> - PGP ID: 0x28DA28B4