Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Businesses Communications Google The Internet

HTTPS Cookie Hijacking Not Just For Gmail 128

mikepery writes with a followup to last month's mention of a security vulnerability affecting Gmail accounts, which it seems understated the problem. "I figure the Slashdot readership is the best place to reach a large number of slacking admins and developers, so I want to announce that it's been 30 days since my DEFCON presentation on HTTPS cookie hijacking, and as such, it's now time to release the tool to a much wider group. Despite what was initially reported, neither the attack nor the tool are gmail-specific, and many other websites are vulnerable. So, if you maintain any sort of reasonable looking website secured by any SSL certificate (Sorry Rupert, you lose on both counts), even if it is just self-signed, you can contact me and I will provide you with a copy of the tool. Be sure to put 'CookieMonster' in the subject, without a space." (More below.)
"I'd also like to encourage security professionals and consultants to request a copy of the tool for use in encouraging their clients to adopt SSL properly for their websites. There's no possible way for me to reach every site, but if convincing demonstrations can be given of the vulnerability on an individual basis, perhaps that will drive the issue home much more than the press alone has done. Heck, the tool might even land you a few new clients."
This discussion has been archived. No new comments can be posted.

HTTPS Cookie Hijacking Not Just For Gmail

Comments Filter:
  • by Anonymous Coward

    Posting an e-mail address on /.

    • Re: (Score:3, Interesting)

      Comment removed based on user account deletion
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        i'm thinking cm is "contact me", so contact me via the fscked organisation

        • by grcumb ( 781340 )

          i'm thinking cm is "contact me", so contact me via the fscked organisation

          Er, cm == 'Cookie Monster', I think.

          He's likely using a hyphenated address which allows for filtering using scripted mail tools.

      • How do we know he isn't phishing for email addresses right in the summary?
      • by Anonymous Coward

        Are you that ignorant that you can't figure out his email.

        via = @
        thefsckedorganization = fscked.org

        He is using mikeperry-cm@ because he's called his tool Cookie Monster.

        I swear, some people need an IQ test before they should be allowed to post!!

      • by gad_zuki! ( 70830 ) on Tuesday September 09, 2008 @02:36PM (#24936449)

        cmvia is command modulated voice interface application. In other words you roll down your window and yell 'MIKE PERRY I NEED THAT FILE.' Eventually a carrier pigeon delivers it to you.

  • ...see this is why the military has an entirely physically separate internet for the Really Important Shit(tm).
    • Re: (Score:3, Funny)

      Yep. The Very Best(tm) security is an air gap.
      But it kinda limits your possibilities.
      • Re:yeah... (Score:5, Informative)

        by n3tcat ( 664243 ) on Tuesday September 09, 2008 @11:54AM (#24934491)
        In what way? We run a lot of stuff over our SIPR [wikipedia.org] and I haven't really noticed any "limits" to what we've done. Hell, I even watch CNN over SIPR sometimes.
        • No, I said an air gap (i.e. no network connection) is the best security, but it limits your possibilities.
          • by n3tcat ( 664243 )
            Ah, yeah "air gapping" is what we call transferring data from one side to the other. Now I understand what you were saying though.
            • Well, I don't know where you're located on the SIPR, but here in that big, oddly-shaped building near the river alongside the city with the big pointy tower and the big white-domed place, we call that "a major pain in my ass."
        • by lems1 ( 163074 )

          I like that when you click on the Privacy notice on the DoD Network Information Site (http://www.nic.mil/), you get a 404 page:

          http://www.disa.mil/info/secpriv.html [disa.mil]

          Ah, the irony of it... I guess there is not a single privacy statement that would protect anybody from just clicking through publicly available pages?

        • Re: (Score:3, Insightful)

          by Frosty Piss ( 770223 )
          CNN, FoxNews, and a few other broadcast channels are re-broadcast on SIPR because that's where Intel gets their Intel.

          Walk into any US Intel / Base Ops / Command Post in the world, and you'll find CNN on a big flat-screen up on the wall.
          • Re: (Score:3, Funny)

            by LiENUS ( 207736 )

            Walk into any US Intel / Base Ops / Command Post in the world, and you'll find CNN on a big flat-screen up on the wall.

            I tried this, now i'm in gitmo.

          • Walk into any US Intel / Base Ops / Command Post in the world, and you'll find CNN on a big flat-screen up on the wall.

            Yep, it's a good idea to monitor the broadcasts of the opposition.

            CNN -- the news network that carries The Daily Show on it's international feed.

      • Re: (Score:2, Interesting)

        I think Franklin ahref=http://sln.fi.edu/franklin/scientst/electric.htmlrel=url2html-25902 [slashdot.org]http://sln.fi.edu/franklin/scientst/electric.html> might have disagreed vehemently with you. Air breaks down as a dielectric, given a high enough voltage across it. And, of course, electromagnetic radiation of all kinds goes right on through air as if it wasn't there. And don't get me started on sound ;-)
        • Re: (Score:3, Informative)

          by Hyppy ( 74366 )
          Many (most?) classified government systems require TEMPEST [wikipedia.org] hardening, to specifically protect against your second point. Many government buildings which contain classified materials also require a similar hardening.
    • Comment removed based on user account deletion
  • Easy to find out... (Score:5, Informative)

    by nweaver ( 113078 ) on Tuesday September 09, 2008 @11:34AM (#24934239) Homepage

    If you want to manually examine a site you visit:

    Clear all cookies.

    Log in.

    Clear all cookies marked as "SECURE" (in firefox, preferences->privacy->show cookies. Delete JUST the cookies marked as "Encrypted connections only").

    Go back to the site. Can you act as if you are logged in? If so, the site is COMPLETELY insecure.

    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Tuesday September 09, 2008 @11:46AM (#24934389)
      Comment removed based on user account deletion
      • by brunascle ( 994197 ) * on Tuesday September 09, 2008 @12:05PM (#24934605)
        If you're suggesting that the site should be tying the cookie to an ip address, then I have to disagree. I've done just that, and I discovered that it's a very bad idea. Not just because some people have a different ip address from one session to the next, but because some of them have a different ip address from one page to the next. For example, there are some ISPs that send GET requests through one address, and POSTs through another.
        • Re: (Score:3, Interesting)

          by HungryHobo ( 1314109 )

          I can get you there.
          My ISP assigns me a new IP every few minutes even if I'm in the middle of a download. Makes using rapidshare impossible.
          And yes, there's always the jackass developer who thinks he's smart locking sessions to an IP which for me just means either being logged out again and again or it locking up till the link to the old IP has expired.

          Yes I know it's the ISP but they're the only game in town and I'm not going back to 56K

          • and you don't want to pay the extra $5 a month or what have you for a static IP?
            • Only available with the buisness package(or so I was told when I called them) which is much more expensive.

        • Re: (Score:3, Interesting)

          Comment removed based on user account deletion
        • by raddan ( 519638 )
          Not to mention, there are some very large NATs out there. IPs are not in 1:1 correspondence with real machines.
    • All of my cookies are for "Any type of connection" including my bank.

    • by pragueexpat ( 674635 ) on Tuesday September 09, 2008 @11:51AM (#24934471)
      if this is true (and I am able to follow directions correctly) then Bank of America has some explaining to do.
      • by blueg3 ( 192743 ) on Tuesday September 09, 2008 @11:58AM (#24934545)

        I think the explanation is quite simple. "We don't know what we're doing."

      • Bank of America has some explaining to do.

        They would boast about their SiteKey© or some such thing. I doubt much would change without a greater segment of the customer base demanding it.

      • Re: (Score:2, Funny)

        if this is true (and I am able to follow directions correctly) then Bank of America has some explaining to do.

        Here, why don't you give me your current IP address real quick and I'll take a look it to make sure you're doing everything correctly. ;)

      • by Atario ( 673917 )

        Bank of America has had some explaining to do for many years now, and I ain't talkin' 'bout no websites, neither.

    • by mcrbids ( 148650 ) on Tuesday September 09, 2008 @01:01PM (#24935295) Journal

      I did this with our own web-based product and found out that yes, indeed, we are insecure. It took a few minutes of poking around to find out how to secure our site.

      So, for everybody else: if you are using PHP, you need to pay attention to Set_Cookie_Params() [php.net]. Here's the 1-liner call that we make in order to solve this problem for us, before any calls to session_register():


      Session_Set_Cookie_Params(720, '/', $_SERVER['SERVER_NAME'], true);

      Parameters:

      1) 720: Our sessions timeout after 2 hours.

      2) '/': the cookie applies to all paths within our site.

      3) $_SERVER['SERVER_NAME']: applies only to the specific domain name originally called. (we use subdomains, so this is important)

      4) true: (the most important one), this means that the cookies can only be used over SSL.

      • by enoz ( 1181117 )

        You could do the same thing using a .htaccess file (assuming you are running Apache).

        php_flag session.cookie_secure on

        This way ensures that it is set before any PHP script runs, regardless of what scripts are used.

    • Comment removed based on user account deletion
    • by ldaff ( 879482 )
      I could be wrong, but I don't think this is true in our circumstances. We have a site that doesn't allow any connections other that https. So, even though we do have cookies set to go through all connections - there is no way to get a non-ssl connection to the site and have the cookies go out clear over the wire. Someone please correct me if I'm wrong, because we'd have some changes to make.
  • WTF?!? (Score:5, Insightful)

    by Anonymous Coward on Tuesday September 09, 2008 @11:48AM (#24934427)

    If you are going to release a tool, just fucking do it. Give is a link and be done with it.

  • by randomc0de ( 928231 ) on Tuesday September 09, 2008 @12:09PM (#24934653)
    I run a few Django SSL-secured websites, and I noticed the default is to send insecure cookies for the session id (i.e. hijack-able cookies). I'm going to try to get on someone's case to make this information more widely available, because you have to turn on secure cookies with a "SESSION_COOKIE_SECURE = True" statement, which I never knew until I checked today. Doing this should secure any Django-powered site from this particular attack.
    • by pavera ( 320634 )

      So... I suppose I've been mis-using SSL all along, but, I secure the login with ssl, after that, the information inside my sites isn't particularly sensitive in any way, I just protect the username/password on the wire for all those people that have 1 username and 1 password for everything...

      I assume to protect against this vuln every page behind the login has to be 100% SSL secured so that you can keep sending the sessionid cookie? If so, that means I get to buy twice as many servers for my 2 little web a

      • I assume to protect against this vuln every page behind the login has to be 100% SSL secured so that you can keep sending the sessionid cookie? If so, that means I get to buy twice as many servers for my 2 little web apps (that already have 5 servers dedicated to them) to support all that SSL traffic?

        I doubt it. Try turning on secure cookies and only having an SSL-enabled login page. Your webserver should be able to accept the secure cookies over SSL and insecure data over HTTP.

        5 servers for 2 apps is a lot. Have you tried a more distributed scheme with 2 servers for the HTML, 2 for the database, and a dedicated SSL proxy? It's a bit of a pain to set up, but you may get better performance with a dedicated SSL machine than the "Renaissance server" tactic.

        • by pavera ( 320634 )

          I have 3 web and 2 db... I guess I could pull one of those web and dedicate it to ssl...
          Anyway, I'll give it a go and see what happens.

  • fscked.org got fscked by getting slashdotted
  • Ways to fix this:

    File Permissions: When the web server asks to write cookie, browser uses file permissions to create a group for that site, and allows only members of that group to read or write to that cookie. Either use the disk filesystem's permissioning, or reimplement a permissioning system within the browser profile, to be used only for cookies.

    File Encryption: Using a public key encryption method, the content of cookie file is encrypted using the web site's private encryption key, and can only be

    • File Permissions: When the web server asks to write cookie, browser uses file permissions to create a group for that site, and allows only members of that group to read or write to that cookie. Either use the disk filesystem's permissioning, or reimplement a permissioning system within the browser profile, to be used only for cookies.

      Requires giving the browser root access to the system (though you can mitigate this by running a jail or sandbox).

      File Encryption: Using a public key encryption method, the content of cookie file is encrypted using the web site's private encryption key, and can only be decrypted by the web server.

      I thought that's what SSL cookies do in the first place?

      • File Permissions: When the web server asks to write cookie, browser uses file permissions to create a group for that site, and allows only members of that group to read or write to that cookie. Either use the disk filesystem's permissioning, or reimplement a permissioning system within the browser profile, to be used only for cookies.

        Requires giving the browser root access to the system (though you can mitigate this by running a jail or sandbox).

        Good point, kindof why I suggested re-implementing permissioning at a higher level of abstraction than the filesystem.

        I thought that's what SSL cookies do in the first place?

        Right, but I'm saying they should do encrypted cookies across the board, whether the site is SSL or not.

        • Wait wait... what?

          Encrypt the cookie data with the site's private key? ... So that holders of the site's public key can decrypt the contents of the cookie? Which would be everyone?

          But maybe you meant encrypt the cookie data with the site's public key, so that only the site can decrypt it. That would make more sense. But, still, that doesn't work.

          See, you'll be sending something over HTTP to the site in question. Let's say it's a secret message that only the site can decrypt, per your proposal. That do

  • by JoeCommodore ( 567479 ) <larry@portcommodore.com> on Tuesday September 09, 2008 @12:28PM (#24934917) Homepage

    There were a lot of 'email me's and talk about bad htps settings but not much content on really what needs to be done for fixing an existing site or properly setting up a new site to be secure.

    • by jimicus ( 737525 ) on Tuesday September 09, 2008 @02:09PM (#24936127)

      There were a lot of 'email me's and talk about bad htps settings but not much content on really what needs to be done for fixing an existing site or properly setting up a new site to be secure.

      Executive summary:

      It is possible to set a single bit in a cookie sent to the browser which means "Only send this cookie over secured connections".

      Many websites (including some important ones like online banking) don't set this bit for the cookie(s) used for session tracking. Hence, it is possible for an attacker to get the cookie with an invisible proxy that injects HTML which forces the browser to fetch something from the server which set up the cookie.

      eg. I set up an invisible proxy on my wireless network which injects into every page and logs the cookie your browser sends when it attempts to connect to mail.google.com for the image.

      I can now plug this cookie into Firefox and read your email.

      Solution: if your website sets any cookies over an HTTPS connection, such cookies must set the bit meaning "Only send over secure connections". How one goes about doing this will depend on whether you're generating cookies yourself or using an existing framework.

  • Let's make this simple. Don't use webmail. Don't use Yahoo.com, Gmail.com, Hotmail.com, squirrelmail, etc. There are SO many vulnerable access points between the web application and your email that it is almost impossible to secure the entire stack.

    The use of Ajax alone (like most major webmail vendors) increases your vulnerability by huge amounts. SOP (same origin policy) is broken. A combination of a reflected XSS attack (which are everywhere http://blogs.zdnet.com/Google/?p=451 [zdnet.com] ) and a stored XSS attack

    • by ccguy ( 1116865 ) *

      Don't use webmail

      So seriously - unless you trust that your email server has secured every possible hole in every possible layer of their stack, stick to TLS/SSL encrypted imap/pop3/smtp. Now, I'm not saying these are perfect, but email protocols are just simpler.

      Your solution only works if

      webmail+storage at google

      is more secure than

      smtp/pop over tls + storage at a typical user's HD which I'm pretty sure is a bad assumption.

      • Oh - I'm not speaking to the typical user. The typical user probably has a keylogger or trojan that makes this all void. I'm speaking to those who are security literate and want to choose both the simplest and most secure solution.

        Personally, I use GPG and have an encrypted hard drive and I feel far more comfortable using IMAP over TLS after compromising Gmail with an XSS exploit.

  • Google Cache [74.125.45.104]

    All I want for Christmas is a website that /. can't bring to it's knees.
  • Yodlee MoneyCenter passes the test, and appears secure. However, my own personal online banking institution did not fare so well. Argh!
  • Using the method outlined in the post, I can't find any sites that I have cookies for that aren't vulnerable.

    • I don't even seem to have any cookies that are set 'encrypted connection only', a major banking site has all cookies sent for any type of connection.

      If I understand the problem correctly, it seems a simple workaround is to delete all cookies related to a vulnerable site as soon as you've finished, that would soon stop my browser sending them to nefarious sorts with invisible proxies.
  • Firefox should complain loudly when such cookies are being sent:

    "Server error: server has sent cookies unsafely. You can add an exception, by clicking below, but until the web site operator fixes the site, you should consider your session not secure."

  • You know, that "encrypted sessions only" bit wasn't put in there just for fun. It's bad enough we have any number of things broken by design, we could at least use the security which actually _was_ designed into the system.

  • The issue described (Score:5, Informative)

    by rabtech ( 223758 ) on Tuesday September 09, 2008 @03:45PM (#24937401) Homepage

    1. Look at DNS requests or do a IP-domain reverse lookup to know what websites the target is visiting over HTTPS. Automated tool can do this over time.

    2. On next regular HTTP request by your target, be a man-in-the-middle and inject an image pointing to desired HTTPS site, except don't use HTTPS - just HTTP.

    3. Browser will dutifully send the cookie along with the image request over plain HTTP (after all, the domain names match), even though the cookie was created and managed only via HTTPS by the original website.

    4. Now your automated sniffer just picked up the supposedly "secure" cookie for the HTTPS site, even though you never even attempted to hack the HTTPS conversation. If the site stores your username/password, a session id, etc this could expose sensitive information.

    5. Protect your applications by setting the encrypted session only flag on the cookie so the browser won't send it with plain HTTP requests. If you have HTTP and HTTPS areas of the site, keep separate cookies for both areas and make sure sensitive info is only stored in the HTTPS-only cookie.

    • Thanks for your clarification.

      This is basically what I gathered from reading the author's description, but it was so poorly written that it left me wondering.

    • While this is disconcerting, it's not like step 2 (being a man in the middle) is easy for an attacker. If they can play that game, you have many things to worry about, which I think is a pretty simple explanation for why people aren't totally panicking over this.

    • by Alsee ( 515537 )

      Good explanation, but I find it's better to just skip the cookies entirely and stick to cupcakes.

      -

  • So, if you maintain any sort of reasonable looking website secured by any SSL certificate (Sorry Rupert, you lose on both counts)

    OK, when did it become funny to put the contents of my cookie in TFA?

    Oh, and I am not responsible for the CSS on the sites I develop for my employer. Don't blame me for the dark blue text on a medium blue background.

  • (For those who might be tempted to say Defcon, it was not ready).

    It's out there, enough with the needless delays and just get a mirror/link out there.

  • A countermeasure against this attack scenario has just been added to latest NoScript development version [noscript.net]:

    v 1.8.0.5

    Experimental "Force Secure Cookies" feature, mitigates HTTPS cookie hijacking attacks (http://tinyurl.com/cookiehijack).
    Enabled by default, it can be disabled either globally, by toggling the noscript.secureCookies about:config preference, or for specific domains only, by listing them (space or comma separated) in the noscript.secureCookiesException about:config preference

    Whenever a cookie

  • If you are leaving your home for a few days and have trouble locking your home, let me know the address and I'll send you a lock!

  • Alarmmingly, asp.net session and authentication cookies do not have the secure bit set even when the site is set to https-only.

    The server still accepts http requests to display a "site can only be viewed over https"

    This C# code added to global.asax will secure all cookies on a .net site. I've left cookies unsecure when browsing localhost so Visual Studio debugging and "view in browser" will still work.

    protected void Application_EndRequest(Object sender, EventArgs e)
    {

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Working...