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
...so give me your emailaddress.
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
You need to check *all* their domains. For me nothing at bankofamerica.com is secure, but onlineeast1.bankofamerica.com has at least two secure cookies and they go away when you log out.
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.
The problem is that a browser will usually send all cookies, even those which are set by a HTTPS site, over an unencrypted connection to the same server as well. That is, unless the HTTPS site instructs the browser to use the cookie only with the HTTPS site and not the HTTP site on the same server.
If you're logged in to an HTTPS site over a public wireless hotspot, then an attacker can hijack some other non-encrypted connection and modify the content to load further content from the same domain as the HTTPS site, but using the unencrypted HTTP protocol. Then your cookie from the secure connection will be sent in the clear and the attacker can log in as you. The way to fix this is to change the web server side such that it flags all cookies set over HTTPS as HTTPS-only cookies.
Way to go with the OPSEC low profile. Why don't you post your circuit's IP and URL while you're at it, big guy? My ISSM can get with yours, we have big party then.
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.
Nobody who uses Ubuntu is a slacker. Nobody.
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.
I have teens, so I'm virtualized with a twenty second revert to baseline wiping everything and bringing us to a fresh Firefox 3.01 (for me) or IE7 (wife) every time.
The embedded units besides TiVo are on NetBeui only for the TV and another for iTunes library (that one read-only) with a frequently wiped netbeui file server for the TV content. How ya gonna route that spy data over Netbeui?
Anyone keeping a real machine for surfing should realize its just a bathroom rug accumulating gunk that anyone who sat in front of the screen ever visited (even by accident).
The host under the virtual doesn't even have network connectivity.
The only real machine left in the house is my gamer and sheer theory of potential botnets are why INSIDE THE HOUSE I make damn sure the gamer IN THE LIVING ROOM is HIBERNATED before doing anything.
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
Mod parent up !
GP is going to Gitmo, fo' shitmo, my slash-dit'mo 's.
A horse can't be sick, you know, even if he wants to.
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!
I've always suspected this is how those F(r)eeCreditInfo companies kept getting new card numbers after cancelling their "service". (Which consists of being charged $20/mo for nothing and have it billed to various random sounding things that strangely start with the same routing number.) They glean your cookies with their banner ads to find transactions with other companies. Their Flash based banners even show up at many trustworthy sites. (Websites don't seem to care what's in the script if they get enough $$ for the ad.) Other than having to deal with the bank for the 3rd time, clearing the cookies and blocking all domains and IPs of such "service" and related "companies" - the problem finally stopped.
Anyhow, in hindsight it's better to pay a modest one-time fee to your bank or credit card company (usually around $10) to find your rating, than to get it up the ass for a "free" report (with a very very small print or hidden service agreement that rapes you in the long run.)
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;
}
}
}