FORM HTTP BASED AUTHENTICATION - BRUTE FORCE ATTACK WITH BURP
- Layout for this exercise:
- The goal of this exercise is to bypass a form based authentication, trying to gain access to the resources located into www.whitelist.com/formauth.
- The attack method used in this case will consist of brute forcing the username and password challenges prompted to the user, taking advantage of some tools provided by the proxy Burpsuite:
- First of all, the browser used by the attacker is set to connect the web page through a manual proxy, so that the connection can be intercepted and crafted:
- Starting the proxy Burp:
- Now, when the user tries to connect to www.whitelist.com/formauth, the connection is intercepted and refused by Burp:
- Analyzing into Burp, the request has been intercepted:
- Then, the request is forwarded:
- Now, the attacker enters some fake credentials (username=asdfg, password=xxxxxxxx):
- Burp detects the fake credentials:
- Right clicking and sending to the Intruder:
- Setting the target (Host and Port) for the attack:
- The attack consists of brute forcing 2 payloads: the 1st payload is inserted into the username position and the 2nd payload is for the password:
- The first payload is defined with a simple list of two possible usernames:
- It is interesting to notice that the Pro version of Burpsuite allows to introduce a complex password list previously crafted or generated by the attacker:
- About the second payload, referred to the password, Burp prompts the user with a charset of lowercase letters, numbers, and a length of 5.
- However, because of the huge amount of requests that Burp would generate (60466176, it would take hours to check all of them), I have simplified the process using a very easy charset with the letters "ab" and a length of 5.
- In this way, the number of request counts would be VR(2,5) = 2^5=32, multiplied by 2 because the first payload list is composed of 2 possible usernames. To sum it up, 64 requests:
- Starting the attack:
- Once the attack is developed, it can be noticed that all the results have a length of 411, with the exception of the 22nd one, whose length is 383:
- For instance, checking the rendered response for the 33rd request, the answer is that the user is not authorized to access the web page, so the corresponding combination (daniel:aaaab) is not correct:
- However, doing the same for the 22nd response (the one with different length) the answer is positive. We find that the user is authorized and welcome to the web page:
- Looking at the response in a raw format:
- We can deduce that the combination used for that request is correct (admin:ababa) and the attack has been successful.
