Burpsuite Academy Authentication Vulnerabilities

Broadly speaking, most vulnerabilities in authentication mechanisms arise in one of two ways:

The authentication mechanisms are weak because they fail to adequately protect against brute-force attacks.

Logic flaws or poor coding in the implementation allow the authentication mechanisms to be bypassed entirely by an attacker. This is sometimes referred to as "broken authentication".

The impact of authentication vulnerabilities can be very severe. Once an attacker has either bypassed authentication or has brute-forced their way into another user's account, they have access to all the data and functionality that the compromised account has. If they are able to compromise a high-privileged account, such as a system administrator, they could take full control over the entire application and potentially gain access to internal infrastructure.

Even compromising a low-privileged account might still grant an attacker access to data that they otherwise shouldn't have, such as commercially sensitive business information. Even if the account does not have access to any sensitive data, it might still allow the attacker to access additional pages, which provide a further attack surface. Often, certain high-severity attacks will not be possible from publicly accessible pages, but they may be possible from an internal page.

Username enumeration is when an attacker is able to observe changes in the website's behavior in order to identify whether a given username is valid.

Username enumeration typically occurs either on the login page, for example, when you enter a valid username but an incorrect password, or on registration forms when you enter a username that is already taken. This greatly reduces the time and effort required to brute-force a login because the attacker is able to quickly generate a shortlist of valid usernames.

While attempting to brute-force a login page, you should pay particular attention to any differences in:

Status codes: During a brute-force attack, the returned HTTP status code is likely to be the same for the vast majority of guesses because most of them will be wrong. If a guess returns a different status code, this is a strong indication that the username was correct. It is best practice for websites to always return the same status code regardless of the outcome, but this practice is not always followed.

Error messages: Sometimes the returned error message is different depending on whether both the username AND password are incorrect or only the password was incorrect. It is best practice for websites to use identical, generic messages in both cases, but small typing errors sometimes creep in. Just one character out of place makes the two messages distinct, even in cases where the character is not visible on the rendered page.

Response times: If most of the requests were handled with a similar response time, any that deviate from this suggest that something different was happening behind the scenes. This is another indication that the guessed username might be correct. For example, a website might only check whether the password is correct if the username is valid. This extra step might cause a slight increase in the response time. This may be subtle, but an attacker can make this delay more obvious by entering an excessively long password that the website takes noticeably longer to handle.


--LAB 1--
1. First Brute-Force the username.(Response Length is different for correct one)
2. Bruteforce the password after that. One by one. (Redirects 302 for correct one)
3. Vulnerability is that showing if username or password is incorrect seperately.


--LAB 2--
1. On the Options tab, under Grep - Extract, click Add. In the dialog that appears, 
scroll down through the response until you find the error message 
Invalid username or password.. Use the mouse to highlight the text content of the message. 
The other settings will be automatically adjusted. Click OK and then start the attack.
2. When the attack is finished, notice that there is an additional column containing the 
error message you extracted. Sort the results using this column to notice that one of 
them is subtly different. That is the username.


--LAB 3--
1. Identify that the X-Forwarded-For header is supported, which allows you to spoof 
your IP address and bypass the IP-based brute-force protection.
2. Add payload positions for the X-Forwarded-For header and the username parameter. 
Set the password to a very long string of characters (More than 100 characters should do it).
3. When the attack finishes, at the top of the dialog, click Columns and select the 
Response received and Response completed options. These two columns are now displayed 
in the results table. Get username from it.
4. Then attack with password list.

It is highly likely that a brute-force attack will involve many failed guesses before the attacker successfully compromises an account. Logically, brute-force protection revolves around trying to make it as tricky as possible to automate the process and slow down the rate at which an attacker can attempt logins. The two most common ways of preventing brute-force attacks are:

Locking the account that the remote user is trying to access if they make too many failed login attempts

Blocking the remote user's IP address if they make too many login attempts in quick succession

Both approaches offer varying degrees of protection, but neither is invulnerable, especially if implemented using flawed logic.

