Closed Bug 625230 Opened 14 years ago Closed 13 years ago

Attacker Can Prevent Access to Email Account

Categories

(Cloud Services :: Server: Registration, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mcoates, Assigned: tarek)

References

Details

(Whiteboard: [infrasec:auth][ws:moderate][MOZ2-4])

Attachments

(2 files)

Summary:

An attacker can create a new account where the username (now represented as an email address) is different than the email address that is registered for the account.  The impact of this is that an attacker could target an email address, which the attacker does not own and the true owner has not yet registered for sync, and prevent this account from ever registering as a sync account.  Further, any password reset attempts against this account would be sent to the attacker's email address and not the victim's email account.

Simplified Example:
- Attacker begins registration with account badguy@site.com
- Attacker targets victim account user@somesite.com. This account does not have a sync account
- Attacker exploits weakness and creates account with username user@somesite.com and associated email address badguy@site.com
- Victim is now unable to ever create a sync account using user@somesite.com or gain access via password reset process

Impact:
This vulnerability allows an attacker to prevent a targeted user from creating a valid account with a particular email address. The initial review of InfraSec places the overall risk as MODERATE.  This issue does not put any user data at risk and only users that are specifically targeted by the attacker would be impacted.  The worst case scenario is an attacker creates a script and performs this attack against large numbers of users. However, this attack would still be throttled by the CAPTCHA controls.


Steps to Reproduce:

1. Set up Fiddler (http://www.fiddlertool.com) for debugging the HTTP traffic and configure
it so that it will intercept network communication between Firefox (i.e., Sync client) and
the Sync server.
2. Launch Firefox and make sure that no Sync account is configured (use the "Stop using
this account" option if one is configured).
3. Under the "Sync" tab in Firefox "Options" dialog, click "Set Up Firefox Sync".
4. When asked whether you want to create a new account or connect to an existing one,
click "Create a new account".
5. In the "Account Details" dialog, provide someone else's e-mail address that hasn't been
registered yet on the server, and any password. Click "Next".
6. In the following dialog save the sync key and click "Next".
7. In Fiddler, set automatic breakpoints before requests (press F11).
8. In Firefox's Sync setup captcha dialog, type the captcha words and click "Next".
9. In Fiddler, wait for the "PUT" request from Firefox to the Sync server. In the inspector
window, see that the request's body contains a number of argument:value pairs,
including the password and e-mail you provided.
10. Change the email argument in the request's body to one of your e-mail addresses.
11. Disable Fiddler's automatic breakpoints (press Shift+F11).
12. Pass the captured request on to the server (click the "Run to Completion" button in
Fiddler).
13. Inspect the Sync server database and see that the newly created Sync user with
another person's e-mail address as account name has your e-mail address registered.


Vulnerable HTTP Request

PUT /user/1.0/aubgqh5ukjteeipeat3mjuspaf6e4aoi HTTP/1.1
Host: auth.services.mozilla.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: text/plain
Cookie: s_vsn_mozillaservicesmozcom_1=1507506673893; WT_FPC=id=25d985ec6c1e69c66e31291249917773:lv=1294466953351:ss=1294466240364; SSID=AwAmjikAAAgASen3TPhuDAFJ6fdMAwAAAAAAAAAAAAAAAAAklPlMAAAM_v__AAAAAABFAAAARAAAAA; SSRT=JJT5TAE; wtspl=305478; __utma=183859642.1782987208.1294430365.1294430365.1294430365.1; __utmz=183859642.1294430365.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
X-Behavioral-Ad-Opt-Out: 1
X-Do-Not-Track: 1
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 287

{"password":"PasswordTesting123","email":"ChangedToVictimEmail@somesite.com","captcha-challenge":"03AHJ_Vuubh9X-hmUzX8K1_uAQZ-j8KdhB7OMsfxB19uXq13sxdMNCqZyZMG1R98-46nFqESPdcR_FrB8OCG2EgQFJIH-lZOO4o-ArK8osYhoPhXYhivTTuslq6UkDvYKPrjbt3PSvLT1kVhjRIrGjFwPXkA_hgVyszg","captcha-response":"54r, Thiben"}


Recommended Remediation:

It appears the root cause of this issue is that the username, accepted during the first steps of account creation, and the email address from the PUT request are not verified to be the same value during account creation.
Whiteboard: [infrasec:auth][ws:moderate] → [infrasec:auth][ws:moderate][MOZ2-4]
Yes, the auth server should verify that username == sha1(base32(email))
We should make that optional in the current auth server (turned on for us) and add a new error code.  We should also specify this in 1.1 of the User API.

At worst this is a mild dos, that can't target existing users, and can be trivially worked around by a user with a bit of knowledge, but let's fix it.
Assignee: nobody → telliott
Mike: Will this be implemented in Python auth only, or also PHP?
We should do it for both, since we don't yet have a timeline on migration of reg to Python.
This is not done yet on any version. Since we've moved AP this week to Python, I am going to take this bug and do the change. I'll introduce a new error code.

I can't see bug 618091 btw, so I am not sure what this blocks.
Assignee: telliott → tarek
Status: NEW → ASSIGNED
This patch controls that the e-mail provided at registration time is corresponding to the base32 email used for the user id.

This control can be deactivated with a new option in the [auth] section, but is activated by default.
Attachment #534402 - Flags: review?(telliott)
Adds a new error code
Attachment #534403 - Flags: review?(telliott)
Comment on attachment 534402 [details] [diff] [review]
Controls the email field on user registration

As long as we keep this restriction to only the creation, we should do this. Looks good.
Attachment #534402 - Flags: review?(telliott) → review+
Note that it is still possible to change your email through the api. Since we don't yet support change-email-changes-username, this will remain a problem.
Attachment #534403 - Flags: review?(telliott) → review+
The last link was a wrong one. here's the right one:
https://hg.mozilla.org/services/server-reg/rev/98936fcd7df7
Blocks: 654148
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Note, that I didn't test the API workflow mentioned by Toby in comment #9
Group: mozilla-corporation-confidential
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: