Monday, January 2, 2017

Brute Forcing Web Authentication - OWASP Mutillidae II & Burp Suite

Authentication is one of those mechanisms which is probably targeted more than anything else. Obviously the reason for this is understandable, as in most cases we have to authenticate to be able to complete a task. Be it we are authenticating against our computer, phones or an application, authentication is essential to what we do.

Since this is probably one of the most attacked mechanisms, we should know not only how the attacks are done but also how we can detect such attacks.

For this let's leverage "OWASP Mutillidae II". Specifically, we will leverage its "OWASP 2013 -> A2 Broken Authentication and Session Management -> Authentication Bypass -> Via Brute Force -> Login"

Figure 1: Mutillidae Login page from menu.

The above produces the following login page

Figure 2: Mutillidae Login page.

Let's now load up Burpsuite as we will need to intercept this traffic to be able to manipulate the authentication process.

Note we need to configure our browser to use the proxy. The image below is for FireFox's proxy configuration which is found under  "options -> advanced -> network".

Figure 3: Firefox proxy configuration.

Next we configure Burp Suite to listen (this is on by default) when Burpsuite is loaded.

Figure 4: Burp Suite Proxy intercept on.

Now that we have our browser configured to use our proxy and we have our proxy listening, let's go ahead and make the request from the login page. At this point the objective is to use any credentials, just to generate some traffic so that we can review it in the proxy.

Figure 5: Sample login

Once we click login, we see that data being intercepted by the proxy. This is where we will spend the rest of our time .... for now ...

Figure 6: Burp Suite intercept results

Next let's send this capture data to Burp Intruder.
Figure 7: Sending to Burp Intruder

Looking at Burp Intruder's "Position" tab

By default Intruder will highlight the fields which we can use as variables. What we will do is double click the ones we don't want and click "clear" from the buttons on the right. In the end we will be left with only two variables that we will use. These will be "username" and password. At this point the values in these fields are "securitynik" for username and "SomePassword" for the password field.

For the "Attack type" we will select "cluster bomb”

Figure 8: Results from Proxy Position tab

Stepping back a little ...

I created two files. the first consists of some usernames and the other some passwords:

<blank> # This is just an empty password

The above two files will be used in the "Payload" tab.

Let's select "Payload Set" "1". For this we will use a "Payload Type" of "Runtime file". Here we select our "username-wordlist.txt" file.

Figure 9: Burp Payload 1 (username) configuration

Let's set our 2nd payload. For this we will use our "password-wordlist.txt" file for the runtime file.

Figure 10: Burp Payload 2 (passwords) configuration

Once completed, let's "Start Attack". This will bring up
Figure 11: Results from password attack

As  we can see almost all of these attempts have a "status" of "200" and "Length" "53449". However, the anomaly lies in the "Status" code of "302" and a "Length" of 436. Since this is one that is different and has a Payload 1 (username) of "admin" and Payload 2 (password) of "adminpass" then we can assume this is probably the credentials that will work for us.

The request which was actually sent looks like:

Figure 12: Admin login successful
We  see our credentials were sent as part of a "POST" method

Let's look at the response for this request

Figure 13: Admin login successful. Response from server.

If  we look at the above image and contrast it with some of the other attempts, we see that this response has an "Expires" header with a value of "Thu, 19 Nov 1981 08:52:00 GMT", a "Set-Cookie" header with "username=admin" another "Set-Cookie" header with  "uid=1" and a "Location" of "index.php?popUpNotificationCode=AU1"

Let's now use the "admin" username and "adminpass" password to authenticate.

Figure 14: Testing the successful credential

Figure 15: Login successful

So  that's it for this post. In the next post let's look at how we can detect this type of activity.


No comments:

Post a Comment