Although this is an important result, I would hope (probably in vain) that no-one would be using Gmail, MSN (sorry, 'Live') etc. for business or even for personal information that they would like to be kept confidential. And especially not from a 'public' location ...

I agree with the author's claims, however this vulnerability has very little to do with WIFI. It is not a vulnerability of the 802.11 protocol, which is operating as designed.

Instead the problem is the false underlying assumption that network traffic can't be monitored or forged.

Had the WIFI been configured for WAP, this article would not have been written, however the vulnerability would still exist and possibly still be exploitable through other vectors (arp spoofing, ...).

Users should learn that in order for a channel to be secure, it must be encrypted for the entire session and not just while exchanging credentials. Compare this to a telephone snooper who doesn't hear anyone saying "hello", but can in fact hear the rest of the conversation since SSL was dropped for the remainder of the call.

> Any session that isn't protected from start to finish by SSL is

> vulnerable to the hack.

Well... yes!? Why be surprised? HTTP being stateless, session information has to be transmitted on each request. If it's unencrypted, and the session information is not locked to at least the original IP that logged in (weak, weak I know), you may be burnt.

But forwarding your http requests using a local "ssh -D" will help you in the hostile WiFi environment.

@Lou

Wifi is one of the only non-switched networks left. No-one uses hubs any more meaning network traffic sniffing is a lot harder without port mirroring or port monitoring.

Most decent WiFi setups also have wireless client separation, to stop wireless clients from talking to each other - and it should be used in public wifi locations

"If I sniff...all your cookies...I clone you". Apparently Ron Graham has just hacked Dan Ayroyd's account!

People could also read what you're typing with binoculars

I suppose this is why facebook (irritatingly) asks you to login again if you change IP address.

What I've never seen pointed out anywhere is that it's pretty straightforward to set up a blogger site that phishes your Google login when you enter a comment.

This has nothing to do with wifi, switches, ssl or anything.

It's a bog standard "man in the middle" attack and Gmail has been caught with its trousers well and truely down!

They've made the assumption that, if it's the same cookie then it's the same browser - which is patently unsupportable. The simple fix is to remember the IP address of the user's browser too. Then if the cookie is subsequently presented from a different IP bounce the user to the login page!

Of course, address-translating proxies and/or firewalls break that security, but still this smacks of a intern-level programming error at gmail.

