Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet Twitter Yahoo! IT

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."
This discussion has been archived. No new comments can be posted.

Twitter, Hotmail, LinkedIn, Yahoo Open To Hijacking

Comments Filter:
  • Hijacking ha (Score:5, Informative)

    by earlzdotnet ( 2788729 ) on Friday March 22, 2013 @10:25AM (#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:Not a new exploit (Score:3, Informative)

    by Anonymous Coward on Friday March 22, 2013 @10:40AM (#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 (Score:5, Informative)

    by JoshRosenbaum ( 841551 ) on Friday March 22, 2013 @12:04PM (#43247367) Homepage

    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.

Say "twenty-three-skiddoo" to logout.

Working...