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 email@example.com To Keep it :) 2- i Will Change email To firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org 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 email@example.com 2.) received pass reset link in email at firstname.lastname@example.org (did not click link) 3.) changed email on account to another email address email@example.com 4.) received confirmation link in email (clicked link) 5.) visited password old reset link from firstname.lastname@example.org (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?
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 email@example.com 2.) received pass reset link in email at firstname.lastname@example.org (did not click link) 3.) changed email on account to another email address email@example.com 4.) received confirmation link in email (clicked link) 5.) visited password old reset link from firstname.lastname@example.org (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.
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 email@example.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
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.
So There is No Reward For This :/
Don't Make This Case Public :)
I see no reason to keep this private. Unhiding.
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-
You need to log in before you can comment on or make changes to this bug.