Authentication vulnerabilities
Last updated
Last updated
Authentication is the process of verifying the identity of a user or client that wants to access a service or application. There are several types of authentication depending on the credentials presented by the client to prove its identity (something you know, something you have or something you are). This is not to be confused with authorization, which is the process of checking what permissions or rights a user has over certain services or applications.
Although authentication and authorization are different concepts, they are closely related and usually work together. Normally, the first step is to identify the user and, once it's been verified he or she is who claims to be, then check what services or applications has permissions to use. For example, in Kerberos both actions are performed by two different entities. The KDC authenticates the user and grants a TGT ticket as a proof of identity. Then, the user is to present this TGT to prove its identity to each application server or service it wants to access, who is in charge to verify what permissions the user has over it.
Authentication, X-Forwarded-For, username enumeration, pitchfork attack, cluster bomb attack.
https://portswigger.net/web-security/authentication
We have to guess application behavior based on response times.
An IP-based brute protection is in place so first we'll investigate how this protection works.
Try three consecutive fail logins.
A hint is provided on how to bypass this protection by manipulating HTTP headers. The trick to bypass it is to just to add an X-Forwarded-For header with a single number in the HTTP request.
Now that we know how to bypass protection, let's try to find out how the application works by analyzing the response times. Bear in mind that you have to increase the X-Forwarded-For every time the IP-based protection locks you out.
To test the application, send a login request to Repeater, add the header, try a failed login and check the response time (response times are displayed in the lower right corner).
When both username and password are correct, application answers with a 302 code, time around 55 ms.
When invalid credentials are used, response times are increased in proportion to the password length.
Response time dramatically increases when we use a longer password with an existing username. This is due to backend delay processing long passwords.
Let's see what happens when we use both a wrong username and a long password (increase the X-Forwarded-For value as needed to bypass protection).
In this case response time does not increase.
The conclusion about how the application works is: first username is checked, if wrong, nothing else is done; if right, the password is processed. Thus, response time is increased if a true username and a long password are entered.
We have all the info we need to bruteforce the username. Create a pitchfork attack using 2 payloads (in a pitchfork attack each element of the first payload will be sent with its matching element of the second payload). The first payload will be the user list and and the second will be a sequential numbers payload for the X-Forwarded-For header.
Launch the attack and inspect the results.
We see there is a username with a higher response time than the others. The time is similar to what we saw in the previous test. Therefore, the password was processed in this attempt, which suggests the username probably exists.
Bruteforce again using the found username and the list of passwords. Update the payloads accordingly.
Find the 302 status code in the results list.
Use the credentials to login. You have solved the lab.
In this case the application uses account locking, but it contains a logic flaw. Exploit it to enumerate a valid username and bruteforce this user's password.
First step is to find the valid username, this will be the account that is locked after three failed attempts.
Create a small wordlist with five random passwords.
Now we need to try all of the usernames with every of these five passwords, then find the account that is locked. This will be the correct username.
This is done with Intruder's cluster bomb attack. In this attack Intruder iterates through all possible payload combinations. It is different from the pitchfork attack we used before, which is more like a credential stuffing attack, where first element of first payload is tested with first element of second payload, second with second, third with third, and so on.
Launch the attack and take note of the account that gets locked. You notice it because the size of the response is slightly different.
Now we have to bruteforce this account; however, there is a protection in place. We can only do only three unsuccessful login attempts, after that the account will get locked.
The exercise says there is a logic flaw in the backend. It can be easily identified by bruteforcing the password and analyzing the results.
There is one request that has a different length than the others. This is the logic flaw, even though the account is locked, the application still recognizes the valid credential.
Just use this password login, you have solved the lab.
