Broken Authentication | TryHackMe

Learn how to defeat logins and other authentication mechanisms to allow you access to unpermitted areas.Learn how to defeat logins and other authentication mechanisms to allow you access to unpermitted areas.

Authentication is the process by which a web application verifies the identity of the user making a request. It typically takes place at the application server, which compares the credentials submitted by the client against records held in a credential store. When the credentials match, the server issues a session token that is returned on every subsequent request until the session expires, and the application uses that token to decide what the request is allowed to do.

An authentication bypass is any attack that allows a user to reach functionality restricted to a given account without supplying the correct credential for that account. Bypass attacks do not always require guessing a password or stealing a session token. Many succeed by exploiting assumptions the developer made about how the authentication process would be used, or by modifying data that the server trusts without independent verification.

Target Environment

Start the machine using the button at the top of this task and wait for the IP address to appear in the banner before continuing. Every tool used in the room is pre-installed on the AttackBox, which can be launched with the green button at the top of the screen.

Learning Objectives

By the end of this room, you will be able to:

• Enumerate valid usernames from differences in a signup form’s response using ffuf
• Brute-force a login form with a custom username list and a password wordlist
• Identify and exploit a parameter pollution flaw in a password reset workflow with curl
• Modify plain text, hashed, and base64-encoded cookies to change the authenticated state the server sees

Answer the questions below

• What is the name for the practice of reusing credentials recovered from one application against unrelated applications?

Credential Reuse

• What is the username starting with si*** ?

simon

• What is the username starting with st*** ?

steve

• What is the username starting with ro**** ?

robert

• What is the valid username and password (format: username/password)?

steve/thunder

• What is the flag from Robert’s support ticket?

THM{AUTH_BYPASS_COMPLETE}

• What is the flag from changing the plain text cookie values?

THM{COOKIE_TAMPERING}

• What is the value of the md5 hash 3b2a1053e3270077456a79192070aa78 ?

463729

• What is the base64 decoded value of VEhNe0JBU0U2NF9FTkNPRElOR30= ?

THM{BASE64_ENCODING}

• Encode the following value using base64 {“id”:1,”admin”:true}

eyJpZCI6MSwiYWRtaW4iOnRydWV9

COCLUSION

Authentication bypass vulnerabilities are usually caused by poorly coded web applications or poorly configured session management. There are, however, secure coding methods and design patterns that reduce the chances of being vulnerable to each class of attack covered in this room.

Mitigating Username Enumeration

Username enumeration is mitigated by returning indistinguishable responses for registered and unregistered values on every authentication-related endpoint, including signup, login, and password reset. Response bodies, status codes, and timing must all match between the two cases. A well-designed registration flow, for example, accepts any submission and sends a confirmation email to the supplied address. If the address is already registered, the email explains that a duplicate registration was attempted, but the response returned to the browser is identical in either case.

Rate limiting and CAPTCHAs provide an additional layer of defence by raising the cost of running an automated enumeration against exposed forms. These controls do not close the underlying leak, but they slow exploitation enough that the activity is more likely to be detected before the enumeration completes.

Mitigating Brute Force

Brute force is slowed by rate limiting on authentication endpoints and stopped by account lockout after a threshold number of failed attempts. Both controls must be carefully tuned to avoid producing a denial-of-service vector against legitimate users. Multi-factor authentication is the most effective single defence, because it ensures that a password alone is insufficient even when it has been guessed correctly.

Password policies that require length, complexity, and rotation interact with brute force in subtle ways. A long passphrase is highly effective against brute force; a short, complex password is not. Policies that encourage users to choose short, complex passwords with frequent rotation often produce weaker outcomes than policies that require long, memorable passphrases with lower rotation frequency.

Mitigating Logic Flaws

Logic flaws are the hardest class to prevent, because they depend on decisions specific to each application. The general principle is that every security-relevant decision should read its inputs from a single, trusted source. A password reset workflow that loads the target account from the query string should compose the outgoing email using the address associated with that account in the database, not using a value re-read from the request.

Frameworks and language features that silently merge inputs from multiple sources should be avoided in security-relevant code paths. In PHP, explicit access to $_GET, $_POST, and $_COOKIE should be preferred over $_REQUEST. In other languages and frameworks, the equivalent principle is to read each request parameter from exactly one well-defined location.

Mitigating Cookie Tampering

Cookie tampering is prevented by one of two approaches. The first is to sign session tokens with a strong server-side secret, typically using a construction such as HMAC or a signed JSON Web Token (JWT). The signature ensures that any modification to the cookie value invalidates the token, and the server can reject forged cookies without needing to consult any external state. The second approach is to issue only an opaque session identifier and hold the actual session state in a server-side store such as Redis or a database. Because the cookie contains no meaningful payload, there is nothing for an attacker to modify.

Hashing a cookie value is not a substitute for either of these approaches. A hash proves only that the client has seen some value; it does not prove that the value was issued by the server or that it has not been modified since.

Further Reading

The OWASP Top 10 room covers broken access control and identification failures in more depth. The HTTP in Detail room covers the request and response mechanics that every attack in this room depends on.