Authentication Vulnerability

What is Authentication Vulnerability?

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.

Multi-Factor Authentication

Two-Factor Authentication Tokens

• Some websites send a verification code via dedicated device or app (such as Google Authenticator)

• Other websites send a code via text message which is open abuse

  • Code is being transmitted via SMS rather than by the device itself

  • Code can be intercepted via SIM swapping among other means

Bypassing Two-Factor Authentication

• Try to go to “logged in pages” without entering the code — you might be able to bypass MFA completely Flawed Two-Factor Verification Logic

1. User logs in with normal creds

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

2. User is 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
   

3. 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: vulnerable-website.com
    Cookie: account=carlos
    ...
    verification-code=123456
   

4. You can change the “account” cookie to any username when submitting the code

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

Brute-forcing 2FA Verification Codes

• This can be automated by creating macros for Burp Intruder

• This can also be done with the Turbo Intruder extension

Password-Based-Login

Username/Password Enumeration

• Pay attention to the following:

  • Status Codes

  • Error Messages

  • Response Times

Bypassing Brute-Force Protections:

• Protection #1: Account lockout based on invalid login attempts

• Protection #2: Blocking IP based on many login attempts in quick success

  Both can be bypassed by adding valid login with your own credentials every few tries so there is not a succession of invalid login attempts

Bypassing Account Locking:

• Establish a list of candidate usernames that are likely to be valid. This could be through username enumeration or simply based on a list of common usernames.

• Decide on a very small shortlist of passwords that you think at least one user is likely to have. Crucially, the number of passwords you select must not exceed the number of login attempts allowed. For example, if you have worked out that limit is 3 attempts, you need to pick a maximum of 3 password guesses.

• Using a tool such as Burp Intruder, try each of the selected passwords with each of the candidate usernames. This way, you can attempt to brute-force every account without triggering the account lock. You only need a single user to use one of the three passwords in order to compromise an account

HTTP Basic Authentication

• Old but simple so sometimes is still in use

• Sends the username:password after base64 encoding it in the “Authorization” header of every response

• Can be compro+mised with a man-in-the middle attack

• Often do not support brute-force protection

• Partially vulnerable to session-related exploits such as CSRF

Resetting-Passwords

Resetting User Passwords

Some app send password by email

• Sending clear text of the user’s password should not be possible if password is stored securely

• Sending passwords over insecure channels can be exploited via a man in the middle attack

• Many users sync their emails across multiple devices increasing the attack surface

Resetting Passwords via URL

• Less secure ways use a URL with an easily guessable parameter: http://vulnerable-website.com/reset-password?user=victim-user

• Better practice is to generate a high-entropy, hard to guess token and create the URL based on that http://vulnerable-website.com/reset-passwordtoken=a0ba0d1cb3b63d13822572fcff1a241895d893f68164d4cc55b421ebdd48a8

$ Some websites still fail to validate the token so an attacker can visit the

$ Some website also generate token via time base or via order… This mean you can try to guest token value. (Ex: reset your own password and the very next second reset the victim password. If your reset link is ex: .com/reset/5439878/, the reset link of your victim could be .com/reset/54349879)

• exploitation example

  • Exploit Steps

    1. With Burp running, click the Forgot your password? link and enter your own username.

    2. Click the Email client button to view the password reset email that was sent. Click the link in the email and reset your password to whatever you want.

    3. In Burp, go to Proxy > HTTP history and study the requests and responses for the password reset functionality. Observe that the reset token is provided as a URL query parameter in the reset email. Notice that when you submit your new password, the POST /forgot-password?temp-forgot-password-token request contains the username as hidden input. Send this request to Burp Repeater.

    4. In Burp Repeater, observe that the password reset functionality still works even if you delete the value of the temp-forgot-password-token parameter in both the URL and request body. This confirms that the token is not being checked when you submit the new password.

    5. In the browser, request a new password reset and change your password again. Send the POST /forgot-password?temp-forgot-password-token request to Burp Repeater again.

    6. In Burp Repeater, delete the value of the temp-forgot-password-token parameter in both the URL and request body. Change the username parameter to carlos. Set the new password to whatever you want and send the request.

    7. In the browser, login to Carlos’s account using the new password you just set. Click My account to solve the lab.

Restricted-File

Restricted files that are not allow to be view by some users

• Possible to view some content by using some feature that has not be sanitized

  • ex: page/2 ——> Restricted

  • page/edit/2——> Not restricted (or possibility to view content)

Secure Authentication Mechanisms

• Take Care with User Credentials

  • Never send login data over unencrypted connections

  • Redirect HTTP requests to HTTPS

  • Audit website to make sure no username or emails are disclosed though HTTP responses

• Don’t Count on Users for Security

  • Implement an effective password policy

  • Provide real-time feedback on user’s password strength

• Prevent Username Enumeration

  • Use identical/generic error messages on all authentication pages

  • Return the same HTTP status code with each login request

  • Make response times indistinguishable

• Implement Robust Brute-Force Protection

  • Implement strict, IP-based user rate limiting

  • Require a user to complete a CAPCHA test with every login attempt after a limit is reached

• Check Verification Logic

  • Audit all verification logic to eliminate flaws

• Implement Proper MFA

  • Use a device or app that generates the code directly (not SMS or email)

  • Make sure MFA logic is sound