Oh, come on, now. You're on a network with a bunch of bad-ass web 2.0 gmail-lovin' lowlifes, you do your post-login sessions in the clear on an ethernet network anyone can snaffle your cookies off (not just wifi - it's no different from being connected to a hub [not a switch which has the intelligence to segregate traffic]), the output IP address on the access point is almost certainly identical for any NATed client connected from inside, and your sessions are not safe? Neither the victim nor the mail service operator can do anything about that without a change. Duh, really. SSL isn't any good unless you validate your sessions (check issuing CA and ideally fingerprint on host cert) and that both client and server have good random number generators and agree to keep the security the whole time. Then even if the actual sessionid generation at the underlying mail service isn't very good (and most aren't because they're in part based on some predictable elements like daytime/pids/hostnames) you'll be just fine as long as your entire session doesn't reveal anything except the ciphertext noise. Of course we mustn't forget other attackables like the DNS and gateway hijacks with ARP, but for the most part SSL will save you. I use SQWebmail for my webmail and one of its more useful compile-time options is that of always sending absolute URLs to clients using the https scheme. So even if you reach the login page using an unencrypted (plain http) URL, the login form and all subsequent requests will still GET/POST using HTTPS. Very good for making memorable URLS like www.example.com/sqwebmail/ , as well as not costing you when someone breaks a security habbit. As to client separation - this is fine providing there is no reason for clients to communicate with each other (i.e. the client's only destination is the outward gateway and other infrastructural hosts like DNS), but I like to think that for efficiency's sake it's rarely necessary to turn it on in most environments - no more than it is to connect everyone in a star network because someone runs tcpdump occasionally (though that's the norm now, of course, and tcpdump helps at the gateway more than anywhere, some attacks can still trick you into talking to a node you wouldn't normally).

Cheers,

Sabahattin

@Craig Foster

"Wifi is one of the only non-switched networks left. No-one uses hubs any more meaning network traffic sniffing is a lot harder without port mirroring or port monitoring.

Most decent WiFi setups also have wireless client separation, to stop wireless clients from talking to each other - and it should be used in public wifi locations"

You really have to think more creatively about network (in)security.

You may have missed it but I already mentioned arp spoofing, which is used even on wired networks to intercept traffic even with switches in place. Also attackers could easily run their own dhcp/dns daemons with a good likelyhood of being able to forge DNS lookups. Not to mention the added potential for viruses/hacking attacks due to being on the same subnets.

People assume upstream providers won't be watching their traffic, but without encryption nothing stops them from doing so. In fact the people at these shows are probably happy plugging into any network connection they find, without even knowing who the provider may be. At these events nobody knows anyone else and have little reason to suspect anything, rogue equipment could easily go unnoticed.

So I stand behind my original statement: Plain non-SSL HTTP should never be assumed to be secure. This conclusion has nothing to do with WIFI.

Ah, I love the sound of that...

There is a reason you should use https:// for everything.

As for someone saying it doesn't have anything to do with wifi ... well it does in the sense that many people inherently trust wifi as long as their login credentials don't travel unencrypted ... now lousy web 2.0 programming + wifi sniffing has proved the contrary.

That's one of the reasons my wi-fi zone is treated as a separate, "high risk" zone. I tunnel port 3128 through SSH down to my firewall/server and use the tunnel to use the server-side proxy. That ensures *all* my traffic goes through a secure link while traveling the "secure" wifi link (even with 128-bit WEP, I don't trust that).

@Rich

The point is not just that I can read your email (I can do that by sitting next to you on the train/plane), but I can login as you and send email in your name. How about if I send some messages to OBL on your behalf ;)

@Ian

Actually Google are ahead of the field in that they at least allow you to configure your account to use HTTPS throughout (most people won't, of course).

Presumably all these webmail providers use HTTPS only on their login pages because of the overhead of using it throughout. Hopefully this will be a wakeup call. I know 3DES pretty much requires hardware acceleration to support high-volume traffic, but I understood that AES was much better in this respect. Does anyone have any real world figures for the CPU overhead of using AES - 10%, 20%, 50%??

Not really. For one, if you're logging in from a public wi-fi AP then presumably that's not your regular IP address, in which you'd have to log in again too - negating the whole point of a permanent session cookie.

Secondly, as your address would be NAT'ed to the address of the AP, anyone else on the same network would have the same public IP.

There is a solution, however, and that's to include a nonce with each cookie (a random number, not a paedophile). The server reads the nonce, confirms it was the last one it sent for that account, then creates a new nonce based on the previous one and returns it as a new cookie with each page request. This prevents replay attacks like this one.

While detecting different IP addresses isn't a bad thing to do (anything that increases security and has no downside is worth doing), it's not enough.

In this scenario someone can be on the same public Wifi network as you and hack into your account and all the requests will appear to come from the same IP because the public Wifi network will connect attached computers to the Internet via NAT. (It's unlikely to be handing out public Internet IP addresses.)

When you get home and authenticate again from there then the hacker will be blocked out of your account because your IP addresses are now different again, but they could have changed your password or read, written or deleted the data they were interested in by then.

IMO it's just another example of why applications should not be in web browsers. Browsers are document viewers. They weren't designed to run stateful applications and every attempt to do so results in horrible usability issues which sometimes lead to security issues when people try to work around them.

Sorry, couldn't resist...

Lucky I'm still using Web 1.0 technologies such as HTML 3.2, with no Javascript and no CSS. I must be the safest person in the world. It was a good choice not to jump on the Web 2.0 boat. Take that suckers!

This technique to gain access to someones session has been around for aaages! I just guessed the fact it worked with Gmail was common knowledge (it's not hard to notice that the secured indicator in a browser disappears after login). Why the big fuss?

The site monitoring a change in your IP address wouldn't help in this case: If you're connecting through the same router, you're likely using NAT, as such, someone logging in through the same router will have the same external IP.

This is just my 2 cents, but I would be inclined to think, that once the SSL session has been established, it would be easier to simply issue a new session ID. So long as it is transmitted within the SSL session, it is safe from interception (unless the SSL session itself is compromised, in which case session hijacking is the least of your worries). Granted, there is still a window during which the cookie is vulnerable, but it is significantly shortened.

Yes, address-translating proxies do break that security: the sort employed by a number of very large and very popular ISPs; invariably a customer's site-facing IP address changes when you go from http to https and vice versa, which rather breaks the whole model.

So, Google could avoid it by tying cookies to IP addresses, but it would prevent a great many people from using Gmail. It would also be completely ineffective in preventing the attack demonstrated here, because most public wifi networks use NAT at the Internet gateway point and so your IP and the attacker's IP will be identical.

They could use SSL for the whole session, which would neatly avoid the problem, but that would make things incredibly slow, and IE6—still (just) the most popular browser on the planet—has all manner of irritating little SSL bugs which would cause Gmail to break for lots of people at random instances, both of which amount to the reason why many web developers avoid prolonging SSL sessions for longer than they have to.

IP address checks don't work for this kind of thing- if I'm logging in from my local pretentious coffee shop I'll almost certainly be going through their gateway so I'll be coming from the same IP address as anyone else on their local Wifi network. Assuming that's where the hijacker is then the problem persists.

Also some ISPs, notably AOL, tend to switch IP address on every request - you would consequently be excluding all of their users from the service.

... and give those who register a client certificate?

That avoids the holes in IP address checking.

It's not too hard to carry your personal certs on a USB stick to use wherever you need them.

Still, the problem is really that GMail doesn't use SSL end-to-end - surely the old worry about the speed of encrypted sites is hardly relevant with modern compute power.

There are many sites out there (I would list any where credentials are handed over SSL and then passed back through unencrypted channels) where this attack vector would exist ... and it's certainly not new. This has been around for many, many years.

Personally I use more than the session id for authentication where I can on repeat requests (specifically the remote IP address), but with the more prevalent use of NAT in large offices and on open WIFI networks (and the potential harder angle of spoofing) this has become less effective. Roll on IPv6!

I have been a long time advocate for anything where you need to login (and want to ensure your account is safe) being executed over SSL for the entirety of the visit.

But in the example given wont they always be behind a NAT device of some sort? With access to the same one as you?

Sure someone upstream (at your ISP) could be doing it... but the contents of email tends to only be of value to people that directly know you and hence will be in your vicinity. (Obviously not always).

Your example is just adding in more obscurity to try and achieve secturity... thats not good practise.

But in the example given wont they always be behind a NAT device of some sort? With access to the same one as you?

Sure someone upstream (at your ISP) could be doing it... but the contents of email tends to only be of value to people that directly know you and hence will be in your vicinity. (Obviously not always).

Your example is just adding in more obscurity to try and achieve secturity... thats not good practise.

Is the problem that gmail is dropping the https connection after you login... so once you've signed in your cookies are sent in plain text?

Well if you go to https://mail.google.com/mail/ (note the https), then it keeps your session encrypted the whole time your logged in... so your cookies should be safe?

I do this at work currently anyway to stop the boss from getting my mail in plain text going through the proxy. I know mail is later sent in plain text across the internet but I dont care to much about people upstream reading my email, just people that know me.

To be honest if your competent enough at hacking to get someones cookies in this way your going to be competent enough to spoof there IP address. Particularly seen as google would probably say "You were last logged on with IP Address: x.x.x.x"

Chris

The real error here is either that the session-identifier is sent over HTTP before the HTTPS connection is established, or that the server even accepted a HTTP connection at all.

If a session-identifier is really needed before an SSL connection is negotiated, it's still only ever required once. Any attempt to re-use it should bring up an appropriate warning message (there's a chance that the bad guy might have got in there before the good guy).

@Ian Rogers: You can't rely on a user's IP address remaining the same throughout a session. Most of the cheap ISPs use DHCP to allocate an IP address, and it's not impossible for the lease to expire mid-session. Some ISPs (*cough* AOL *cough*) even use a bank of transparent proxy servers, with successive requests being routed through different proxies.

I'm confused - I thought this was meant to be something new. Basically he's taken cookie stealing (like we used to years ago with Javascript until webmail and forums started blocking it), crossed it with WiFi sniffing and now it's bleeding edge?

Did I miss something?

Cookies have always been a weak point in web based authorisation. If you drop down to HTTP from HTTPS after login you can expect them to remain so.

Don't get me wrong, it's always nice to see PoC but it's not anything earth shattering.

Why isn't all WiFi traffic between the access point and client encrypted as part of the protocol? Surely that negates all problems of running a non-switched network.

Unsecured connections are insecure - why is this news?

If you are using a session cookie outside of a secure connection then include an encrypted timestamp and nonce. If you get the same timestamp and nonce more than once for the same session ID then reject it. If the timestamp is outside an X minute window then reject it.

Strictly speaking, if the clock resolution is fine enough then the nonce isn't needed but it does make it harder to crack the encryption.

Or am I missing something?

Even these days when everybody with some technical knowlege can see the vulnerabilites, large modern companies who really should know better are still opening their systems (i.e. us) up to casual hackers who don't need much technical ability.

We can argue the fact that Graham is getting some credit for something which a schoolkid with a laptop and an Internet connection could do after half an hour of googling, but that's not his fault, he's not clever, the website providers are stupid.

The 'big win' is for all providers of a service which should be private to run https:// instead of http:// from log in to log out. Then certificate security becomes the next vulnerbility (don't use a PC that could have been compromised, never ignore certificate warnings, don't accept a new CA cert into your browser etc.)

A wider question is 'Who should be responsible for security?' yes, gmail can be https:// log in to log out so why not make it the default? Yes, there will be a cost in performance, the providers will need to invest more, and the user may notice a 10% hit, and there may be other browser warnings when mixing secure and non secure content, there's a difference between a taking choice away and people not understanding there's a risk if they don't use https://

I personally can't believe that people will use public PCs to do secure things such as paying bills, but that's starting to get off topic.

Kinda defeats half the point of signing in with SSL eh...

Lucky I'm still so Web0.5 that I host my own email, www, ftp...

If you use POP3 with SSL, it's encrypted from the beginning. And the good news is that once you download the message to your own machine, you can (and should) delete it from the server. HOWEVER, how many sites use SSL?

Gotta wonder, do the RNC and DNC even encrypt their email servers? Or traffic? That would be a fun attack.

This was brought up at least two years ago as possible and a reason not to use gmail in that fashion anyway I don't like gmail (nothing to do with security I just don't like the interface) but if you think about it your asking for it if you don't pay attention when security minded people point out a new service is vulnerable. Of course none of this means anything if your email is being forked over to outside parties by the service so none of them are safe and people that work there can always read them nothing email is private get used to it.

It should be noted that the majority of websites DO actually check that the IP address the cookie is being used from is the same that the login came from.

Although lots of companies use banks of proxy servers there is usually some session affinity to ensure that once you access a certain website your requests always come from the same proxy/cache. I have personal experience at one of my clients sites where they tried to load balance the internet connectivity across multiple DSL connections and requests would come from different IP's all the time, this broke pretty much all websites that required logins until the session affinity feature was switched on.

Although this attack is a vulnerability I think it's very insignificant in that it would be very time consuming to do, with little to no interesting/significant win for the hacker 99% of the time.

For the last year I've been sending everything through an SSH tunnel with a http proxy on the other end when using public WiFi. Ensures end-to-end encryption. While I know there's probably *some* way to compromise even this, it's much more secure than just relying on SSL.

If you have any access to an SSH server connected to a proxy, I strongly recommend this method.