For example, you might sometimes find that your IP is blocked if you fail to log in too many times. In some implementations, the counter for the number of failed attempts resets if the IP owner logs in successfully. This means an attacker would simply have to log in to their own account every few attempts to prevent this limit from ever being reached.

In this case, merely including your own login credentials at regular intervals throughout the wordlist is enough to render this defense virtually useless.


--LAB 4--
1. On the Resource pool tab, add the attack to a resource pool with Maximum concurrent 
requests set to 1. By only sending one request at a time, you can ensure that your login
 attempts are sent to the server in the correct order.
2. On the Payloads tab, select payload set 1. Add a list of payloads that alternates 
between your username and carlos. Make sure that your username is first and that carlos 
is repeated at least 100 times.
3. Edit the list of candidate passwords and add your own password before each one. 
Make sure that your password is aligned with your username in the other list. (pitchfork attack)


--LAB 5--
1.Select the attack type Cluster bomb. Add a payload position to the username parameter.
Add a blank payload position to the end of the request body by clicking Add § twice. 
2. On the Payloads tab, add the list of usernames to the first payload set. For the 
second set, select the Null payloads type and choose the option to generate 5 payloads.
(You will get the username from here where error will be You have made too many incorrect 
login attempts) 
This will effectively cause each username to be repeated 5 times. Start the attack.
3. Add the list of passwords to the payload set and create a grep extraction rule for 
the error message. Start the attack.(Here you will get password which says no error)


--LAB 6--
1. With Burp running, investigate the login page. Notice that the POST /login request 
submits the login credentials in JSON format. Send this request to Burp Repeater.
2. In Burp Repeater, replace the single string value of the password with an array of 
strings containing all of the candidate passwords. For example:

"username" : "carlos",
"password" : [
    "123456",
    "password",
    "qwerty"
    ...
]
3. Send the request. This will return a 302 response.
4. Right-click on this request and select Show response in browser. Copy the URL and 
load it in the browser. The page loads and you are logged in as carlos.
5. Click My account to access Carlos's account page and solve the lab.

Bypassing 2 Factor Authentication

At times, the implementation of two-factor authentication is flawed to the point where it can be bypassed entirely.

If the user is first prompted to enter a password, and then prompted to enter a verification code on a separate page, the user is effectively in a "logged in" state before they have entered the verification code. In this case, it is worth testing to see if you can directly skip to "logged-in only" pages after completing the first authentication step. Occasionally, you will find that a website doesn't actually check whether or not you completed the second step before loading the page.


--LAB 1--
1. Log in using the victim's credentials.
2. When prompted for the verification code, manually change the URL to navigate to 
/my-account. The lab is solved when the page loads.

Sometimes flawed logic in two-factor authentication means that after a user has completed the initial login step, the website doesn't adequately verify that the same user is completing the second step.

For example, the user logs in with their normal credentials in the first step as follows:


POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

They are then assigned a cookie that relates to their account, before being taken to the second step of the login process:


HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

When submitting the verification code, the request uses this cookie to determine which account the user is trying to access:


POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

In this case, an attacker could log in using their own credentials but then change the value of the account cookie to any arbitrary username when submitting the verification code.


POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

This is extremely dangerous if the attacker is then able to brute-force the verification code as it would allow them to log in to arbitrary users' accounts based entirely on their username. They would never even need to know the user's password.


--LAB 2--(Without password login because of 2Factor)
1. With Burp running, log in to your own account and investigate the 2FA verification 
process. Notice that in the POST /login2 request, the verify parameter is used to 
determine which user's account is being accessed.
2. Log out of your account.
3. Send the GET /login2 request to Burp Repeater. Change the value of the verify 
parameter to carlos and send the request. This ensures that a temporary 2FA code is 
generated for Carlos.
4. Go to the login page and enter your username and password. Then, submit an invalid 
2FA code.
5. Send the POST /login2 request to Burp Intruder.
6. In Burp Intruder, set the verify parameter to carlos and add a payload position 
to the mfa-code parameter. Brute-force the verification code.
7. Load the 302 response in the browser.
8. Click My account to solve the lab.