Old Cookies Die Hard

HTTP Cookies have always been an important part of authentication, and session management. But, ever since the session management grew complex, its correlation with security has gone for a toss. Developers pay a lot of attention on keeping the session(s) valid, and more so valid even after a successful logout. Now, this accounts to a session management vulnerability. I understand that the delivery of the cookies, or the session variables have been locked with an HTTPS channel, but to me it is a compensatory control. It is NOT A FIX for a session management vulnerability. I have been talking about it in the past with an example of LinkedIn vulnerability. It made it to the news but still everything has not been taken care of.

Okay, now what is the problem with cookies and session management? Fine, here is the problem statement –

Cookie Expiry and Session Management

It means that the cookie/session ID for an authenticated session is available even after the session has been terminated. There are examples where cookies can be accessible to hijack authenticated sessions. And these cookies are days (sometimes months) old. As a result, someone can successfully access accounts that belong to individuals from different global locations. Even if they would have logged-in/logged out many a times, theirs cookie would still be valid.

Though the cookie expiry date is mentioned still the cookies are valid post log-out. Why do the websites keep the cookie active even if the user has “logged out” and closed the session? Worse, when the same has been done a hundred times! Why do they keep ‘all the sessions maintained’ even when the log-out page has been accessed? I can’t think of a valid justification, and thus it makes a vulnerability. Now, let us go through some famous websites that are vulnerable –

Microsoft Mail Service (www.outlook.com and www.live.com)

Microsoft mail services are vulnerable to this session management flaw. Apart from your regular MSN/Live email accounts, you can also move your corporate accounts on outlook exchange mail service. Thus, it also affects your Microsoft hosted corporate accounts. Now, the problem with outlook/live is that it authenticates the old session cookies even if the user has logged out from the session. Here is a walkthrough of the authentication cookie for live.com but the same works with outlook.com accounts as well,

Name Value
Host .login.live.com
Name PPAuth
Path /
Content <removed for privacy & account security>
Expires At the end of session
Send for Encrypted connections only
Created Tuesday, March 19, 2013 9:51:42 PM
Last accessed Tuesday, March 19, 2013 9:51:42 PM
HTTP only No
This domain only Yes
Policy <no information available>
Status <no information available>

To check this vulnerability & confirm the finding, here are some of the steps,

  1. Login to your live.com/ outlook.com account and check for cookies (recommended: Cookie Manager w/ Firefox).
  2. There will be a huge list of cookies added by live.com. Look for the authentication cookie (PPAuth for live.com or RPSAuth for outlook.com).
  3. If not sure among the different *AUTH cookies (MSPAuth, PPAuth, RPSTAuth), for safer side, backup of all types of *AUTH cookies in a separate file.
  4. Click the logout/ sign-out from your account. Check the cookies and make sure the *AUTH cookie(s) are deleted.
  5. Ideally the AUTH cookie should be deleted from the server too. But has it? Lets check.
  6. Import the saved cookie into the browser, and try opening live.com. You will see the mailbox right away.

So what just happened? How the old cookie is still being validated at the server end? The cookie expires at the end of session, gets deleted from the browser but what about the server? Why the server maintains the authentication cookie and for how long will this be valid? No idea but scary.

Twitter Service (www.twitter.com)

Twitter is even a step ahead with this strange behaviour. Let us first check the authentication cookie for Twitter,

Name Value
Host .twitter.com
Name auth_token
Path /
Content <removed for privacy & account security>
Expires At the end of session
Send for Encrypted connections only
Created Tuesday, March 19, 2013 11:37:33 PM
Last accessed Tuesday, March 19, 2013 11:37:33 PM
HTTP only No
This domain only Yes
Policy <no information available>
Status <no information available>

We now logout from the session, and clean the cache/ delete the cookies. Let us import this cookie in the browser, and voila! we have the twitter authenticated. So, twitter is for sure vulnerable to bad session management.

Here is a video POC –

Twitter–Session Management (auth_token)

There is a bigger issue with twitter – the authentication cookie (auth_token) is a CONSTANT alphanumeric string. During my research, and multiple logins to twitter, it turned out to be the same constant string again and again. It is NOT a random generated session based token, but even after multiple logins via different browsers/ IPs, it remains constant every time. It means, once it is stolen, an attacker can gain control of your account anytime. OMG! is this the way to handle an authenticated session? Twitter! I didn’t expect this from you.

LinkedIn Networks (www.linkedin.com)

I have already spoken a lot on LinkedIn session management in my previous article. Here is the authentication cookie for LinkedIn,

Name Value
Host www.linkedin.com
Name leo_auth_token
Path /
Content LIM:<removed for privacy & account security>
Expires Tuesday, June 18, 2013 12:20:02 AM
Send for Any type of connection
Created Wednesday, March 20, 2013 12:19:52 AM
Last accessed Wednesday, March 20, 2013 12:20:03 AM
HTTP only No
This domain only No
Policy <no information available>
Status <no information available>

Yes, LinkedIn cookie still has the HTTPS and HTTP Only flag not set. It means, the cookie is very much available for sniffing on HTTP channel. Enough said.

Yahoo Service (www.yahoo.com)

Okay, I know Yahoo was an odd choice, but still I was curious how yahoo web application actually handles the session management. Here is my analysis on the two cookies (Y and T) which act as authenticated cookies for session management with Yahoo,

Authentication Cookie – ‘T

Name Value
Host .yahoo.com
Name T
Path /
Content <removed for privacy & account security>
Expires At end of session
Send for Any type of connection
Created Wednesday, March 20, 2013 12:39:27 AM
Last accessed Wednesday, March 20, 2013 12:39:27 AM
HTTP only No
This domain only Yes
Policy <no information available>
Status <no information available>

Other verification cookie – ‘Y

Name Value
Host .yahoo.com
Name Y
Path /
Content <removed for privacy & account security>
Expires At the end of session
Send for Any type of connection
Created Wednesday, March 20, 2013 12:39:27 AM
Last accessed Wednesday, March 20, 2013 12:39:27 AM
HTTP only No
This domain only Yes
Policy <no information available>
Status <no information available>

Yes! Yahoo is even vulnerable and the cookies are not being locked with ‘Encrypted sessions ONLY flag’.

Summary

Here is a list of websites that I tested against the session management vulnerability –

  1. www.outlook.com / www.live.comVulnerable
  2. www.google.com / www.gmail.comNot Vulnerable
  3. www.twitter.comVulnerable
  4. www.linkedin.comVulnerable (still)
  5. www.facebook.comNot Vulnerable
  6. www.yahoo.comVulnerable

As it is well confirmed that session management vulnerability is very common, and most of the web servers do not discard the session even after the user has logged out. This practice is not safe, and needs quick attention. No matter how strong a password is, but vulnerability in handling a session can be the loophole you should never take it lightly.

Mar 19th, 2013 | Filed in: Hacking | Trackback
Author: Rishi Narang
  1. Mar 23rd, 2013 at 17:13 | #1

    Was shocking… that such a thing still exists. Great work rishi sir. :)

  2. Mar 23rd, 2013 at 18:42 | #2

    session cookie post!!!!!!waiting :-)@ref null…regards..anupam

  3. hitechkhiladi
    Mar 24th, 2013 at 07:54 | #3

    Was aware of the yahoo being still vulnerable to Session hijacking..anyways who uses it these days !!
    Nice Post Thanks for sharing :)

  4. Sandeep
    Mar 24th, 2013 at 16:26 | #4

    An exemplary work by a real world security professional! Real World Problem ! ;)