Start off by making sure you have the following requirements:
- Burpsuite (latest copy - free version is fine)
- Download from Homepage: http://portswigger.net/burp/download.html
- Just download and run burpsuite_v1.3.03.jar file (version number may change)
- Requires JRE Environment to be installed to run, platform independant
- SQLMAP (latest copy - Open Source=FREE)
- Download from Homepage:
- Requires Python to be installed, platform independant although not all features capable on Windows platform
- *Site with $POST data being submitted for us to find and inject (i.e. Login page or search fields
- Example Google Dork: "inurl:admin/login.php" get creative and get better results
EX: "ext:php inurl:admin/login site:US"
NOTE: There are variations to this, so use your own creativity to increase your odds
Resulting Target Found: http://www.site.com/Admin/login.php (take note, write it down, and close browser)
Now it is time to use Burpsuite to help us find out the needed fields for injecting. Run the "burpsuite_v1.x.jar" file to get up and running, just double click it OR start it from the command line by using 'java -jar burpsuite_v1.x.jar' (replace "x" with your version number).
Bursuite is configured by default to operate on port 8080, so you will need to configure your favorite browser to use this as the proxy address so that Brupsuite can pick up all of the traffic for analysis and examining. For most browsers you can open and then go into options or internet options>>connections>>LAN Settings>>PROXY Settings>>and then set to: 127.0.0.1:8080>>save>>and your done.
Now any pages you go to in your web browser will be parsed by Burpsuite, simple remove proxy setting to go back to normal surfing. By default Burpsuite has the option to "Intercept Data" set to "ON". This is helpful if you want to tamper with data for EVERY request travling on the line. You can quicklya nd easily turn this off if you dont want as much interaction as it will still save the logs for requests sent and received to the HISTORY tab. I prefer to leave it ON as I see more of what is actually going on and can simply DROP any I dont want or FORWARD to allow without very much hastle. Leave it setup for now, we will come back to this in a few...
NOTE: you will have to do some back and forth to see the results while we test so I suggest you just minimize or adjust your screens so you can run side by side (my preference) to save your self time.
Now that we have a potential target and Burpsuite running we will start testing it with our browser to see what all is captured. Surf to the login page found with our Google Dorks earlier and watch as the Burpsuite starts to blink for user interaction. Assuming you have default behavior you will need to "FORWARD" or "DROP" the requests as they are sent and received. This equates to allow or drop in simple terms. You can review the actual details of what is being sent in the RAW tab window (you change tabs to view different aspects of what is ebing sent/received). Let us try entering "logintest" in the login field and "passtest" in the password field, then submit. Obviously this is not going to get us into the site, unless you are just a really lucky guesser, BUT it will help us to get one step closer to accomplishing that task. You will see the request come through Burpsuite again, FORWARD the request to allow it to run through the full authentication cycle. Now lets review the results from that simple request we just sent...
In Burpsuite navigate to the HISTORY tab, two to the right of the main INTECEPTOR tab we have been working from since we started. The HISTORY tab will outline all of the details that were captured when we sent the login request to our target site.
You should see one or two $GET requests which were sent from you when you were actually navigating to the target site, and then you should find a $POST request from when we actually submitted the login page/form. This is the one we are actually interested in. Highlight the $POST request in the history tab and you can view the specifics down below in the RAW tab window. This is a view of the $POST request sent, if you look through it (likely near bottom) you will notice the actual post parameters sent for the form fields we entered (testlogin & passtest).
It should look something like this:
POST /Admin/login.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.65 Safari/534.24
*Notice* the "_auth_username=testlogin" & "_auth_password=testpass". These are the $POST fields we just sent, these field names may vary from site to site so please stay with me if yours a little different.
Note the cookie field to see if this is of any value, as this and user-agent fields
are also injectable (to be covered in another article).
*PRO TIP*: If you use tools like Cain and Able you can use this method to
add to the "HTTP_PASS_FIELDS.LST" & "HTTP_USER_FIELDS.LST" files
to increase your chances of catching credentials while pulling off MiTM attacks
as you can add the form fields it looks for.
OK now that we know our $POST variables we will be working with, it is time to startup SQLMAP. Open command prompt and type in 'sqlmap.py', see previous posts regarding how to set environment variables to avoid having to navigate to the install folder. Now that SQLMAP is up we will start feeding it the data we found from our previous steps above (_auth_username=&_auth_password=&Submit_button=). We will need to let identify we want to use $POST method to inject our website by issuing the '--data' argument followed by our $POST fields we found using Burpsuite "_auth_username=" & "_auth_password=".
NOTE: $GET requests are sent by SQLMAP as default but by issuing the '--data' argument it is smart enough to know to change to $POST - realized by you supplying the those $POST parameters with the '--data' argument in command. The fields passed are then used to test for SQL injection as well as any
provided GET parameters that might normally be tested for.
EX: sqlmap.py -u http://www.site.com/Admin/login.php --data "_auth_username=test&_auth_password=test$Submit_button=Submit"
*PRO TIP* If you know or only want to test certain fields then only include the ones you want (i.e. _auth_password only). If you started a scan and it doesnt look like it is an injectable field you can hit 'CTRL+C' to pause and then you can hit 'N+ENTER' to skip to the next field to start testing. This can save you from spending unnecessary time.
Once confirmed that you have found an injection point, we can add arguments we learned from our previous introductions to find crucial information. We transform the above command into the following:
EX: sqlmap.py -u http://www.site.com/Admin/login.php --data "_auth_password=test" --current-user --current-dba --users --dbs --is-dba
Once we have processed results we will check for passwords, using the '--passwords' and see if we can get any...
EX: sqlmap.py -u http://www.site.com/Admin/login.php --data "_auth_password=test" --passwords
NOTE: this is assuming you have gone in order, as it will read the session file already created to skip things like (--users) which normally accompanies this command argument...
You can continue enumerating the database for more details on tables, columns, etc but that was already covered in my two original posts on SQLMAP so I will not go into any more details on how to dump the database. If you are super lazy and this was too complex for you, then you can use the easy way out as covered in my mini-tutorial at the end of SQLMAP Tips & Tricks article (--forms).
I hope you have enjoyed this little twist to your standard injection techniques, and hope you walk away remembering to leave no rock unturned in your search for vulnerabilities and injection points. I will try to include more in depth coverage on Burpsuite and its other functionalities and how else it can be used in future articles, but I encourage you in the meantime to please dig around in it and try to get creative.