Notes:

To brute-force a login page, you should pay particular attention to any differences in

• Status Codes

• Error Messages

• Response times

• Password Based Login

  • To shorten the attack time, try enumerating one field at a time. For example, start with the username field and look at the response length. It's possible that separate responses have been given for the username and password fields. If successful with the username, move on to enumerating the password field. This is better than brute-forcing both fields simultaneously.

  • After logging in from the attacker's account, take note of the URL. Logout and attempt to login with victim credentials. When asked for a verification code, manually navigate to the previously noted URL.

  • get a reset password link using the attacker’s email. the request body consists of username field. change the username field to victim’s username and delete the value of the temp-forgot-password-token from URL and body and send the request.

  • Username enumeration via subtly different responses - run Intruder on the username field, select "options," add "grep extract," and then highlight the statements in the response that contain the error message.

    • OR just clusterbomb both the username and password field and sort the response code
    • grep search for the exact error message it says when incorrect login, there’s a subtle change even for the right username, it will be noticed, now bruteforce passwords on that username, sort by response code.

    to learn is that, even if we put the wrong username and password, some code flaw could be reflected. show some error message when both the fields are correct, when only one field is correct and when neither of them are correct. through this kinda, we can enumerate and find the correct one.

  • Username Enumeration via response timing -

    1. The target uses IP based protection, therefore simultaneously spoof X-Forwarded-For header and username to bypass this.
    2. To differentiate valid usernames, use a long password (~100 characters). For valid usernames, the response time will be significantly longer due to increased processing time.
    3. Enumerate over a list of potential usernames and monitor response times. The valid username will cause a longer response time.
    4. Once the valid username is identified, start enumerating passwords while continually spoofing the X-Forwarded-For header.
    5. The correct password will result in a HTTP 302 response

    Note: This approach first enumerates usernames and then passwords for efficiency, although a brute-force on both can also be performed using a single cluster bomb attack.

    to learn is that even if we found the right username, and the password is something else and too long it. there could be a code flaw that would highlight that, “something is right, but not all of the things, so in checking that, it took time” - from this kind of thing, the username can be enumerated and we can find the correct one.

• Flawed Brute Force Protection

  • If IP is getting blocked after too many login attempts, then there could be an implementation where the counter resets after a number of failed attempts. If that is the case then.
    • A pitchfork attack using Burp Intruder. The attack alternated between the user's own valid credentials and Victim's account username, effectively resetting the failed attempt counter. This circumvented the IP block and identified Victim's password, granting access to his account.
    • what we did was, pitchfork attack. payload 1 as username and payload 2 as password. payload 2 was a list of passwords, we inserted our right creds in it, after every alternate word. this doubled the payload 2. using the total count of payload 2, we make the payload 1 of same count, alternating between our valid username and victims’s username.
  • The main thing there here is that, when we are sending requests. we make sure that the maxiumum requests is set as 1 in the Resource pool, that makes sure that one requests gets sent at one time so that when we are rotating between the right creds and trying to bruteforce the password, the requests gets sent in proper order

• Broken Brute Force Protection, multiple credentials per request

  • A flaw in user rate limiting for brute force protection, system rate limits based on the HTTP requests sent from the user's IP, but it is possible to bypass this defense by sending multiple passwords in a single request

    • In Repeater, modify the single string value of the password into an array of strings, each string being a candidate password. ["username" : "carlos", "password" : [ "123456", "password", "qwerty", ... ]. If Response is 302 then open the response in Browser.
    • To find the correct password from an array, send half the array in a request. If you get a successful login, the correct password is in this half. If not, it's in the other half. Continue halving the successful subset until you isolate the correct password. This process is similar to a binary search operation

  • what to learn here is that passwords fields any input field can accept input as multiple values, so look for that. eg "password":["lala","123456","password","qwerty",…]

    and as for the lab, brute-force protection can be bypassed if an application accepts multiple credentials per request, allowing an attacker to test several passwords at once and avoid rate limiting.

• Username enumeration via account lock

  • login with wrong creds, proxy with Burp. Intruder>Cluster Bomb Attack Type, payload as the username and the password value fields. payload for username as the list of usernames and for the password as null payloads, generate 5 payloads. this will try to send the same username 5 times so that when the same username is used more than 3 times, account gets locked. this will help in username enumeration.
  • The main thing here is that if accounts gets locked out, or has a policy of locking out user when too many wrong attempts, we can still try to enumerate the usernames. HOW?
    • authentication issues can have account logout when right username is used with wrong password multiple times. with this kind of flaw we can still enumerate usernames and this can lead to issues and once the right username is found we can bruteforce the password.
    • Account lock mechanisms with logic flaws can reveal valid usernames through differing error messages, allowing for successful username enumeration and password brute-forcing.

• HTTP Basic Authentication

  • if stumbled upon a page that has only HTTP basic authentication, it typically uses a auth token from the server like this base64(username:password) and passes in each request like this Authorization: Basic base64(username:password) its not a secure way, unless the website also has HSTS applied, or else its open to MITM basic auth also doesnt provide support to brute force protection, session related exploits like CSRF