Password reset key leaked via HTTP "Referer" field

Bug #1333096 reported by Aaron Wells on 2014-06-23
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
Low
Robert Lyon
1.10
Low
Robert Lyon
1.8
Low
Robert Lyon
1.9
Low
Robert Lyon
15.04
Low
Robert Lyon

Bug Description

If a site has resources on external domains, and a user clicks the link in a "forgot password" email, then the key to reset their password gets sent to those external domains via the "Referer" field of the HTTP request. External resources could be from the Persona plugin (which loads up a javascript file from the main Persona server), from the $CFG->additionalhtml field including a Piwik or Google tracking cookie, or other sources.

To replicate:

1. Turn on the Persona authentication plugin

2. Log out of Mahara

3. Click the "Lost username / password" link

4. You'll receive a password reset email. It will contain a link like this: "https://mahara.example.com/forgotpass.php?key=3wKYEeGdBI2J5jSc"

5. In your web browser, turn on a tool that lets you view HTTP requests and their headers.

6. Load the password reset link

Result: You'll see the "key" param of forgotpass.php being sent to the persona.org servers:

Host=login.persona.org
User-Agent=Mozilla/5.0 (Windows NT 6.3; rv:30.0) Gecko/20100101 Firefox/30.0
Accept=*/*
Accept-Language=en-US,en;q=0.5
Accept-Encoding=gzip, deflate
Referer=https://mahara.example.com/forgotpass.php?key=3wKYEeGdBI2J5jSc
Connection=keep-alive

The password reset process happens takes two page loads. The first page load displays the "new password" form to the user, and the second page load actually changes their password and expires the key.

So that means this is actually abuseable. An attacker who had a resource that gets included in each page load could, in theory, listen for that key in the referer field, and then quickly use it to reset the password themselves.

Low priority because this attack requires the attacker to have compromised the system already. And there's only a slim window of opportunity. They have to use the key after the new password screen is loaded, but before the user fills it out and submits it.

CVE References

Aaron Wells (u-aaronw) wrote :

I believe the best fix for this would be to remove the "key" from the URL before we render any page to the user. Like this:

1. User goes to https://mahara.example.com/forgotpass.php?key=3wKYEeGdBI2J5jSc

2. forgotpass.php reads the "key" param from the URL, stores it in the session, then redirects to https://mahara.example.com/forgotpass.php

3. We proceed from there pretty much as normal.

Aaron Wells (u-aaronw) on 2014-10-21
no longer affects: mahara/1.7
Robert Lyon (robertl-9) wrote :

Have added a patch for this: https://reviews.mahara.org/#/c/3804/

Robert Lyon (robertl-9) on 2014-11-25
information type: Private Security → Public Security
Robert Lyon (robertl-9) on 2015-04-17
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers