Authentication

Usernames enumeration

  • Some username: admin, administrator ,firstname.lastname@somecompany.com

  • Compares responses between a valid user and an invalid user (and incorrect password). [One character out of place makes the messages distinct, even if not visible on the page]

  • Create account and see if there's error like "account already exists"

  • Account locking? (after a certain number of trials). It could mean that the account exists

  • Response times (a website may only check the password if the username is valid) entering an excessively long password causes a noticeable delay

  • Check HTTP responses to see if any email addresses are disclosed

Passwords

Password Cracking

Account locking

  • Guess password with locked account

    • With your account locked, send a request with an incorrect password and another with a correct password. Is the response different?

  • IP blocked?

    • The failed attempts counter resets if the IP owner logs in successfully. (Make sure that concurrent requests is set to 1)

    • Try to bypass by adding X-Forwarded-For header

  • With password change

    • See if you can change the password of an arbitrary user. Ex: look for a hidden username paramer (control it). Brute-force password when you enter your current password.

    • Tip: use your account and notice different behavior.

      • current password: wrong, new-password-1=XXX, new-password-2=XXX

      • current password: wrong, new-password-1=XXX, new-password-2=YYY

      • current password: <right>, new-password-1=XXX, new-password-2=XXX

      • current password: <right>, new-password-1=XXX, new-password-2=YYY

2FA

  • Brute-force

  • Bypassing two-factor authentication -> check if you can directly skip to "logged-in" pages

  • Flawed logic

# 1.1 step - Normal login with attacker account
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
[...]
username=attacker&password=qwerty


# 1.2 step - The server sets cookie
HTTP/1.1 200 OK
Set-Cookie: account=attacker
# 2 step - request two-factor
GET /login-steps/second HTTP/1.1
Cookie: account=attacker
# 3 step - submit the two-factor code with victim cookie
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

Remember me option

Some websites generate this cookie based on a predictable concatenation of static values, such as the username and a timestamp (or maybe even the password).

  • Study your cookie and deduce how it is generated

  • Sometimes this cookie is hashed or encoded (e.g. base64)

  • Now try to brute-force other users' cookies to gain access to their accounts

If the website uses salt it becomes much more complicated...

Password reset

  • Control username parameter

    • After you receive an email with the URL to reset your password, see if you can control username parameter.

    • POST /forgot-pwd?temp-token=xxx HTTP/2
[...]

user=<victim>&new-pwd-1=<whatever>&new-pwd-2=<whatever>&token=xxx

  • Resetting passwords using a URL (static token)

    • Poor implementation can use guessable parameter: Ex: http://vulnerable-website.com/reset-password?user=victim-user

  • Steal another user's token (for dynamic token)

    • Try adding the X-Forwarded-Host header and see if it allows you to control the link generated by the app. This way, you can insert your website's URL so that when the user clicks on the link, they are directed to http://your.website.com/reset-password?token=impredictabletoken.

Last updated