BURP SUITE - PART II: SQL Authentication Bypass

Today I am going to extend my previous tutorial where I introduced you to Burp Suite tools so that we can now audit login forms for SQL Authentication Bypass vulnerabilities. This is a common problem found daily in the wild where PHP & MySQL are being used as the Authorization mechanism based on dynamic SQL Query's which are completed from user input supplied through login form. This can be time consuming and repetitive to conduct manually but it is relatively easy to audit - and after reading this it will be even easier, especially with Burp! I will first provide an explanation of the problem and what is going on which allows the vulnerability to be exploited followed by an example, so here goes…

As mentioned above Authentication Bypass vulnerabilities often occur due to a lack of filtering of user supplied input. If we review a quick example of code from a PHP/MySQL authentication page we will begin to see things more clearly. You can find some test samples with quick Google dork “file:php/asp inurl:admin/login”, but here is sample login to keep it easy:

<?php

$sql = "SELECT * FROM users WHERE username='" . $_POST['username'] . "' AND password='" . $POST_['password'] . "'";

response = mysql_query($sql);

?>

This code fails to filter or check the user supplied input. The target system reads like so as result:

SELECT * FROM users WHERE user='' AND password=''

Since this is not filtered or checked we will pick a username and use SQL Injection on the secondary field. Let us assume we choose the username “webadmin” and the SQL Injection:

' OR 'x' = 'x

This is now how the query looks that will get passed through:

                SELECT * FROM users WHERE user='webadmin' AND password='' OR 'x' = 'x'

This is how the target system actually reads & parses the request:

SELECT * FROM users WHERE user='webadmin' AND TRUE

The ultimate goal here is to use our SQL injection to alter the SQL query so that it is fooled into letting us in. This works as you can see above as ‘x’ is always going to be equal to ‘x’ so it will always return as TRUE, and thus the system will grant us webadmin user access to walk right in through the front door without any real password.

Now we could use alternative injections above, like:

·         ' or '1'='1

·         ' or 'x'='x

·         ') or ('x'='x

·         ') or ('1'='1

·         …etc

Some customization may be needed to fit your specific need (Sometimes injections need to be placed in both fields; sometimes it needs more complex syntax, HEX or Char encoding may be needed, etc). You could easily build your own list, but I have gone ahead and put together a decent list to help get you started. The list can be found in the AuthBypass/auth-bypass.txt file which is included in my full download here: HR’s Burp Starter Pack.

Now with Burp Suite:

Now rather than try each potential SQL statement or injection we place all of our potential injections into a single file and then let Burp run the requests in an automated fashion. This will help to save you time, as well as allow easier parsing of the results in a systematic way. In order to do this we simply submit a bogus request with arbitrary data submitted (user: foo, pass: bar).

We then load up the request and send it to the Intruder tool to build our attack. We clear the default injection points and specifically set them around our password field or both user and password fields. You will choose the Sniper or Battering Ram attacks for this method, depending on how you want to test the form. You will then need to set the payload to run your auth-bypass.txt file. You can add some additional inspection items to the grep field if you want. I find it is often helpful to add some basic text you might see upon failed or successful login attempts (welcome, success, failed, wrong, etc).

Once you run the Intruder tool it is time to sit back and interpret the results. You will need to check time, length, grep, etc and manually review any of the requests that appear to show a noticeable variance in responses.

Once you find one, re-test it manually in the browser to see if it works.

If it works you are in, if not keep analyzing and inspecting further.

Rinse, wash, and repeat as necessaryJ. Here is a quick video to show how things should work for those of you that needed the real time visual aid (I know I usually do):

I hope you have enjoyed another tutorial on the Burp Suite and how it can be used to perform quick and accurate audits of login forms to see if they are vulnerable to Authentication Bypass via SQL Injection. I plan to have a follow up tutorial stemming from this one which adapts the methods slightly to perform dictionary attacks against login forms. Please check back often and soon for more updates and more tutorials to come. As always and until next time, Enjoy!

Thanks,

H.R.