THM Authentication Bypass

THM Authentication Bypass Module Notes

A helpful exercise to complete when trying to find authentication vulnerabilities is creating a list of valid username.

Website error messages are great resources for collating this information to build our list of valid usernames.

Go to a login signup page, If you try entering the username admin and fill in the other form fields with fake information, you’ll see we get the error An account with this username already exists. We can use the existence of this error message to produce a list of valid usernames already signed up on the system by using the ffuf tool below. The ffuf tool uses a list of commonly used usernames to check against for any matches.

-w selects the file’s location on the computer that contains the list of usernames that we’re going to check exists.

-x argument specifies the request method.

-d argument specifies the data that we are going to send.

In the ffuf tool, the FUZZ keyword signifies where the contents from our wordlist will be inserted in the request.

-H argument is used for adding additional headers to the request.

-u argument specifies the URL we are making the request to

-mr argument is the text on the page we are looking for to validate we’ve found a valid username.

After getting the usernames from login page we save the usernames to a text file. With this text file we will bruteforce to the system.

A brute force attack is an automated process that tries a list of commonly used passwords against either a single username or, like in our case, a list of usernames.

Previously we used the FUZZ keyword to select where in the request the data from the wordlists would be inserted, but because we’re using multiple wordlists, we have to specify our own FUZZ keyword. In this instance, we’ve chosen W1 for our list of valid usernames and W2 for the list of passwords we will try. The multiple wordlists are again specified with the -w argument but separated with a comma. For a positive match, we're using the -fc argument to check for an HTTP status code other than 200.

Sometimes authentication processes contain logic flaws. A logic flaw is when the typical logical path of an application is either bypassed, circumvented or manipulated by a hacker.

The below mock code example checks to see whether the start of the path the client is visiting begins with /admin and if so, then further checks are made to see whether the client is, in fact, an admin. If the page doesn’t begin with /admin, the page is shown to the client.

if( url.substr(0,6) === '/admin') {
    # Code to check user is an admin
} else {
    # View Page
}

Because the above PHP code example uses three equals signs (===), it’s looking for an exact match on the string, including the same letter casing. The code presents a logic flaw because an unauthenticated user requesting /adMin will not have their privileges checked and have the page displayed to them, totally bypassing the authentication checks.

Cookie Tempering

Examining and editing the cookies set by the web server during your online session can have multiple outcomes, such as unauthenticated access, access to another user’s account, or elevated privileges.

The contents of some cookies can be in plain text, and it is obvious what they do. Take, for example, if these were the cookie set after a successful login:

Set-Cookie: logged_in=true; Max-Age=3600; Path=/
Set-Cookie: admin=false; Max-Age=3600; Path=/

We see one cookie (logged_in), which appears to control whether the user is currently logged in or not, and another (admin), which controls whether the visitor has admin privileges. Using this logic, if we were to change the contents of the cookies and make a request we’ll be able to change our privileges.