Slashdot Mirror
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."
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.
(1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
Hotmail still exists?
seriously, if you don't have cookie authentication, all the interrelated services on those sites would require logins every time you view the page. It's a feature that these sites retain your auth for days or longer on purpose as a cookie. It's not trivial to get the cookie from the user unless you can log onto their system or intercept plain http using XSS or similar.
see http://codebutler.com/firesheep/ for an example of this over a year ago....
kind of surprising that this security expert is just finding out about this now, and assuming that it's not common knowledge
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
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.
Will the HTTPS Everywhere pluggin protect me from this?
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?
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.
I agree that this isn't big news. However, the comments here seem to be missing the point a bit. The issue isn't entirely with HTTPS/SSL. Yes, that could help prevent leaking the session details, but an XSS vulnerability (even with HTTPS/SSL) could leak the cookie information to an attacker. I think the bigger issue is that these services are not properly handling their sessions during log ons and log outs. If you look at the OP's video he is able to get back into this Twitter account after a supposed "successful" logout. An old session should not be able to be used after the user has logged out or their session has timed out. I disagree with the post that says this is difficult to protect against without huge overhead or being prone to errors. It's actually very simple- properly terminate sessions during logout so they can't be reused.
This is a very simple problem to solve. Just make the authentication cookie contain a hash of several lines of key data (MD5 or whatever is considered secure today). The key data should include your password, IP address, and the cookie expiration time. It could also include your browser ID string and other things that might be useful to keep consistent.
The only problem with the above as described is that it requires the server to save your plaintext password, but the same scheme would work with a hash of the password. The cookie could even be generated by the browser without interacting with the web site at all, except that it would need to know the IP address as seen by the web site (NAT makes that difficult to know).
If you leave out the IP address from the hash, then it is more convenient for computers that move frequently, but is obviously less secure.
Congrats, you just discovered cookies!
Spoiler: if a hacker can log your keystrokes and get your passwords, they can also log into your online accounts!
Tune in next week when we explain how running virus.exe can be bad for your computer
Well, that explains how my Yahoo account got hacked a couple of weeks ago. No more Yahoo for me.
"Courage is being afraid to do the Right Thing, and doing it anyway."
The simplest fix, of course, is to use https for all cookie handling, which probably means https for every page access.
The problem with having HTTPS on every logged-in page access is that Internet Explorer for Windows XP and Android Browser for Android 2.x lack support for Server Name Indication. This means that if a web server hosts more than one domain using name-based virtual hosting, a browser using an SNI-incapable SSL stack can't see any certificate past the first, and users will see a certificate error. In this era of IPv4 address scarcity, this especially hurts hobbyist sites on shared web hosting, whose operators don't necessarily have the money for a VPS with its own IP address. For example, this looks fine on Chrome, Firefox, or IE 9+, but it gives a cert error on Gingerbread's browser and IE 8 on XP. Windows XP will pass out of support in 13 months, but seeing how prepaid wireless carriers are still selling Android 2.3 devices, I don't see the SNI problem ending any time soon.
This is called a Replay Attack. And protecting against it is very difficult
How would it be so difficult? The attack wouldn't work on, say, PhilsHobbyShop.com because each session record stores an expiry time. Normally they expire 16 hours after creation, after which the session ID can no longer be used to gain the user's privileges. At any time, the user can set expiry to the current time by clicking "log out".
Step 1: Create a cool new Twitter application that everyone wants to use
Step 2: Store auth_token strings from users.
Step 3: When a few mega-popular users have tried your service, use the auth_token/cookie method to begin Tweeting as them.
Step 4: Profit.
Also, relevant XKCD: http://xkcd.com/792/
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
And this is news? Welcome to 2013.
I used to use this exact method to show people that open wifi is bad, I can just copy/paste the captured Set-Cookie:s from the header and paste them into my browser's cookies.txt and voilla I'm using [website] as them. This was 10 years ago.
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
I always thought of this as a nature of the web itself. Does it really have a workaround, except securing the traffic itself?