Slashdot Log In
HTTPS Cookie Hijacking Not Just For Gmail
Posted by
timothy
on Tue Sep 09, 2008 11:24 AM
from the cookie-monster-demands-satisfaction dept.
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."
Related Stories
[+]
A Good Reason To Go Full-Time SSL For Gmail 530 comments
Ashik Ratnani writes with this snippet from Hungry Hackers: "A tool that automatically steals IDs of non-encrypted sessions and breaks into Google Mail accounts has been presented at the Defcon hackers' conference in Las Vegas. Last week, Google introduced a new feature in Gmail that allows users to permanently switch on SSL and use it for every action involving Gmail, not just authentication. Users who did not turn it on now have a serious reason to do so, as Mike Perry, the reverse engineer from San Francisco who developed the tool, is planning to release it in two weeks."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
new security vulnerability (Score:2, Funny)
Posting an e-mail address on /.
Re: (Score:3, Interesting)
Am I missing something? Should I replace the - with a @ and make organization into
It's fscked.org from the link, so maybe just mikeperry-cm @ that?
Screw it... sent an email to everything... mikeperry-cm [at] fscked org didn't get returned... I'll assume that's it.
Re: (Score:2, Interesting)
i'm thinking cm is "contact me", so contact me via the fscked organisation
Re: (Score:2)
Re:new security vulnerability (Score:5, 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.
Parent
Re: (Score:3, 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!
yeah... (Score:2)
Re: (Score:3, Funny)
But it kinda limits your possibilities.
Re:yeah... (Score:5, Informative)
Parent
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
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)
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.
Re: (Score:2)
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:3, Insightful)
Re: (Score:2, Interesting)
Re: (Score:3, Informative)
Re: (Score:2)
Are you suggesting we should all have our own private Internets?
Easy to find out... (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.
Re:Easy to find out... (Score:5, Informative)
Parent
Re:Easy to find out... (Score:5, Informative)
Parent
Re: (Score:3, 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
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
All of my cookies are for "Any type of connection" including my bank.
Re:Easy to find out... (Score:5, Interesting)
Parent
Re:Easy to find out... (Score:5, Insightful)
I think the explanation is quite simple. "We don't know what we're doing."
Parent
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. ;)
Re: (Score:2)
Bank of America has had some explaining to do for many years now, and I ain't talkin' 'bout no websites, neither.
Re:Easy to find out... (Score:4, 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() [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.
Parent
Re: (Score:2)
I'm assuming the vulnerability comes in when deleting the secure cookies would NOT cause this behavior. Presumably it would mean that your cookie is persistent, transmitted unencoded, and open to interception/impersonation by a bad actor. That is quite a vulnerability because it would
And even moreso... (Score:2)
CookieMonster is an active tool.
It will take any OTHER connection the user makes on a wireless link, redirect THAT to point to http://yoursite.com/ [yoursite.com] answer that request with a SYN, and now the browser spits out the cookie.
WTF?!? (Score:5, Insightful)
If you are going to release a tool, just fucking do it. Give is a link and be done with it.
please tag itsatrap (Score:5, Interesting)
Why don't YOU just e-mail the guy and be done with it?!
Perhaps it's... A TRAP!
Parent
Re: (Score:3, Funny)
Please install this tool on all servers and workstations as admin for maximum benifit.
Re: (Score:2)
So ask someone who went to DEFCON for a copy.
Djagno and Secure Cookies (Score:5, Informative)
Re: (Score:2)
Because most sites don't use SSL to begin with. That said, they should at least include the line in the settings.py file, with a comment to set it to True if you use SSL.
Secure by permissioning or secure by encryption? (Score:2)
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
Re:Secure by permissioning or secure by encryption (Score:3, 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?
Re: (Score:2)
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.
How do you secure a site? (Score:4, 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.
Re:How do you secure a site? (Score:4, 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.
Parent
Webmail is broken (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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 (Score:2)
All I want for Christmas is a website that
Firefox should complain (Score:2)
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."
Security measures not used (Score:2)
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)
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.