Reset Link Doesn't Expire if i Changed email To Another email

NEW
Unassigned

Status

support.mozilla.org
General
P3
normal
2 years ago
7 months ago

People

(Reporter: Abdel Hafid Ait Chikh, Unassigned)

Tracking

({sec-low, wsec-authentication})

unspecified
sec-low, wsec-authentication
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

Steps to reproduce:

Hello Team

i've Found a Vulnerability At support.mozilla.org it's That The Reset Link Doesn't Expire if i Changed email To Another email

Steps :

1- i Will Send a Reset Password To Account email test@test.com To Keep it :)
2- i Will Change email To attack@attack.com
3- i Will Receive a Confirmation Link and i Will Confirm it

In this case the reset link password have to expire But Now it's Still Working

4- i Will Click On The Reset email That i Sent Before to test@test.com and i Can Change Password :)


Actual results:

Reset Link Doesn't Expire if i Changed email To Another email.


Expected results:

it Have To Expire When i Changed email to Another One.
Abdel - thanks for the report, I'm looking into this now.
Test #1 - Baseline test (Do password resets expire? Yes)

1.) asked for password reset on foo@domain.com
2.) received link in email
3.) clicked link and reset password
4.) revisited link (Got this: "The password reset link was invalid, possibly because it has already been used. Please request a new password reset.")

Test #2 - Suggested Test (Abdel's PoC - Do password resets expire during email change? Yes)

1.) asked for password reset on foo@domain.com
2.) received pass reset link in email at foo@domain.com (did not click link)
3.) changed email on account to another email address bar@domain.com
4.) received confirmation link in email (clicked link)
5.) visited password old reset link from foo@domain.com (Got this: "The password reset link was invalid, possibly because it has already been used. Please request a new password reset.")
Abdel - I was unable to reproduce your PoC.  It's possible that I misinterpreted your replication instructions, can you please provide more clarification and help me reproduce the issue?
(Reporter)

Comment 4

2 years ago
Hello Jonathan

This is it

Test #2 - Suggested Test (Abdel's PoC - Do password resets expire during email change? No)

1.) asked for password reset on foo@domain.com
2.) received pass reset link in email at foo@domain.com (did not click link)
3.) changed email on account to another email address bar@domain.com
4.) received confirmation link in email (clicked link)
5.) visited password old reset link from foo@domain.com (Got this: "Password Reset :" ) And To Type New Password :) in This Case i Can Change Password
:
Abdel - Since we seem to agree on the replication process, but not the end result I'm going to ask someone else on my team to double check this just to make sure.

:adamm - Can you please offer up a second opinion on the result of Test case #2 above?  When I test I get an invalid password reset link, but when Abdel tests he's getting a valid password reset.
Flags: needinfo?(amuntner)
(Reporter)

Comment 6

2 years ago
Hello Jonathan 

You Will Found Anything in This Video : https://youtu.be/Ishm61t0P2U
Confirmed behavior, with serious limitations that limit the effectiveness of this as an attack to a very specific and limited set of conditions. 

The attacker MUST have access to the mailspool of email #1
The mailspool for email #1 MUST contain an unexpired password reset link
The user MUST have moved their Sumo account to a different email address

Attack:
1. Victim reset their password, resulting in a password reset email in their mailbox for email address #1.
2. Victim remembers their password later, uses it to login, never using the link in the reset email. 
3. Victim changes their email address #1 to email address #2. SUMO sends confirmation to email address #2. 
4. User accepts account control, clicks email change confirmation link.
5. Attacker gains access to email address #1, clicks unexpired password reset link, logs into account.
6. Attacker changes the email address again, to one under their own control, locking the user out of their account, unless they have an expired password reset of their own, in which case they can use it to take their account back. 

This can not be used to attack an arbitrary account. When trying to use this to attack an existing account (ie bar@domain.com), SUMO complains that the account already exists. 
It is only possible to change address to one that is not already a user. When adding an email address that doesn't already have a SUMO account, SUMO assumes it's under the user's own control and sends a confirmation email. If it wasn't, the "victim" would be able to take over the attacker's account after accepting the link. 

I tested using the same concept to try to attack email address change confirmations that haven't been accepted, where the attack scenario would be someone typing the wrong email address to change to by accident, then resetting it to one under their control. After the user sends another, the first is expired. 

 Given the unlikely combination of two requirements for this to be an effective attack, it's rank SEC-LOW, not SEC-MODERATE.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(amuntner)
Keywords: sec-low
Keywords: wsec-authentication
Group: websites-security
Thanks for submitting the bug Abdel. If we missed something and there's another attack scenario, you're welcome to comment again and flag me from needinfo from dialog below to make sure I see it.
(Reporter)

Comment 9

2 years ago
So There is No Reward For This :/
(Reporter)

Comment 10

2 years ago
Don't Make This Case Public :)
(Reporter)

Updated

2 years ago
Group: websites-security
I see no reason to keep this private. Unhiding.
Group: websites-security
Flags: sec-bounty?
As a "low" rated security issue, this does not qualify for a bug bounty. I am minusing it as a result.
Flags: sec-bounty? → sec-bounty-

Updated

7 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.