Hello ethical hackers! Today I share with you an account takeover I achieved during a recent penetration testing of a web application. For those who don’t know know what an account takeover is, there is a dedicated section for that. From there, I will explain how I enumerated all the endpoints. Then, I will walk you through the steps I took to gain access to the highest privilege account. It is going to be a fun and rewarding episode, so stay with me until the end!
Account takeover definition
Account takeover happens when an attacker, with low or no privileges, can take control of another account without authorization. For example, you can find customer account takeover in e-commerce platforms or any other service which manages user accounts.
Is account takeover a vulnerability?
I see account takeover qualified as a vulnerability. However, I don’t think this should be the case. In fact, I tend to describe it as a result of one or more vulnerabilities. Just like a data breach can be the result of a SQL injection vulnerability.
Account takeover scenarios
Based on the distinction we have just set between vulnerability and its outcome, many vulnerabilities can lead to account takeover. For example, you might have an open redirect vulnerability which leaks the user token upon login. In this scenario, an attacker can take over the victim’s account by simply clicking on a malicious link. There are many reports demonstrating account takeover on HackerOne’s Hacktivity, so make sure to check them out.
In the remaining of this episode, the scenario involves unauthenticated endpoints which, once combined, result in a full account takeover without user interaction.
Since this application had a separate front-end, I collected all the API endpoints. It is a tedious task, but it’s rewarding in the long run. I found many endpoints, but the most interesting ones were the user sign up feature, password resetting based on the user identifier and account listing based on the user email. You will see why shortly!
Before account takeover
Before I found how to achieve account takeover, I first tested the endpoints I collected earlier. During application mapping, there was a registration form which returned an error. I thought maybe it’s broken and I moved on. However, I now understand what’s happening.
The debug interface
It turns out that the application sends a confirmation email to the user. However, the mail server was down. Besides, the sign up requires approval from an employee. How did I know that? Well, I found a debugging portal on another port on the server which disclosed all the operations, including the back-end responses. One of them contained a mail server connection error, and another one returned the ID of the newly created user, which means that it has been successfully created, but not yet active.
Bypassing the approval step
If you recall, I mentioned earlier that I found a password reset API endpoint that uses the account ID. Guess what, I have the new user ID. So I quickly send the request. To my surprise, the response is positive and I can now log in as the new user without approval from an internal employee! As a bonus, I have a limited admin role, which is not as powerful as the System Admin, but it’s a good start to hunt for the ultimate account takeover. Sadly, the user identifiers were long and random, also known as UUIDs. Therefore, I needed a way to enumerate them.
Information disclosure to the rescue
Inspecting the debugging portal reveals exhaustive details about this specific feature, including the SQL query, which happened to be using the
LIKE operator in the
WHERE statement. The SQL query resembled something along the line of
select email from user where email LIKE ?. Although there is no SQL injection, I can still use the percent character
%, which returned the entire users from the database! A massive information disclosure!
System admin account takeover without interaction
We now have all the ingredients to get that System Admin account. Matter of fact, I didn’t know there is one until I dumped the entire database with that information disclosure vulnerability. I now have the System admin ID, which I use to reset the password, therefore achieving full account takeover of the System Admin user.
In terms of the impact, I essentially got full access to the application as the highest role possible, without any interaction from the victim.
Hopefully, you learned a trick or two on how to achieve account takeover during a web application penetration testing using a black-box approach.
Account takeover is one of the biggest security flaws. Depending on the level of access, attackers can compromise the entire web application or even the whole infrastructure. If you are a developer, I hope you learned why you must always implement authentication and access control on privileged endpoints. Besides, I recommend you request a penetration testing early in the development life cycle. That way, you will avoid any design flaws or business logic errors that will become expensive to patch later.
If you are new to hacking and want to learn the basics, start with the Ultimate guide to OWASP Top 10 and apply your knowledge on the lab which supports it. If you enjoy learning with videos, I invite you to watch the OWASP Top 10 Youtube playlist.