The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

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 cant 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,

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

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 didnt 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

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.

Continue reading on wtfuzz.com