API2–2023: Broken Authentication
Broken Authentication is a vulnerability that can happen when an application does not properly handle the different parts of authentication. This can include things like:
- How the application authenticates users.
- Brute-force attacks against authentication endpoints, such as credential stuffing and password spraying.
- Weak or poorly enforced password policies.
- Security of network and transport-layer communications.
- How authentication tokens and session identifiers are stored and managed.
- The use of weak cryptographic algorithms during authentication, especially when handling passwords.
One important thing to understand is that Broken Authentication is mainly focused on authentication, not authorization. Authentication is about verifying who the user is, while authorization is about verifying what that user is allowed to access.
For example, during authentication, a user might provide a username and password, an API token, or a one-time security token. If these authentication factors are valid, the application can identify the user. After that, authorization checks should determine whether that user actually has permission to access a particular resource or perform an action.
Business Impact
In the worst-case scenario, an attacker could take over another user’s account by exploiting a broken authentication vulnerability. Once the attacker has successfully taken over the account, they could authenticate as that user and perform actions using that user’s permissions.
Depending on what the compromised account has access to, this could lead to serious financial, reputational, and regulatory consequences for the affected company. It could also expose sensitive information belonging to the user or the organization.
With that in mind, I will be exploring the Authentication path from Web Security Academy. Let’s get started.
Authentication Vulnerabilities — Web Security Academy
Authentication vulnerabilities are basically security flaws in the way an application checks who a user is. If the design or implementation of the authentication system makes it possible for an attacker to pretend to be a legitimate user, then we have an authentication vulnerability.
This can potentially allow attackers to gain access to accounts or information that they should not have access to.
Username Enumeration via Different Responses
For this lab, the application is vulnerable to brute-force attacks, but before jumping straight into that, I first wanted to understand how the login endpoint responds to different inputs.
I started by testing a common default credential:
admin:admin
The application responded with “Invalid username.”
At first, this might not seem like a huge issue, but it actually gives an attacker useful information. The application is basically telling us that the username we provided does not exist. If the application instead responded differently when the username was valid, we could use those differences to identify valid usernames.
This is where techniques such as username enumeration, brute-force attacks, and password spraying become relevant.
Password spraying is a type of attack where an attacker tries one commonly used password against many different accounts before moving on to another password. This is different from a traditional brute-force attack, where an attacker might try many passwords against one account. Password spraying can be effective against applications that have weak password policies or do not properly detect repeated login attempts.
In this particular lab, however, I decided to start with a brute-force approach because I was provided with a username list and a password list.
One of the biggest clues came from the login responses. If an application tells you “Invalid username” for one request and “Incorrect password” for another, it is effectively giving you information about whether the username exists.
For example, if I receive:
Invalid username
I know the username probably doesn’t exist.
But if I receive:
Incorrect password
that gives me a strong indication that the username exists, and the problem is the password.
That difference in responses is a security weakness because it allows an attacker to enumerate valid usernames.
Finding a Valid Username
To start testing this, I submitted a failed login attempt and then looked at the HTTP traffic in Burp Suite.
I found the:
POST /login
request and sent it to Intruder.
Inside Intruder, I highlighted the username parameter and added it as the payload position. Burp then showed it as something similar to:
Get Gamuchirai’s stories in your inbox
Join Medium for free to get updates from this writer.
§admin§
I left the password as a static value for now because my first goal was to identify a valid username.
For the attack type, I selected Sniper.
A Sniper attack is the default and one of the most commonly used attack types in Burp Suite Intruder. It uses a single payload set and places the payloads into the selected injection point one at a time. In this case, that means Burp will take each username from my list and try it against the same password.
For the payload type, I used:
Simple list
Then, under the payload configuration, I pasted the usernames from the username list I was given.
Once everything was configured, I started the attack.
This is where I was mainly looking at the Length column in the Intruder results. For the first few requests, most of the responses had a length of around:
3352
So I had to be patient and look for something that stood out from the rest.
And this is where patience comes in lol. But seriously, sometimes the best thing you can do is step away for a moment, skip the lab for a bit, or go touch some grass. Your mind somehow comes back with fresh ideas.
Eventually, I found a response that was different.
When I tested the username in the browser, instead of getting “Invalid username”, I received:
“Incorrect password.”
This was the confirmation I was looking for. The username was valid, and now I just needed to find the password.
The username I identified was:
asai
Finding the Password
Now that I had a valid username, I could use a similar process to identify the password.
I went back to the POST /login request in Burp Suite and changed the username to the one I had found.
I then removed the username payload and replaced it with the password list.
This time, I wasn’t only looking at the Length column. I also paid attention to the Status Code.
Most of the failed login attempts were returning:
200 OK
and had response lengths around:
3441 or 3354
However, one of the requests stood out. It returned:
302 Found
with a much smaller response length of around:
186
That difference was a strong indication that something had changed in the application’s response. A 302 Found response is an HTTP redirect, and in this lab it indicated that the login attempt had succeeded and the application was redirecting the authenticated user.
After identifying the successful combination, I was able to log in using the credentials:
asia:asdfgh
This allowed me to successfully complete the lab and access the user’s account, where I could also see the user’s email address.
And this is where the impact of the vulnerability becomes much clearer. The problem isn’t simply that an attacker can guess a username and password. The bigger issue is that weaknesses in the authentication process can allow an attacker to identify valid accounts and eventually gain access to them.
In a real-world application, this could potentially expose sensitive account information and allow an attacker to perform actions as the compromised user.
Overall, this lab was a good example of how small differences in application responses can leak useful information to an attacker. Something as simple as returning “Invalid username” versus “Incorrect password” can make username enumeration possible, which can then make further attacks much easier.
Many to be continued, stay Tuned…
