Twitter, Hotmail, LinkedIn, Yahoo Open To Hijacking 50
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."
Not a new exploit (Score:5, Insightful)
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: (Score:3, Informative)
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: (Score:3)
Simplified example:
Embedded image src in email: http://www.hacker.com/cookieparser.php?default=<script>alert(document.cookie)</script>
Obviously more complicated because you need to mask your embedded code to get through the fi
Re: (Score:2)
https is used to prevent session fixation working without a secondary exploit. If you have a secondary exploit that allows access to the cookie (e.g. the XSS exploit you're describing), then a different fix is needed for the different exploit (for instance, fixing the XSS hole itself, or marking the cookies as http-only so that they can't be accessed via JavaScript). If you don't have https, then someone with access to the victim's network doesn't need another exploit at all; their network access is enough
Re: (Score:2)
Re: (Score:2)
> 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. ..snip..
>
> Simplified example:
Embedded image src in email: http://www.hacker.com/cookieparser.php?default= [hacker.com]alert(document.cookie)
I hope I don't understand that correctly.
WHY is any browser expressing a cooking via javascript as a target of a link to a site that has nothing to do with the cookie?
WHY would any browser
Re:Not a new exploit (Score:5, Informative)
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> [hacker.com];
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.
Re: (Score:2)
I agree, it's more of a general problem with single step auth (session hijacking)... but if somebody's getting a hold of your cookies you've got all sorts of problems, twitter being the least of them compared to say a financial account (though those tend to be more secure, the connection/machine are still compromised).
Also, firesheep is overrated, nobody respectable uses hubs on their network.
Re: (Score:2)
Re: (Score:2)
free wifi at many restaraunts have a MiTM page that could easily be used to hijack many accounts - I've already seen what could be construed as a MiTM attack using my Nexus 7 on a free wifi with a landing page. Was attempting to google something and got the business page after being redirected to their acceptable use page instead of the google search page.
Server Name Indication (Score:3)
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 d
Re: (Score:2)
Hotmail (Score:5, Funny)
Re: (Score:3)
No, they switched everyone to the crappy Metroised 'Outlook' now.
It also appears to use SSL by default now, so cookie stealing will be tough.
Re: (Score:3)
In a way. If you have an old e-mail address ending in "@hotmail.com" it's still valid but only as an alias of your new "@outlook.com" one (if you take the trouble of creating one).
Also, Outlook.com is quite nice now that Google scrapped the free Apps version. Last time I checked Microsoft was providing 500 or so e-mail accounts for free for domain owners. The all Metro interface is somewhat meh but whatever, for a free service (that you can replace anytime given you own the domain) it works well enough.
Hijacking ha (Score:5, Informative)
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
Re: (Score:2)
As it stands, this isn't a story big enough to make the news. All the cookies are kept over HTTPS, so when getting a user's cookie is as easy as truly "breaking" HTTPS, there is little risk and numerous other websites will have this same "problem"
Also, what do you bet they have at least some protection against replay attacks like ensuring client side IP address or some such matches along with other unique identifiers. Although, making cookies like this last for a month or more at a time does feel pretty u
Store an expiration date for each session ID (Score:2)
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".
Re: (Score:2)
SSL/HTTPS (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
As mentioned above, the new crappy 'Outlook' site that replaced hotmail appears to force SSL. Looks like Yahoo Mail has a 'force SSL' option, but you have to explicitly turn it on. No idea why it's not on by default.
HTTPS Everywhere plugin (Score:2)
Will the HTTPS Everywhere pluggin protect me from this?
Re: (Score:2)
Using two cookies? (Score:3, Insightful)
Session Fixation? I don't think so. (Score:5, Interesting)
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.
Re: (Score:2)
If so...again, SSL fixes this.
Re: (Score:3)
They aren't talking about any method of gaining access to the cookie, just demonstrating what you can do one you have, somehow, magically, gained the information. May as well demonstrate what you can do if the victim tells you their passwords.
Missing the point (Score:1)
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
How authentication cookies should work (Score:2)
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
Re: (Score:2)
The key data should include your password, IP address, and the cookie expiration time.
Even if encrypted, why include the pw? Also, and this is my own ignorance here, but it sounds to me like the attacker still needs access to the target's workstation. Such attacks are low on my list of security problems, at least in my current working environment.
Re: (Score:2)
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.
If you use the IP address as part of the authentication, every time my employer (or ISP) NATs my traffic through a different IP address, I'll have to log on again.
This is particularly troublesome with cell phones, my phone might get a dozen different IP addresses a day as I transition from home to the cellular network to various hot spots on my commute to work and back again.
Re: (Score:2)
IP address certainly seems like a great way to filter, but some users are switching IP addresses randomly by using proxies or get new IP addresses more often, because of their connection. So IP can be an unreliable detection method. Also, since it's possible the person is on your network when sniffing your request, they could possibly just use your same IP address anyway.
Using the browser ID (or other headers) is no good either, because the attacker can sniff and use that as well. In fact, nothing that is i
Yahoo Account Go Bye Bye (Score:1)
Well, that explains how my Yahoo account got hacked a couple of weeks ago. No more Yahoo for me.
Re: (Score:1)
Three Steps (Score:3)
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/
Re: (Score:2)
Step 2: Point a bot at #AuthTokenDickWaving.
Step 3: Fuck step 3. You're done.
Nothing new. (Score:3)
Re: (Score:2)
It's in http's nature (Score:1)