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:
"username-wordlist.txt"
nik
securitynik
admin
guest
sa
"password-wordlist.txt"
password
<blank> # This is just an empty password
admin
letmein
12345
adminpass
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.
Reference:
Mutillidae
Burpsuite
https://support.portswigger.net/customer/portal/articles/1964020-using-burp-to-brute-force-a-login-page
https://portswigger.net/burp/help/intruder_using.html
https://portswigger.net/burp/help/intruder_payloads_types.html
https://support.portswigger.net/customer/portal/articles/1783129-configuring-a-burp-intruder-attack
https://portswigger.net/burp/help/intruder_positions.html
Monday, January 2, 2017
Brute Forcing Web Authentication - OWASP Mutillidae II & Burp Suite
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment