Broken Access Control-OTP Bypass-Account Takeover
While reviewing a web application using the Burp Suite tool, I noticed that an API was employed in the background. All actions within the application were authorized using a JWT token under the title of “Authorization.”
About Broken-Access Control
What is Broken Access Control?
Broken Access Control refers to a vulnerability in web applications that allows users to gain unauthorized access to resources or functionalities that they should not have access to. Let’s break it down:
Definition:
Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others.These checks are performed after authentication, and they govern what ‘authorized’ users are allowed to do. The SSH cryptographic network protocol operates on a client-server model. That is, the client initiates a connection to the server, and communication is established after authentication takes place. SSH can use both password and private key authentication, the latter of which is considered more secure. Learn more
Implementing robust access control is insidiously difficult. Developers often underestimate the complexity.
A web application’s access control model is closely tied to the content and functions it provides.
Users may fall into different groups or roles with varying abilities or privileges.
Ad-hoc Rules:
Access control rules scattered throughout the code become unwieldy and hard to understand.
Flawed Schemes:
Many flawed access control schemes are easy to discover and exploit.
Consequences:
Once a flaw is found, attackers can view unauthorized content, change or delete data, perform unauthorized functions, or even take over site administration.
Clearly document an access control policy and enforce it.
Validate the correctness of the access control implementation through code reviews.
Broken Access Control
Step:1 In my reviews, I first started to review the web application with the Burp Suite tool. The most important thing I noticed was that an API was used in the background and all of our actions on the application were authorized with the JWT token under the title of “Authorization”.
.png)
Step:2 After noticing these requests, I replaced the token of the authorized user with the token of the unauthorized user in order to check whether the unauthorized user can access these parts only with the JWT token change. You can access the request before changing from the image below.
.png)
Step:3
OTP Bypass-Account Takeover :
While reviewing the site, I later noticed the values in the password reset field. The image of the existing password reset field was as follows..png)
Step:4 After entering the username in the relevant field and clicking the send button, I noticed that you sent a password reset e-mail to the e-mail belonging to that account.
.png)
I noticed that the “code” field on the relevant URL is the same as the “SecurityStamp” I found with the Broken Access Control vulnerability. This meant that I could access the password reset area of the authorized user as long as I knew the “SecurityStamp” code. Then I tried to access the password reset area with the “SecurityStamp” code of the authorized user that I obtained in the first stage.
Step:5 With the code I obtained, I was able to access the password reset area of the authorized user. Later, I tried to do a normal operation by entering the username I discovered this field, but the presence of the OTP code prevented this. I wanted to make the request primarily for my own user. You can find the request for this area below.
.png)
Step:6 The “ClaimId” part of this request attracted my attention, and then I made another request in the same way, and I saw that the “ClaimId” parameter in this request was the next number, 33416. At this moment, I thought of this. If I open the password reset field in two accounts at the same time and use the OTP code I obtained for your own account by changing the “ClaimId” parameter in the request made for the authorized user, will it work? With this thought, I immediately took action and started the transactions. I accessed the password reset area with the “SecurityStamp” code I found. At the same time, I started to do the same operations within my own user.
Step:7 First of all, I asked for a password reset link for my own account. Later, I accessed the password reset link of the authorized user using the “SecurityStamp” code I obtained with the Broken Access Control vulnerability. Later, I made the same transaction for my own account and requested OTP for both accounts. The code in the request I made for my own user was returned as 33417, which meant that the code in the request I made for the authorized user was returned as 33418. In the request I made for the authorized user, I changed the “ClaimId” parameter to 33417 and entered the OTP code that came to me.
Step:8 HTTP Request
.png)
Step:9 Later, I saw that the request led to another request. This request was as follows.
.png)
Step:10 The information here was completely belonging to the authorized user. After directing this request. And BINGOO!!!! I had the admin account all to myself.
.png)
A good part of the process was normally terminating my session when I made a password reset or change specific to this web application. But when I changed the password in this way, it did not terminate the session and not even the soul of the account holder heard it. Another finding was that an old password could be entered in the password reset fields as Esktra.
Conclusion:
Accessibility should be considered in API configurations, authorization transactions and token use. This type of attack can lead to very high costs. Theback-end developer and employees interested in the test automation process should pay attention to the configurations and test processes in these steps.