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: Exploring the Password Change Functionality
  • Step 3: Setting Up the Brute-Force Attack
  • Step 4: Analyzing Results
  • Step 5: Verification

Was this helpful?

  1. Writeups
  2. Portswigger Labs
  3. Authentication

Password brute-force via password change

PreviousPassword reset poisoning via middlewareNextBroken brute-force protection, multiple credentials per request

Last updated 5 months ago

Was this helpful?

Lab Description

Walkthrough

Step 1: Exploring the Password Change Functionality

After logging in with the provided credentials (wiener:peter), the first step is to explore the application's behavior. I navigate to the Change Password section under My Account.

  • I observe that the form includes fields for the current password, new password, and confirmation of the new password.

Step 2: Testing Validation

To understand how the application handles input errors, I perform a series of tests:

  1. Mismatched New Passwords

    • Enter a correct current password but intentionally input mismatched new passwords.

    • Result: The application throws an error: "New passwords do not match."

  1. Incorrect Current Password

  • Enter an incorrect current password while inputting valid new passwords.

  • Result: The application throws an error: "Current password is incorrect."

From these tests, I notice two distinct behaviors:

  • When the current password is valid but the new passwords mismatch, the error is about mismatched new passwords.

  • When the current password is invalid, the error explicitly says it is incorrect.

This differentiation can be exploited in a brute-force attack:

  • We attempt various passwords as the current password while using intentionally mismatched new passwords.

  • A response indicating mismatched new passwords implies the current password was correct.

Step 3: Setting Up the Brute-Force Attack

To brute-force the current password, I:

  1. Send a sample password change request to Burp Suite.

  2. Replace the username field with carlos to target their account.

  3. Mark the current password as a payload position for the attack.

  4. Use two mismatched new passwords to generate a distinguishable response.

Step 4: Analyzing Results

  • After the attack completes, filter the responses by content length.

  • Identify the response with a differant length

  • The associated payload reveals the correct current password for Carlos's account.

Step 5: Verification

Using the retrieved password (qwerty), I log in to Carlos's account and confirm access to the My Account page.