Et tu, Gmail? Simple hack defeats last barrier to decades-old attack
Only Salesforce standing
In the morass of Web 2.0 insecurity, Gmail and other Google-hosted services stood out as a beacon of hope. That's because they were believed to be the only free destination that offered protection against a decade-old vulnerability that enabled hackers to steal sensitive authentication details as they pass over Wi-Fi hotspots and other types of public networks.
Now, we know better.
According to security researcher Rob Graham, it doesn't take much to disable the safety measure. And that, in turn, would give attackers free rein over a victim's Google account, including any email, map searches or calendar entries that happen to be housed there.
The vulnerability stems from the wide-spread use of session-IDs that websites use after visitors have successfully entered their login credentials. Typically, they come in the form of random text strings in the URL or the HTTP cookie and are sent in the clear.
That makes it a snap for bad guys hanging out at coffee shops to sniff the string and use it to masquerade as the victim. This happens even if the password is entered behind the veil of a Secure Socket Layer session, which encrypts the information so it's not decipherable to prying eyes.
Google was the only free service known to encrypt the session-ID if the user went through the trouble of putting an HTTPS in the address for Gmail and other Google services that support SSL. Visit this Google Calendar address instead of this one and no one would be able to make heads or tails of the session-ID, the thinking went.
But Graham says Google SSL will automatically revert to plain-vanilla HTML if the site believes there are connection problems. This means an attacker at a hotspot can cause Google to lower its shield simply by sending a reset packet to either the Google server or to the victim's PC.
"If companies do SSL correctly, then you're safe," Graham says. "The problem with Gmail is it's not doing SSL correctly. In my experience just using Gmail normally, I've seen this happen accidentally."
A Google spokeswoman said company security pros were looking in to Graham's research.
To be fair, Google still offers protections that Yahoo!, MySpace, Facebook and most other Web 2.0 properties do not. That's because Gmail and several other Google services that support SSL encrypt all information passed back and forth during a session. Most other websites encrypt data only during the login sequence and then quickly drop the protection once the user has been authenticated.
Among websites Graham has tested, only Salesforce.com has managed to insulate itself from this man-in-the-middle attack.
"As far as I can tell, they really have spent a lot of effort to solve problems like this," he says. ®
Dunno why you lot are struggling to work this one out... SSL offload network appliances have been around for donkey's years. Funnily enough anyone running large load balanced server farms uses this and doesn't just kick the arse out of their servers.
Oh and you also probably need to use the SSL offload devices in order to load balance any kind of application that requires session persistence anyway...
Anyway, surely the Gmail problem is resolved by having the user select in their profile if they want to use SSL or not. If they select this option then the system will never allow them to drop into unencrypted mode mid session- which is actually the problem here... hmmm that sounds quite simple...
You get what you deserve...
If you use wifi, then you get what you ask for really. I don't even use my home wifi without openvpn running over it, even though wpa2 with a complex password might be secure.
In any case it's just silly to use an unencrypted wifi connection for anything remotely sensitive. The obvious problem is that loads of people don't understand that - most of them don't even seem to realize that its a good idea to encrypt their personal wlans.
That said, I managed to use the non-ssl version of gmail at defcon 15 without getting owned. Because I routed all of my traffic through an SSL'd VPN, which was tunneled through and ssh session which was tunneled in yet another ssh session. (The ssh sessions were to deal with stupid complexities of my target network.) I then blocked every host on the local subnet except the gateway w/ ebtables. Sounds complex, but I had a nifty script. And I had no problems pushing 2mbit in both directions, even with all that encryption overhead.
Long story short, just pretend that you're at defcon whenever you switch on that wifi adaptor and you'll be safe (or safer, at least...)
Is this safer?
Now that Google has enabled IMAP, you can access your mail from a client such as Thunderbird, and use TLS/SSL - which works exceedingly well. Only problem is that it does not yet support secure authentication. So is this safe?