There has been a significant rise in web application attacks in 2021 as seen in numerous reports that have been published. With the increasing adoption of modern technologies, we have further relied on web applications removing obstacles for us throughout. However, the other side to it’s rise in adoption is that it increases the attack surface for attackers as now they have much more to try their skills on.
The detailed analysis including statistics that were reported by multiple reports describing the cost of breaches has been discussed in the previous post: The State of Web Application Security in 2021.
I recently was testing a web application that heavily relied on APIs. Enumerating through the scope when I discovered a few APIs I decided to test them up. The APIs were authenticating each call using an additional header ‘Authorization’ which contained an authorization token that was automatically generated when a user logged in.
Moreover I continued exploring their application’s functionalities, they offered a guest account which was generated within a second as soon a user clicked for it. What I though of it was it must generate an authorization token automatically for it right? Turned out that I was right about it. Not just it, soon I noticed that once the authorization token was generated it only expired if the user logged-out but not when the user’s session expired.
I started using that guest account’s generated authorization token to communicate with the APIs. There was this one API that fetched user’s data when it had to display it at the user’s profile. The issue with the API was that it did not authenticate the userID that was provided so it returned the user’s data as per the userID that was given in the call’s parameter. The userIDs existed in incremental procedure and hence finding user’s userID wasn’t much of a problem here.
This was itself an enough risk but having a look at the user data that was provided in the response, there was more to it. The response returned an object with user details, that included a key named ‘password-reset-token’ which was quite interesting as it can be seen.
Since the user IDs in the database were assigned to users in an incremental way, I decided to chain these issues up and write a python script that made calls to the API and for each user and dumped it’s data to a json file locally.
How does it lead to user’s account takeover?
An Account Takeover attack is where an unauthorized party seizes access and control over a user account. In the consumer world, this can be an online bank account, Facebook account or even something like your League of Legends account. For employees, it relates to the accounts that employees use to do their jobs like M365, Zoom or Salesforce.Robin Gray – Wandera
Chaining these all vulnerabilities together, the following attack scenario leads to the account takeover:
- a user’s email can be easily fetched through the API calls, as demonstrated through the python proof-of-concept exploit.
- The user’s email is used and the forgot password functionality is used on the web application for its backend to generate a password reset token.
- The generated password reset token can be fetched using the API call again as it returns with complete user details.
- The fetched reset password token is used to reset password for the victim.
Have anything to say? Please share it in comments.