619276 - Unique PERSONA_USER cookie per user on getpersonas.com

Status: RESOLVED FIXED

(Websites Graveyard :: getpersonas.com, defect)

Description

[pwn.star.wannabe]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Build Identifier: 

getpersonas.com websites uses 3 different cookies WT_FPC, wtspl and PERSONA_USER. 

However PERSONA_USER cookie is used for authentication of the user. This cookie is not random and every time a user logs on on the websites he has the same cookie. Moreover the cookie has username information in it : <login>+<MD5_salted_between_login_and_password>.

Doing few tests, i am sure that this cookie is a MD5 with user name and password parameter. 

It is insecure to NOT use a random cooke per user's session. Indeed,if a malicious user steals a user's cookie via a XSS attack, he will be able to log in with his account until he changes his password.

An attacker could also bruteforce an accounts cookie requesting the /profile page without entering any CAPTCHA.

I recommend using PHPSESSIONIDs.


Reproducible: Always

Steps to Reproduce:
1.Log in various times and look at PERSONA_USER cookie.
Actual Results:  
PERSONA_USER cookie is always the same for a user with a password.


This vulnerability increase Reflected/Stored XSS vulnerabilities. Indeed, it makes cookie like password of the user.

Comment 1

[pwn.star.wannabe]

I apologize to have forgotten ticking the security box. I don't see how change it.

Comment 2

[Fred Wenzel [:wenzel]]

I am looking at this one.

Comment 3

[Fred Wenzel [:wenzel]]

Attachment: Patch

This patch should solve the problem as described by the bug reporter. Instead of hashing the password (including salt, by the way) and dropping it as a static value into the PERSONAS_USER cookie, I am only storing the username in that cookie now. It is only used to show "hello, clouserw" in the header.

The actual session handling is taken over by PHP and appropriately started on login and destroyed on logout.

Comment 4

[Wil Clouser [:clouserw]]

Comment on attachment 498480 [details] [diff] [review]
Patch

Thanks wenzel.  -> telliott for review

Comment 5

[Toby Elliott [:telliott]]

Comment on attachment 498480 [details] [diff] [review]
Patch

I can't run it anywhere, but the theory here looks fine.

Comment 6

[Jeff Balogh (:jbalogh)]

The patch doesn't apply for me, so maybe I'm missing some details, but doesn't it allow me to login as whoever I want by switching my cookie to contain their username?

The authenticate_user_from_cookie function was relying on the token as a weak "server secret" to prevent cookie tampering.

I don't know how PHP sessions work, so maybe that's not an issue?

Comment 7

[Fred Wenzel [:wenzel]]

(In reply to comment #6)
> I don't know how PHP sessions work, so maybe that's not an issue?

http://www.php.net/manual/en/function.session-start.php

Comment 8

[Fred Wenzel [:wenzel]]

Landed on trunk: r79666

How do we deploy this?

Comment 9

[Wil Clouser [:clouserw]]

We should verify it does what it says on http://personas.stage.mozilla.com/en-US/ and then file an IT bug to svn up personas I guess.

Comment 10

[Fred Wenzel [:wenzel]]

jbalogh: Once stage updates, please try breaking it.

Comment 12

[pwn.star.wannabe]

The patch seems to work well. However, i recommend to regenerate the PHP session id, each time a user logs in.

Try to add session_regenerate_id(); just after calling the session_start(); function.

Comment 13

[Fred Wenzel [:wenzel]]

Will do, thanks!

Comment 14

[Fred Wenzel [:wenzel]]

Oh, this looks like I forgot to close the bug. The fix is live since last week.