Account Takeover
Any account takeover attack relies only around users Access/Password related cases. While testing, focus on how the requests are being crafted and how they can be exploited. Especially focus on Response Manipulation while dealing with Account takeovers.
Account takeover is possible in multiple ways. I am discussing the types I've exploited.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Using OTP Misconfiguration:
Here as the name suggests, the application has Forget Password, where users can request for an OTP and create a new password.
Exploitation:
The OTP validation happens in 2 steps.
1. Users request for an OTP where user can give their username(email ID) and request for an OTP.
2. After the user gives the requested OTP, it is validated, and the response redirects to update password page.
3. Here are 2 misconfigurations.
3.1 Appliction is loading the Update Password page based on the response code of the previous OTP validation, implying if i change the response code to 200 OK, i would be able to navigate to Update Password despite giving Invalid OTP.
3.2 Update Password is not validating the OTP, nor has a specific token for user, implying an attacker can send any users emails ID in the request as a parameter and change any users password. Thereby performing a full account takeover.
Recommendation:
OTP related account takeover can be restricted in multiple ways, here are a few:
1. Validate OTP and username in every request including New Password and Confirm New Password requests.
2. Create a session token specific for the validated OTP and username combination so that attackers cannot request for another users password change using their session tokens.
3. And restrict rate limiting attempts to max of 3 to restrict any bruteforce attempts.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Using OTP Misconfiguration:
Here as the name suggests, the application has Forget Password, where users can request for an OTP and create a new password.
Exploitation:
The OTP validation happens in 2 steps.
1. Users request for an OTP where user can give their username(email ID) and request for an OTP.
2. After the user gives the requested OTP, it is validated, and the response redirects to update password page.
3. Here are 2 misconfigurations.
3.1 Appliction is loading the Update Password page based on the response code of the previous OTP validation, implying if i change the response code to 200 OK, i would be able to navigate to Update Password despite giving Invalid OTP.
3.2 Update Password is not validating the OTP, nor has a specific token for user, implying an attacker can send any users emails ID in the request as a parameter and change any users password. Thereby performing a full account takeover.
Recommendation:
OTP related account takeover can be restricted in multiple ways, here are a few:
1. Validate OTP and username in every request including New Password and Confirm New Password requests.
2. Create a session token specific for the validated OTP and username combination so that attackers cannot request for another users password change using their session tokens.
3. And restrict rate limiting attempts to max of 3 to restrict any bruteforce attempts.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Using Misconfigured Concurrent Session:
Here as the name suggests, the application requests users to continue in existing session or login in a new session through concurrent session popup.
Exploitation:
One of the good measures is notifying a concurrent session. But that could also lead to account takeover without the victim's password or MFA or prescence.
1. Login to the application in a browser.
2. Login into the application in another browser, probably incognito.
3. Here when you get concurrent session notification, notice the request parameters going in the burpsuite, as such requests quite often miss validation of users for passwords or MFA.
4. In such a request, ideally, parameters would validate if the existing session is present or not, and if present return specific ID such as the session token or Auth token.
5. One of such request had only the username of the victim and the rest had basic stuff like time stamp last login details etc..
6. Modifying the Username parameter to victim's username, i was able to login to the application and gain access. Notice in such scenarios, we are not requested password or MFA of the victim, as the applications assumes we already have given them.
This leads to full account takeover with victims still having their access, unbeknownst to the attacker.
Recommendation:
Validate new and concurrent sessions with existing tokens and references before allowing users to the application.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Here as the name suggests, the application requests users to continue in existing session or login in a new session through concurrent session popup.
Exploitation:
One of the good measures is notifying a concurrent session. But that could also lead to account takeover without the victim's password or MFA or prescence.
1. Login to the application in a browser.
2. Login into the application in another browser, probably incognito.
3. Here when you get concurrent session notification, notice the request parameters going in the burpsuite, as such requests quite often miss validation of users for passwords or MFA.
4. In such a request, ideally, parameters would validate if the existing session is present or not, and if present return specific ID such as the session token or Auth token.
5. One of such request had only the username of the victim and the rest had basic stuff like time stamp last login details etc..
6. Modifying the Username parameter to victim's username, i was able to login to the application and gain access. Notice in such scenarios, we are not requested password or MFA of the victim, as the applications assumes we already have given them.
This leads to full account takeover with victims still having their access, unbeknownst to the attacker.
Recommendation:
Validate new and concurrent sessions with existing tokens and references before allowing users to the application.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Using misconfigured Change Password:
Here as the name suggests, the application requests users to continue in existing session or login in a new session through concurrent session popup.
Exploitation:
Such exploitations require least privilege atleast to be able to exploit.
1. Login and navigate to Change Password.
2. Capture the request of a successful change password. If the request is not validating old password, application might be vulnerable to Accoun Takeover.
3. Now, validate if there are any tokens passed and if they are being validated.
4. If not, an attacker from outside the application can exploit this vulnerability to perform account takeover.
5. In the application i tested, it wasnt validating both old password and session token, leading an attacker to perform change password without knowing the current password of the victim.
Recommendation:
Validate the previous(current) password and the Session token(also if its valid to perform the requested user as an additional measure) while performing or requesting a new password via Change Password.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Here as the name suggests, the application requests users to continue in existing session or login in a new session through concurrent session popup.
Exploitation:
Such exploitations require least privilege atleast to be able to exploit.
1. Login and navigate to Change Password.
2. Capture the request of a successful change password. If the request is not validating old password, application might be vulnerable to Accoun Takeover.
3. Now, validate if there are any tokens passed and if they are being validated.
4. If not, an attacker from outside the application can exploit this vulnerability to perform account takeover.
5. In the application i tested, it wasnt validating both old password and session token, leading an attacker to perform change password without knowing the current password of the victim.
Recommendation:
Validate the previous(current) password and the Session token(also if its valid to perform the requested user as an additional measure) while performing or requesting a new password via Change Password.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Using misconfigured Register:
Applications allow users to register, and most of the applications do not validate the existing registration after initial checks. And that is what we are going to exploit here.
Exploitation:
Application requests for a username during registration. And if the username is already registered, application responds the same. But manipulating response code to a response code of that of a unregistered account, allows attacker to move forward with the registration.
Now, since there are no further checks, attacker can register with same username and email ID and thereby change password of the victim user's account mimicking the fresh installation.
This can lead to full account takeover of the victim's account.
Recommendation:
Validate user existence across every step of registration. And dont fall for response manipulation i.e., do not pull data from responses of the previous requests.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Applications allow users to register, and most of the applications do not validate the existing registration after initial checks. And that is what we are going to exploit here.
Exploitation:
Application requests for a username during registration. And if the username is already registered, application responds the same. But manipulating response code to a response code of that of a unregistered account, allows attacker to move forward with the registration.
Now, since there are no further checks, attacker can register with same username and email ID and thereby change password of the victim user's account mimicking the fresh installation.
This can lead to full account takeover of the victim's account.
Recommendation:
Validate user existence across every step of registration. And dont fall for response manipulation i.e., do not pull data from responses of the previous requests.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Default Password:
Applications registers users with default passwords and does not request a mandatory password change on first login.
Exploitation:
I dont think an explanation is required here, just login with default password.
Recommendation:
Implement a mandtory password change on first login.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Applications registers users with default passwords and does not request a mandatory password change on first login.
Exploitation:
I dont think an explanation is required here, just login with default password.
Recommendation:
Implement a mandtory password change on first login.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bypassing Password Login over MFA:
In a few applications where MFA is enabled, response manipulation of invalid login can lead to successful MFA trigger and validation. This is possible if we have access to MFA code, but this lands as a vulnerability as the application users for whom MFA is not present, there is no additional security measure, attackers can exploit this vulnerability to perform an Account takeover.
Recommendation:
Do not fall for response manipulation and always validate every request based on input parameters, not response details.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In a few applications where MFA is enabled, response manipulation of invalid login can lead to successful MFA trigger and validation. This is possible if we have access to MFA code, but this lands as a vulnerability as the application users for whom MFA is not present, there is no additional security measure, attackers can exploit this vulnerability to perform an Account takeover.
Recommendation:
Do not fall for response manipulation and always validate every request based on input parameters, not response details.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bypassing OTP with injection:
In a few applications where MFA is enabled, OTP is sent to a phone number.
Exploitation:
Injecting attackers phone number such as smsphonenumber=<victim-phone> to smsphonenumber=<victim-phone>,<attacker-phone> gave me OTP of the victim on my phone as well as victims device. This allows me to use the OTP as the MFA token to change password in forget password.
Recommendation:
1. Do not send OTP to multiple numbers at same time
2. Validate all the requests before sending OTP to a phone number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In a few applications where MFA is enabled, OTP is sent to a phone number.
Exploitation:
Injecting attackers phone number such as smsphonenumber=<victim-phone> to smsphonenumber=<victim-phone>,<attacker-phone> gave me OTP of the victim on my phone as well as victims device. This allows me to use the OTP as the MFA token to change password in forget password.
Recommendation:
1. Do not send OTP to multiple numbers at same time
2. Validate all the requests before sending OTP to a phone number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++