Slashdot Mirror
HTTPS Cookie Hijacking Not Just For Gmail
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."
Posting an e-mail address on /.
...see this is why the military has an entirely physically separate internet for the Really Important Shit(tm).
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
Comment removed based on user account deletion
If you are going to release a tool, just fucking do it. Give is a link and be done with it.
Why don't YOU just e-mail the guy and be done with it?!
Perhaps it's... A TRAP!
Comment removed based on user account deletion
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.
Comment removed based on user account deletion
fscked.org got fscked by getting slashdotted
Persian Project Management Software as a Service
Comment removed based on user account deletion
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 decrypted by the web server.
Perhaps a combination of both approaches would yield the most secure cookie system.
You see? You see? Your stupid minds! Stupid! Stupid!
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
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 ) and a stored XSS attack can completely compromise your session.
Forgetting about XSS, there's still CSRF, injections, RFI, information leakage, broken authentication/session management, insecure url access, etc.
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. There will always be fewer places to attack and thus the chances of your email being compromised are just smaller.
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.
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.
You see? You see? Your stupid minds! Stupid! Stupid!
Google Cache
/. can't bring to it's knees.
All I want for Christmas is a website that
I am Bennett Haselton! I am Bennett Haselton!
Yodlee MoneyCenter passes the test, and appears secure. However, my own personal online banking institution did not fare so well. Argh!
God look at me, I'm just a man, but you tell me I'm not just a man, so hard to understand, after all, I'm just a man.
Comment removed based on user account deletion
Using the method outlined in the post, I can't find any sites that I have cookies for that aren't vulnerable.
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."
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/ answer that request with a SYN, and now the browser spits out the cookie.
Test your net with Netalyzr
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.
Yeah I'm the first person to ever say "I'm in the military and we have this thing called SIPR and here's a public link to the wiki."
And I'm probably also the first say "We can convert sat feeds to digital signal. DONT TELL THE COMMIES!"
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."
Joe Dougherty, Florida, USA
The words I thought I brought, I left behind. So, never mind.
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)
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.
--
E_NOSIG
(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.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
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 does not prevent anyone else from sending the same secret message. I don't have to be able to decrypt the secret cookie to snoop, copy, then send the secret cookie.
One's next inclination may be to find a way to make sure that others can't send the same secret cookie. Perhaps some kind of authentication. I think things start to get a little complex this way. Why not just have the site serve the cookie with "Secure;" in the string?
Whenever a cookie is set over a secured HTTPS connection, NoScript forcibly flags it as "Secure" even if the server didn't. Therefore the browser won't leak it anymore over insecure connections.
Obviously this feature works always as long as it's turned on, independently from JavaScript/Java/Flash/Plugins permissions.
There's a browser safer than Firefox, it is Firefox, with NoScript
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.
.net site. I've left cookies unsecure when browsing localhost so Visual Studio debugging and "view in browser" will still work.
// set all cookies to secure
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
protected void Application_EndRequest(Object sender, EventArgs e)
{
if (Request.Url.Host != "localhost" && Response.Cookies.Count > 0)
{
foreach (string s in Response.Cookies.AllKeys)
{
Response.Cookies[s].Secure = true;
}
}
}