OWASP TimeGap Theory Handbook
Search…
⌃K

Challenge 2 – Login

The starting point for all users.Rate limited to avoid brute force attacks.
Login pages are the user's starting point in many web apps. They collect username/email and password and create user sessions if they are valid.
Let us look at a sample login page flow:
A close up of text on a white background Description automatically generated
There is an obvious flaw here. Let us review it:
  1. 1.
    Tom is an attacker
  2. 2.
    Tom wants to break into Jerry’s account
  3. 3.
    Tom tries [email protected], [email protected], etc
  4. 4.
    Tom gets account does not exist error
  5. 5.
    Tom tries [email protected]​
  6. 6.
    Tom gets invalid password error. This means there is a user account with [email protected] as user name
  7. 7.
    Tom tries logging into the portal with [email protected] and 1,2,3,a,b,c etc. as the password
  8. 8.
    Tom gets invalid password error for all of them
  9. 9.
    Then Tom tries jerry as the password and Boom! Tom just logged in to the portal as Jerry
The above scenario is a major headache for all login pages. These types of attacks are known as dictionary or brute force attacks. There are multiple ways to protect login pages from brute force attacks - captchas, delays, account lockouts, generic error messages etc.
What happens if we revise the current login page design with account lockouts. If the user is not able to login successfully within a few tries, the portal will lock the user’s account.
A close up of a logo Description automatically generated
As you can see, the account lockout is achieved by storing the number of failed login attempts on the server side. For every failed login attempt, the app will increment the counter. If the value exceeds a certain point, for example 3, the portal will lock the account.
The high-level steps are:
  1. 1.
    User enters the correct username but the wrong password.
  2. 2.
    Portal increases the failed login attempt count to 1.
  3. 3.
    User enters the wrong password again.
  4. 4.
    Portal increases the failed login attempt count to 2.
  5. 5.
    User enters the wrong password one more time.
  6. 6.
    Failed login attempt count reaches 3.
  7. 7.
    The portal locks out the user out of their account.
Sounds good? Let us verify this in our lab:
  1. 1.
    Open your browser
  2. 2.
    Navigate to the login page
  3. 3.
    Enter [email protected] as the username
  4. 4.
    Enter abcd as the password
  5. 5.
    Click on the Login button a few times
  6. 6.
    Initially, you will get an error message that goes Login failed
  7. 7.
    After a few tries, you will see a different error message - Your account is locked out
  8. 8.
    You have been locked out of the user account
  9. 9.
    Now, change the password from abcd to tom
  10. 10.
    Click on the login button again
  11. 11.
    The system will not allow you to login even with the correct password because the account is locked
What if we perform all these login attempts in a single try before the server updates the failed login attempt counter on the database? Let us check that theory.
By default, TimeGap Theory will lock the user account on the third wrong attempt. In order to successfully test our attack, we would need more than three browser windows. That kind of spoils the fun, doesn’t it? Let us reduce the maximum failed attempt to 1. This way, we just need two browser windows to test.
  1. 1.
    On your browser, navigate to the Settings page
  2. 2.
    Change the login attempt count to 1
  3. 3.
    Click on the Save button
  4. 4.
    Stay on the Settings page, we need to do one more thing
Time to slow down TimeGap Theory:
  1. 1.
    Change the Main wait to 5 seconds
  2. 2.
    Click on the Save button
Now, TimeGap Theory will wait 5 seconds before every database write operation. This write operation includes failed login attempts values.
Preparation Phase
  1. 1.
    Open two browsers side by side (Use a private/incognito window if you do not have two browsers).
  2. 2.
    On both the browsers:
    1. 1.
      Navigate to the login page
    2. 2.
      Click on the second user button this time - this will fill the form with details of the user Jerry
Alright, the preparation is done. Here comes the exploitation phase.
Exploitation Phase
  1. 1.
    Click on the Login button on the first browser
  2. 2.
    In the second browser quickly also click on the Login button
Post-exploitation Phase
  1. 1.
    Wait for both the browsers to complete the request
  2. 2.
    You should see the login attempt was successful on the second browser
  3. 3.
    Check the user login attempt count is greater than 1. Phew
  4. 4.
    If you check your score, you should see you have 100 points
  5. 5.
    Before moving on, revert the delay to 0 on the settings page

Automation Time

There is no way we can perform a brute force attack like this in real life. You cannot call the webmaster and ask them to delay the server. Browser Dev Tools to the rescue again.
First, we need a valid fetch request:
  1. 1.
    Open your browser (Chrome or Firefox)
  2. 2.
    Navigate to the login page
  3. 3.
    Click on any of the user buttons
  4. 4.
    Open up dev tools by pressing F12 on the browser
    1. 1.
      On Windows, you can use Ctrl + Shift + I
    2. 2.
      On Mac, you can use Cmd + Shift + I
  5. 5.
    On the login page, click on the Submit button
  6. 6.
    On the browser dev tools, click on the Network tab
  7. 7.
    Right click on the login.php request
  8. 8.
    Click on Copy > Copy as fetch
Paste this in the Console tab of the browser dev tools. It should like the following:
It is okay if you see a request with some more elements. We trimmed down the unwanted portions to make it look clean.
But that’s just one request.
We are talking about brute forcing here. We need a minimum of 5 for this simulation.
Copy and paste the fetch request without pressing the Enter key. However, it is a good practice to separate each request with a comma. Let us do that.
We also changed the password value in each request. The first four requests have the wrong password. The last request has the correct password.
Before running this new command, we need to clear the slate. It involves three simple steps:
  1. 1.
    Ensure that there is no delay
    1. 1.
      Go to TimeGap Theory > Settings
    2. 2.
      Set the Main wait to 0
  2. 2.
    Refresh the user accounts.
    1. 1.
      Go to TimeGap Theory > Admin
    2. 2.
      Click on Create Default Users
  3. 3.
    Clear your current score.
    1. 1.
      Go to TimeGap Theory > Score
    2. 2.
      Click on the Clear button
Alright, our slate is clear. Let us execute the attack now:
  1. 1.
    Enter the combined fetch requests on the Console tab of browser dev tools
  2. 2.
    Press the Enter key
  3. 3.
    Go to the Network tab of the browser
  4. 4.
    See if you can find an index.php file
  5. 5.
    Right click on it and select open in a new tab
  6. 6.
    You are logged in
  7. 7.
    If you want to see which password was correct, you can check which request showed true in the Console tab
  8. 8.
    Go to TimeGap Theory > Score
  9. 9.
    You should have got 100 points for completing the Login challenge
What is the business impact of such an attack? Depending on how the app is designed, there are several possibilities:
  1. 1.
    A legitimate user may keep getting their account compromised despite changing their passwords
  2. 2.
    Attackers may compromise the admin functionalities of web apps
Let us summarize what we completed:
  1. 1.
    The login page rate limits the login attempts by locking the account
  2. 2.
    You analyzed this behavior by locking out one account
  3. 3.
    You slowed down the system and bypassed the business logic
  4. 4.
    You bypassed the business logic by using browser dev tools
  5. 5.
    Now you know how TOC/TOU security issues can affect login pages
Previous
Challenge 1 – Sign Up
Next
Challenge 3 – Transfer
Last modified 2yr ago