How I was able to Zero Click Account takeover with 3 different ways on the same Reset Password function
السلام عليكم ورحمه الله وبركاته
Hello folks, I hope you are doing well ,
I am Ahmad Asaad a Penetration Tester & Bug bounty hunter (Linkedin)
Introduction
This is my first Writeup, I hope it will be clear enough, I welcome any feedback you may have.
On one of my latest pentest projects I have discovered 3 ways on the same reset password endpoint for 0 Click account takeover, I will try to explain how I found them.
Vulnerabilities
Three ways include: Bypassing Rate Limiting, Response Manipulation and
Mass assignment. Let’s get started !
After some fuzzing on the application, I have discovered an old Endpoint for reset password on the application.
NO Rate Limit on OTP (Brute Force)
With some fuzzing I have found an Old endpoint for reset password,
then I tried to reset my password through this endpoint
FUZZ TIP: Usually I check which programming language does app work with then i go to assetnote lists and start fuzz with it.
I have to choose whether I want to receive the OTP on phone or Email
I Proceed and clicked send, And added any OTP then intercepted the request
Send request to intruder, There’s a rate limiting applied on the endpoint.
I had bypassed the rate limiting by adding X-Forwarded-Host:127.0.0.1
and kept changing the ip in the header every request E.g: 192.168.1.2 ,192.168.1.3, ….
Get the Correct OTP *different response length* then proceed to change the password for any account just by knowing the ID or Email.
MITIGATION
Rate limiting should be implemented on session ID not only relying on IP which could be bypassed by adding header to deceive proxy.
Response Manipulation (Change response body)
While Checking the response of the Wrong OTP entered, I noticed that response body is just number (-10) with no cookies or session is being set or changed in response which means that you can easily manipulate the response
— — — — — — — — — — — — —-Change -10 to 1 — — — — — — — — — — — — — — — —
After changing -10 to 1 You will get redirected to set a new password on Page even the OTP is wrong, Which means there’s an error on the logic of Setting a new password that leads to Account takeover.
MITIGATION
OTP Should be sent to database and generate temp token and resend it with the last request of setting a new password to make sure that the user entered the correct OTP
Mass assignment ( Adding email parameter)
While setting a new password in the last step of resetting password, I fuzzed for parameters and found email parameter
Intercepting the request after adding passowrd in Web Page and add email parameter with encrypted value of any other user email you will be able to change other users passwords then account takeover
But how did I get the encrypted value of Email address?
If you go to login page and enter your email address you will get the encrypted value of it in the request (RSA encryption for email and password) , so you can enter any email address to get it encrypted and then use it in reset password request.
(Also We can look in Javascript files and get the key or the library that generates this value and replicate the same used method BUT That is for another writeup on how I bypassed the mitigation of this)
MITIGATION
OTP Should be sent to database and generate temp token and resend it with this request of setting a new password to make sure that the user is changing his password not other user password
And I was able to takeover any account Just with knowing the email address which could be enumerated on login page due to different error messages (Another Vulnerability but Impact is low, but it could be chained in these cases)
Thanks for reading! I hope you learnt something new ! And that you don’t give up after 1 vulnerability in the same endpoint Or same function
you can contact me through (Twitter | Linkedin)
If you have any questions just drop a message
Again I welcome all feedbacks , If there’s any mistake or any issue in the writeup just lemme know. I appreciate all opinions !
