Authentication

From PortSwigger Academy

Description

Authentication is the process of verifying the identity of a given user or client. In other words, it involves making sure that they really are who they claim to be. At least in part, websites are exposed to anyone who is connected to the internet by design. Therefore, robust authentication mechanisms are an integral aspect of effective web security.

Three authentication factors :

• Something you know, such as a password or the answer to a security question.

• Something you have, that is, a physical object like a mobile phone or security token.

• Something you are or do, for example, your biometrics or patterns of behavior.

Authentication is the process of verifying that a user really is who they claim to be, whereas authorization involves verifying whether a user is allowed to do something.

Type of vulnerabilities

• 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".

Authentication mechanisms vulns

Password based login

Brute-force attacks

These attacks are typically automated using wordlists of usernames and passwords. Make your own based on the company you are pentesting. Check data breaches.

• Brute-forcing usernames

  • recognizable pattern disclosed ? Check also HTTP responses (admins, IT-support addresses ?)

  • high-privileged accounts with predictable usernames (admin, administrator, root...)

• Brute-forcing passwords

  • password policy ? mypassword -> Mypassword1! or Myp4$$w0rd

  • regular password change ? Mypassword1! ->Mypassword1? or Mypassword2!

Username enumeration

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.

Check any differences in :

• Status code -> If a guess returns a different status code, this is a strong indication that the username was correct.

• 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.

• 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. For example, a website might only check whether the password is correct if the username is valid. Test with a long password and display response columns in Burp intruder tab.

Flawed brute-force protection

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

  • Try to detect how many attempts is possible then try multiple usernames with a very short password list for each one. Check data breaches also.

  • Check if username enumeration is possible : test to lock a non existant random user, if it don't works you can then test with a wordlist with 5 times each possible usernames and see if you can determine existant accounts.

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

  • Is it possible to reset the counter after a successful attempt ? If yes, add a successfully login into the wordlist at regular intervals.

An other one :

• User rate limiting : In this case, making too many login requests within a short period of time causes your IP address to be blocked.

  • Is it possible to test more than one password in a single request ? For example by using JSON with an array of strings

"username" : "carlos",
"password" : [
    "123456",
    "password",
    "qwerty"
    ...
]

HTTP Basic Authentication

Authorization: Basic base64(username:password)

• user credentials are open to being captured in a man-in-the-middle attack if not https

• as the token consists exclusively of static values, this can leave it vulnerable to being brute-forced

• particularly vulnerable to session-related exploits, notably CSRF

Multi-factor authentication

This usually requires users to enter both a traditional password and a temporary verification code from an out-of-band physical device in their possession, for example an RSA token.

Bypassing two-factor authentication

• 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.

  • Could you directly skip to "logged-in only" pages after the first step without complete the 2FA ? you can try to discover these pages thanks to another account or using a tool such as dirbuster

Flawed two-factor verification logic

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.

1. For example, the user logs in with their normal credentials in the first step (POST /login/first ...... username=carlos&pass=qwerty)

2. They are then assigned a cookie that relates to their account, before being taken to the second step of the login process (Set-Cookie: account=carlos)

3. When submitting the verification code for the second step, the request uses this cookie to determine which account the user is trying to access (POST /login/second ........ Cookie: account=carlos ....... 2FAcode=123456)

4. 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/second ........ Cookie: account=victim ....... 2FAcode=123456)

5. 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.

Brute-forcing 2FA verification codes

As with passwords, websites need to take steps to prevent brute-forcing of the 2FA verification code. This is especially important because the code is often a simple 4 or 6-digit number. Without adequate brute-force protection, cracking such a code is trivial.

crunch 4 4 -t %%%% -c 2000 # 0001 -> 2000
crunch 6 6 -t %%%%%% # 000001 -> 999999

If the website log out the user after some attempts, you can still automate the process of login and brute force the 2fa using Burp Macros or the Turbo Intruder Extension.

Other authentication

