Brute-forcing a stay-logged-in cookie
To access the lab visit the following link:
This lab allows users to stay logged in even after they close their browser session. The cookie used to provide this functionality is vulnerable to brute-forcing.
To solve the lab, brute-force Carlos’s cookie to gain access to his “My account” page.
- Your credentials:
wiener:peter - Victim’s username:
carlos - Candidate passwords
Click on the given button to access the lab:
On the Lab’s homepage we can see “My account” option. Let’s click on that to attempt login.
Let’s login using correct username and password to capture the login request using burp. In this way we can see the login functionality of the application.
And we are successfully logged in to the application.
Let’s see the POST request in burp HTTP history. The login POST request contains username, password and stay-logged-in field which indicates a preference to stay logged in, often implemented with a checkbox on the login form. The value “on” shows that the user has selected the option to remain logged in across sessions.
On viewing the response we can see the standard session cookie and stay-logged-in cookie.
Next, let’s copy the stay-logged-in cookie and go to the Decoder in Burp Suite. The Decoder tool allows us to decode the cookie's value, which might be encoded in a format such as Base64. By decoding it, we can understand the actual data stored in the cookie, which can be useful for analyzing its contents and understanding how the application handles persistent login sessions.
Paste stay-logged-in cookie in decoder and click on Decode as to select the base64options from menu. The cookie will be decoded and shown below.
We can see the decoded cookie. Upon viewing it we can see it includes the username and a hash.
Let’s try to crack that hash. Go to CrackStation.
Paste the copied hash into CrackStation and click on “Crack Hash.” The hash is successfully cracked, revealing that it is an MD5 hash that corresponds to Wiener’s password.
Through our analysis, we have learned that the stay-logged-in cookie is actually a Base64 encoded string that combines the username and the MD5 hash of the user's password in the following format:
username:md5hashpassword
For example, if the username is “wiener” and the MD5 hash of the password is “51dc30ddc473d43a6011e9ebba6ca770”, the stay-logged-in cookie will contain the Base64 encoded version of "wiener:51dc30ddc473d43a6011e9ebba6ca770"
We know the victim’s username and we have the password list so we can brute force the stay-logged-in cookie.
We can see that after login a GET request is also captured by burp which keeps the user logged in and that request contains stay-logged-in cookie.
To start brute force attack right click on the request and send that to intruder.
In intruder positions tab select Attack type to Sniper.
Click on “Clear §” to remove all the automatic payload positions. Highlight the value of the stay-logged-in cookie.
Click on “Add §” to mark this value as a payload position. It will be surrounded by § symbols.
Remove the session token from request as well.
We have the password list on the lab page.
Navigate to the “Payloads” tab in Intruder. you can see the Payload tab in the intruder section as shown below.
In the “Payloads” section, make sure “Payload set 1” is selected, corresponding to the position you marked.
Under “Payload sets”, select “Simple list”.
Copy the passwords provided and click on paste in intruder’s Payload section to add list.
Under “Payload processing” section, Click on add to add a payload processing rule.
A new window will open. Select Hash and type MD5 as shown in the image below.
Click OK to add the rule in list.
Click on add to add second payload processing rule.
A new window will open. Select Add prefix and we will add username of carlos as prefix as shown in the image below.
Click OK to add this rule in list.
Now, finally we need to encode this to base64 string.
Click on add to add Third payload processing rule.
A new window will open. Select Encode and select Base64-encoding type as shown in the image below.
Click OK to add this rule in list.
Now that we have set all the payloads click on “start attack” button.
Burp Suite will start sending requests after applying all processing rules we defined for payload and display the results in the Intruder tab.
Upon viewing the results we can differentiate unique requests based on status code and we found a request with status code 200.
Let’s Render the response of this request in intruder Results section and we can see that we have accessed the my-account page of victim “carlos”.
On the other hand, the lab is also marked as solved in browser.
Congratulations! The walkthrough of Ninth authentication lab finishes here.
You can see walkthrough of Tenth lab by clicking the following link:
