Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTPS Cookie Hijacking Not Just For Gmail

Posted by timothy on from the cookie-monster-demands-satisfaction dept.

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

29 of 128 comments (clear)

  1. new security vulnerability by Anonymous Coward · · Score: 2, Funny

    Posting an e-mail address on /.

    1. Re:new security vulnerability by Anonymous Coward · · Score: 2, Interesting

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

    2. Re:new security vulnerability by gad_zuki! · · Score: 4, Funny

      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.

    3. Re:new security vulnerability by Heembo · · Score: 2, Funny

      He was just trying to use basic Darwinism to filter out idiots. But some defender of white moths told them to fly away and take cover cause da smoke was a comin! Dam u!

      --
      Horns are really just a broken halo.
  2. Easy to find out... by nweaver · · Score: 5, Informative

    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.

    --
    Test your net with Netalyzr
    1. Re:Easy to find out... by pragueexpat · · Score: 5, Interesting

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

      --

      "The prohibition will be strongest when the group is nervous." - Paul Graham

    2. Re:Easy to find out... by blueg3 · · Score: 4, Insightful

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

    3. Re:Easy to find out... by brunascle · · Score: 4, Informative

      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.

    4. Re:Easy to find out... by HungryHobo · · Score: 2, Interesting

      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

    5. Re:Easy to find out... by morgan_greywolf · · 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. ;)

      --
      My blog
    6. Re:Easy to find out... by mcrbids · · Score: 3, Interesting

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

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
  3. Comment removed by account_deleted · · Score: 4, Informative

    Comment removed based on user account deletion

  4. WTF?!? by Anonymous Coward · · Score: 5, Insightful

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

  5. Re:yeah... by $RANDOMLUSER · · Score: 2, Funny

    Yep. The Very Best(tm) security is an air gap.
    But it kinda limits your possibilities.

    --
    No folly is more costly than the folly of intolerant idealism. - Winston Churchill
  6. please tag itsatrap by sveard · · Score: 4, Interesting

    Why don't YOU just e-mail the guy and be done with it?!

    Perhaps it's... A TRAP!

    1. Re:please tag itsatrap by Joe+U · · Score: 3, Funny

      Please install this tool on all servers and workstations as admin for maximum benifit.

  7. Re:yeah... by n3tcat · · Score: 5, Informative

    In what way? We run a lot of stuff over our SIPR and I haven't really noticed any "limits" to what we've done. Hell, I even watch CNN over SIPR sometimes.

  8. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  9. Re:yeah... by PJ+The+Womble · · Score: 2, Interesting

    I think Franklin ahref=http://sln.fi.edu/franklin/scientst/electric.htmlrel=url2html-25902http://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 ;-)

  10. Djagno and Secure Cookies by randomc0de · · Score: 5, Informative

    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.

    --
    Three rights make a left. Freedom of speech, freedom of the press, freedom of assembly.
  11. Re:yeah... by Hyppy · · Score: 2, Informative

    Many (most?) classified government systems require TEMPEST hardening, to specifically protect against your second point. Many government buildings which contain classified materials also require a similar hardening.

  12. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  13. Re:yeah... by Hyppy · · Score: 2, Insightful

    He is. Rebroadcasting a satellite feed is simple.

  14. How do you secure a site? by JoeCommodore · · Score: 3, Interesting

    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.

    --
    "Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
    1. Re:How do you secure a site? by jimicus · · Score: 3, Informative

      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.

  15. Re:yeah... by Frosty+Piss · · Score: 2, Insightful

    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.

    --
    If you want news from today, you have to come back tomorrow.
  16. Re:yeah... by LiENUS · · Score: 3, Funny

    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.

  17. Re:Secure by permissioning or secure by encryption by corbettw · · Score: 2, Informative

    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?

    --
    God invented whiskey so the Irish would not rule the world.
  18. The issue described by rabtech · · Score: 4, Informative

    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.

    --
    Natural != (nontoxic || beneficial)