In addition to the basic login functionality, most websites provide supplementary functionality to allow users to manage their account. For example, users can typically change their password or reset their password when they forget it. These mechanisms can also introduce vulnerabilities that can be exploited by an attacker.

Keeping users logged in

Usually a simple checkbox labeled something like "Remember me" or "Keep me logged in". Often implemented by generating a "remember me" token of some kind, which is then stored in a persistent cookie.

• Create an account and study the token/cookie in order to create an admin token/cookie.

  • Is the token guessable ?

  • Is it encrypted ? Hash without salt ?

  • Is it encoded ? Base64 ?

• This method can be used to bypass login attempt limits if a similar limit isn't applied to cookie guesses.

Remember that under "Payload processing" you can add rules which will be applied sequentially to each payload before the request is submitted.

For example in this token case :
    base64(username+':'+md5HashOfPassword)
1. Add the wordlist :
    123456
    qwerty
    ...
2. Add these rules :
    Hash: MD5
    Add prefix: victim:
    Encode: Base64-encode

• Could you use another technique such as an xss to steal the cookie ?

• If the website was built using an open-source framework, the key details of the cookie construction may even be publicly documented.

• In some rare cases, it may be possible to obtain a user's actual password in cleartext from a cookie, even if it is hashed.

Resetting user passwords

• vulnerable-website/reset-password?user=victim-user

  • Can you change the user parameter ?

• vulnerable-website/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

  • Could you simply visit the reset form from their own account, delete the token, and leverage this page to reset an arbitrary user's password ?

  • If the URL in the reset email is generated dynamically, this may also be vulnerable to password reset poisoning. In this case, an attacker can potentially steal another user's token and use it change their password.

  • Check for password reset poisoning

Changing user passwords

This feature rely on same process for checking that usernames and passwords match as a normal login page does so it can be vulnerable to same techniques.

• Can you access it directly without being logged ?

  • Hidden field with username ? Edit it for another user

  • Study the form. Can you enumerate usernames and brute force passwords ?

Third-party Authentication vulns

OAuth 2.0 authentication

While browsing the web, you've almost certainly come across sites that let you log in using your social media account. The chances are that this feature is built using the popular OAuth 2.0 framework. This framework enable websites and web applications to request limited access to a user's account on another application.

How does it work?

It works by defining a series of interactions between three distinct parties :

• Client application - The website or web application that wants to access the user's data.

• Resource owner - The user whose data the client application wants to access.

• OAuth service provider - The website or application that controls the user's data and access to it. They support OAuth by providing an API interacting with both an authorization server and a resource server.

There are numerous different ways that the actual OAuth process can be implemented. These are known as OAuth "flows" or "grant types". In this topic, we'll focus on the "authorization code" and "implicit" grant types as these are by far the most common. Broadly speaking, both of these grant types involve the following stages:

1. The client application requests access to a subset of the user's data, specifying which grant type they want to use and what kind of access they want.

2. The user is prompted to log in to the OAuth service and explicitly give their consent for the requested access. The client application receives a unique access token that proves they have permission from the user to access the requested data.

3. Exactly how this happens varies significantly depending on the grant type.

4. The client application uses this access token to make API calls fetching the relevant data from the resource server.

OAuth Scope

For any OAuth grant type, the client application has to specify which data it wants to access and what kind of operations it wants to perform. It does this using the scope parameter of the authorization request it sends to the OAuth service.

The scopes for which a client application can request access are unique to each OAuth service. As the name of the scope is just an arbitrary text string, the format can vary dramatically between providers.

scope=contacts
scope=contacts.read
scope=contact-list-r
scope=https://oauth-authorization-server.com/auth/scopes/user/contacts.readonly

When OAuth is used for authentication, however, the standardized OpenID Connect scopes are often used instead. For example, the scope openid profile will grant the client application read access to a predefined set of basic information about the user, such as their email address, username, and so on.

Authorization code grant type

Preventing attacks