Common Session Variables - Auth Bypass
In our first instance of session puzzling, we will have a look at a basic scenario in which a session variable is re-used in multiple places. Successfully identifying session puzzling vulnerabilities can be challenging. The process of looking for these types of vulnerabilities is similar to the process of looking for business logic vulnerabilities. We have to identify places where session variables are used and think of what might go wrong on the web server. Let's have a look at a basic example of common session variables that lead to an authentication bypass.
Identification
Overview of the Web Application
The exercise below is a simple web application that provides login functionality. After logging in with the provided credentials, the application displays basic user information:
http://<SERVER_IP>:<PORT>/profile.phpStatus page showing "logged in" with username "htb-stdnt". Description: "This is the user for HackTheBox Academy students." Navigation includes Home, About, Contact, and Log out.
When logging back out, we can see that the application also provides a Forgot password functionality. After providing our username, we have to answer a security question:
http://<SERVER_IP>:<PORT>/reset_2.phpQuestion prompt asking "What is 2+2?" with an answer input field and a "Submit" button.
After answering the question correctly, we are allowed to set a new password for the account. Let's try to access another user's account by resetting their password. When trying to set the username admin, we can see the admin user's security question:
http://<SERVER_IP>:<PORT>/reset_2.phpSecurity question asking What is your first pet's name? with an answer input field and a Submit button.' Unfortunately, we do not know the answer to that question. So instead, let's analyze the network traffic to see if we can identify a session puzzling vulnerability.
Analyzing Session Variables
When analyzing the network traffic generated during a password reset flow, we can see that there are multiple steps:
In the first step, we provide the user name.
In the second step, we provide the answer to the security question.
In the third step, we provide the new password.
Since these steps are handled in subsequent HTTP requests, and the answer to the previous steps is not contained in the follow-up requests, we can deduce that session variables are used to store user information. More specifically, when we supply the response to the security question, our request does not contain the username. However, the backend somehow has to know our user information to check whether our response was correct. Therefore, it is likely that user information was stored in the session variables:
We can verify this by sending the same request again without the session cookie. We are now getting redirected back to the login page and a new session is created:
So after analyzing the traffic, we now know that session variables are used in the multi-part password reset flow to store information about the user. The next question is: how do we identify and exploit a vulnerability?
Exploitation
In the previous subsection, we identified that the first step of the password reset process makes the backend store user information in session variables. How could we exploit that?
The first approach could be to attempt to bypass the security question altogether. We can first send the username admin to the endpoint /reset_1.php, which would make the web server store the admin user in the session variables. If there is no additional check, we could maybe access the password reset endpoint /reset_3.php directly, skipping the security question. Let's try this by first setting our username to admin with the following request:
We can see that we get a fresh session cookie and are redirected to the second step. Let's now use that session to attempt a password reset directly at /reset_3.php thereby skipping the security question:
The web server tells us that we need to complete phase 2 (which is the security question) first and redirects us back to the login page. So that apparently did not work.
Another potential vulnerability would be the re-use of the same session variable for the password reset process and the authentication process. If successful authentication stores the logged-in user in the same session variable that the web server uses to store the user in the password reset process, we might be able to bypass authentication entirely.
To test for that, click on Forgot Password? and enter the username admin. Afterward, access the post-login endpoint at /profile.php directly. We are now logged in as the admin user by exploiting our first session puzzling vulnerability.
Make sure that you understand why this vulnerability exists on the backend. The web server checks whether a user is logged in by checking whether the session variables contain a valid username. However, the same session variable is used in the password reset process, such that we can set the username with the password reset functionality and then bypass the authentication check.
In simplified code, the vulnerability results like this. The first phase of the password reset process in reset_1.php sets the session variable Username to the username provided by the user:
The authentication process utilizes the same session variable and authentication in profile.php only checks if this session variable is set:
Last updated