Slashdot Mirror
Point-and-Click Gmail Hacking Shown at Black Hat
not5150 writes "Using Gmail or most other webmail programs over an unsecured access point just got a bit more dangerous. At Black Hat Robert Graham, CEO of errata security, showed how to capture and clone session cookies very quickly over connections without encryption. He even hijacked a shocked attendee's Gmail account in the middle of his presentation. 'While Ou was typing, Graham was running Ferret and sniffing all the cookies that were being sent from Ou's laptop and Google. Graham then clicked on Ou's IP address and Gmail page, complete with Ou's recently sent message on the screen. We photographed both Graham's and Ou's laptop at that time and posted it to the picture gallery. You'll see that the contents are exactly the same.'"
Somebody intercepted plaintext on an open network . . . . did I miss something?
Your hair look like poop, Bob! - Wanker.
This is shameful. It's 2007, Google. SSL has been a (reasonable) standard since 1996. USE IT.
The Firefox extension forces GMail to always run over SSL. It's great!
Apple has nothing at all to do with it.
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid. The only situation where this solution may get a bit annoying is if you're behind a load-balancing proxy, which changes your IP address on every request (fortunately, this is somewhat rare.) It's better than allow easy hijacks...
They offer it. All you have to do is go to https://mail.google.com/ rather than http://mail.google.com./
I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I think the upshot of this isn't really "look at us, we can sniff plaintext Wifi connections," but "look at one of the biggest players in web mail use plaintext connections even though they ought to know it's a hideously bad idea."
It's more of an indictment of Google than anything, because they default to unencrypted HTTP rather than HTTPS, and most users won't know that they can go to https://mail.google.com/mail/ to force smarter behavior.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
A huge part of security is having sane defaults. If you support 'secure' and 'insecure' you should default to 'secure,' and let users who know what they are doing, and need 'insecure' behaviour opt into it. You shouldn't default to 'insecure' and make it the users' responsibility to select 'secure.'
I am TheRaven on Soylent News
Although they don't have a public key scheme strong enough for the AES-256 (requires 15360-bit RSA or 256-bit ECC for public key), you should always be logging in using https://gmail.google.com/ from all locations (even home) to ensure the entire session is encrypted.
In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.
I agree with the latter recommendation about using SSL, but saying 'secure your wireless AP' doesn't do a lot to help the many public wifi locations; I think it's unhealthy to ever assume that a wireless connection will be secure. As more wireless networks are rolled out, and more people get laptops with built-in wireless and traipse happily from home to their local coffeeshop, where they're sharing an IP and an unencrypted connection with many untrusted users, opportunities for sniffing and hijacking are only going to become more common.
As users demand more portability, security and authentication need to be moved (and kept) up at the application layer, and not simply assumed as part of the datalink or physical layers.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
We have redirects setup on all plain-text channels that have a login to SSL, and have for the past 6 years; this is beyond common-sense.
Website Hosting
You're right that the exploit itself really isn't that new. What's new is twofold:
1) It's being done to Gmail, a service provided by People Who Should Know Better.
2) There is now a tool that allows any script kiddie to do it, meaning that it's no longer a theoretical exploit; it's something that your next-door neighbor is going to be doing to you (or your slightly less-technically-savvy family/friends) if you don't take precautions.
#2 is probably most significant, since it's really what's going to cause #1 to change. Sometimes, producing a GUIed, Windows-based exploit tool is the fastest way to get a problem fixed, because it's the easiest way to turn an academic argument into a real-world security issue that will get resources thrown at it. (Of course, it may also land you in jail.)
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
They shouldn't tell anyone, just transparently redirect to the secure URL. Sane defaults, and all that jazz. Or at least semi-transparently, with a "redirecting..." page that has a link to both encrypted and unencrypted login URLs, in case some network blocks https.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
correct me if I'm wrong, but don't most who complain about microsoft OSes point to prior defaults to administrator privileges as a major security concern? If so, by that same reasoning, shouldn't web services default to more secure configurations as opposed to less?
un burrito me trampeó.
Maybe not, but the heavenly smell is basically a SSID broadcast of their existance to those interested in finding them.
More Twoson than Cupertino
Even if there are others with the same problem doesn't give you excuse to ignore the problem.
-- Reality checks don't bounce.
Well, I suspect that the reason they don't serve GMail access over SSL by default is greed and/or the desire to be "green". Serving web content over SSL put significantly higher strain on servers. In Google's case this equates to more CPU cycles and that translates to higher power requirements. More power means higher costs for Google and more carbon emissions into Earth's atmosphere. I would like to believe that "do-no-evil" Google is doing this for the latter reason.
Bookmark the secure address and use that (who wouldn't over open wireless??). You could also use http://www.customizegoogle.com/ with Firefox if you're using Gmail to force it to go to the secure URL.
I have never heard of anyone thanking God that they use Yahoo... in my entire life.
It's not Google's fault -- gmail is still in beta! :)
That's dumb. An application should never assume that the network it's connected to is secure. It doesn't matter whether you're plugged into switched Ethernet, a wireless LAN, or IP over carrier pigeon -- if you're designing an application that's going to transmit sensitive/assumed-private data (which email clearly is), it's a mistake to just blithely assume that the network is in any way secure.*
An application like Gmail should be treating all network connections as though they're unencrypted Wifi (or hubbed/shared-media Ethernet -- let's not call out 802.11 when there are so many other networking options that can also be trivially compromised); anything else is bad design.
* I'm aware that SMTP is designed like that (as are many other core Internet protocols), but that doesn't mean it's a good idea or even close to technically correct; it was designed in kinder, gentler, and clearly more naive time, and it's caused a whole lot of pain as a result. To do the same thing today is pretty ridiculous.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
# This is how I did it: ..... mostly. /var/www/ /var/www/> /insecure/
.....
#
# Actual snippet from my Apache configuration
# Some details have been changed to protect the innocent
# And some details have been changed to protect the guilty
#
# The virtual host "secure.mydomain.co.uk" cannot be accessed
# by http; only by https.
#
# The insecure port
<VirtualHost 10.11.12.13:80>
ServerName secure.mydomain.co.uk
DocumentRoot
<Directory
RedirectMatch ^/[^iI]
# In this directory is a page with a dire warning
# that https is required to access this server.
# NB. To avoid creating an infinite loop, we never
# redirect if request begins with I or i.
</Directory>
</VirtualHost>
# The secure port
<VirtualHost 10.11.12.13:443>
SSLEngine on
</VirtualHost>
Je fume. Tu fumes. Nous fûmes!
I use the Gmail Notifier firefox extension which checks for messages and forces gmail to use secure connections.
We have the best government that money can buy.
The point is, security is more than just "what's available." It also has to be about how good the defaults are. The technical community cried foul when Microsoft included a firewall in Windows XP but didn't have it turned on by default, and we complained so much that in SP2 Microsoft finally changed the default.
I agree that security is ultimately the responsibility of the user, but they should not have to seek out secure settings and turn them all on one by one. The default mode for any network-enabled program should be Secure. If the user needs Insecure, then they should have to change a setting to make it so. Spam should be opt-in, security should be opt-out. Anything else is unfair to the user.
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.