Daemon Of Hacking
  • WELCOME!
    • 👋/home/usr/KruKnight
  • METHODOLOGIES & RESOURCES
    • Passwords & Attacks
    • Post Exploitation
      • 👀Situational Awareness
      • 🖥️Privilege Escalation
        • Linux Privilege Escalation
        • Windows Privilege Escalation
  • Writeups
    • CyCtf 2024
      • Vending Machine
      • Aerospace
      • OhMyCell
    • Portswigger Labs
      • Authentication
        • Username enumeration via different responses
        • 2FA simple bypass
        • Password reset broken logic
        • Username enumeration via subtly different responses
        • Username enumeration via response timing
        • Broken Brute-Force Protection, IP Block
        • Username enumeration via account lock
        • 2FA broken logic
        • Brute-forcing a stay-logged-in cookie
        • Offline password cracking
        • Password reset poisoning via middleware
        • Password brute-force via password change
        • Broken brute-force protection, multiple credentials per request
      • Os Command Injection
        • OS command injection, simple case
        • Blind OS command injection with time delays
        • Blind OS command injection with output redirection
        • Blind OS command injection with out-of-band interaction
        • Blind OS command injection with out-of-band data exfiltration
      • Cross-Origin Resource Sharing (CORS)
        • CORS vulnerability with basic origin reflection
        • CORS vulnerability with trusted null origin
        • CORS vulnerability with trusted insecure protocols
      • Server-side template injection
        • Basic server-side template injection
        • Basic server-side template injection (code context)
      • Server-Side Request Forgery (SSRF)
        • Basic SSRF against the local server
        • Basic SSRF against another back-end
        • Blind SSRF with out-of-band detection
        • SSRF with blacklist-based input filter
        • SSRF with filter bypass via open redirection vulnerability
      • Path Traversal
  • 🟩HTB Writeups
    • Heal
Powered by GitBook
On this page
  • Lab Description
  • Walkthrough
  • Step 1: Understanding the Logic Flaw
  • Step 2: Testing with Null Payloads To test this:
  • Step 3: Observing Results After 50 repeated requests:
  • Step 4: Enumerating Usernames To identify valid usernames:
  • Step 5: Analyzing Results
  • Step 6: Brute-Forcing the Password With the valid username identified:
  • Step 7: Observing Response Anomalies While brute-forcing:
  • Step 8: Accessing the Account

Was this helpful?

  1. Writeups
  2. Portswigger Labs
  3. Authentication

Username enumeration via account lock

PreviousBroken Brute-Force Protection, IP BlockNext2FA broken logic

Last updated 5 months ago

Was this helpful?

Lab Description

Walkthrough

Step 1: Understanding the Logic Flaw

The lab description mentions a logic flaw in account locking. Upon initial testing:

  1. Using a wrong username results in the error: "Invalid username or password."

  2. After repeated attempts with an invalid username, the account does not get locked, suggesting account lockouts apply only to valid usernames.

This is an indication that we can use account lockouts as a mechanism to enumerate valid usernames.

The account lockout mechanism is usually triggered after multiple failed login attempts. However, we hypothesized that this logic might only apply to valid usernames and not invalid ones.

Step 2: Testing with Null Payloads To test this:

  1. Burp Suite Intruder Configuration:

    • Payload Set: Used the Null Payload option, which generates a specific number of empty payloads (in this case, 50).

    • This allowed us to send 50 login attempts with the same invalid username.

  2. Invalid Username Input:

    • We used an arbitrary (allegedly invalid) username and any random password.

    • The payload repeatedly sent requests with this invalid username.

Step 3: Observing Results After 50 repeated requests:

  • The error message remained the same: "Invalid username or password."

  • Importantly, no lockout message was displayed, and the system did not mention being locked out due to too many attempts.

Step 4: Enumerating Usernames To identify valid usernames:

  1. Configure Burp Suite Intruder.

    • Payload Set 1: Load the Candidate Usernames list.

    • Payload Set 2: Use Null Payloads (repeating each username multiple times).

  2. Use the Cluster Bomb attack type to test each username 10 times with an invalid password.

Why repeat attempts?

  • A valid username will trigger an account lockout after multiple failed login attempts.

  • Invalid usernames will not trigger any lockout, and the response will stay consistent.

This will make burp send each username 10 times with the wrong password to trigger the lockout

Step 5: Analyzing Results

  1. Use Burp Suite's Grep - Extract feature to highlight responses.

    • Filter for differences in the error message or response length.

  1. A valid username will display an account lockout message instead of "Invalid username or password.

Step 6: Brute-Forcing the Password With the valid username identified:

  1. Modify the Intruder attack to focus on brute-forcing the password.

    • Use Payload Set 1: Fixed username (valid).

    • Use Payload Set 2: Candidate passwords.

Step 7: Observing Response Anomalies While brute-forcing:

  • Notice a response length differs slightly, inspect the request.

  • A shorter response or the absence of an error message often indicates a successful login.

Step 8: Accessing the Account

Using the identified password, log in with the valid username and confirm access to the account page.