Registration logic error — 2500$ bug bounty

So let’s ask a question : what happens if I try to register with an already registered user?

✅Step 1 — I create a user with the process described before.

❌Step 2 — Now, I do not pre-register again, but I try to send REQ1 to obtain a user_token because it is required for REQ2.

What happens is : nothing! REQ1 no longer returns the user_token we need for REQ2. This gives the following scheme.

At this points I tried to look for user_token string in Burp to see if I could retrieve it elsewhere, and the answer is yes! There was another request, let say REQX, that allowed me to get the user_token. So let’s start again!

✅Step 1 — I create a user with the process described before.

✅Step 2 — I use the new request REQX I found to obtain a user_token.

✅Step 3 — I send REQ2 with the user_token and it works! I can complete the OTP… This is useless.

Let’s start over with a slight difference : remember REQ2 normal behavior? We can change the email address for OTP. Let’s try it!

✅Step 1 — I create a user with the process described before.

✅Step 2 — I use the new request REQX I found to obtain a user_token.

✅Step 3 — I send REQ2 with the user_token and I provide another email address than mine!

⚠️Step 4 — Unexpected consequence : it updated my contact email address in the application! I can still log in with my original email address, but all communication is done with the new email I specified.

Answer to our question : what happens if I try to register with an already registered user? Well, the email address gets updated, even if I didn’t login!

So this is our updated scheme.

Ok, we didn’t hack anything yet since all testing was realized with my own account! How an attacker could exploit this? Let’s make some assumptions :

🥷Assumption 1 — The attacker knows its victim personal information. That actually very likely to happen, because of data leaks that sometimes contains millions of records.

🥷Assumption 2 — The attacker needs a user_token.

🥷Assumption 3 — The user_token could be obtained with REQ1 thanks to the user_id. But the request doesn’t work for an already registered user, and the attacker has no way to retrieve the user_id.

Well, I hid something from you… This is all about REQX : the other request I found the retrieve the user_token. The input needed by this request is only personal information… Here are the scheme and the steps.

✅Step 1 — The attacker gets its victim personal information.

✅Step 2 — The attacker sends REQX to get a user_token.

✅Step 3 — The attacker sends REQ2 with the user_token and provides their own email address!

✅Step 4 — The attacker triggers a password reset! (not shown on the scheme)