AT&T Glitch Connects Users To Wrong Accounts 138
CAE guy writes "The Boston Globe is carrying an AP report which begins: 'A Georgia mother and her two daughters logged onto Facebook from mobile phones last weekend and wound up in a startling place: strangers' accounts with full access to troves of private information. The glitch — the result of a routing problem at the family's wireless carrier, AT&T — revealed a little known security flaw with far reaching implications for everyone on the Internet, not just Facebook users.' Who needs to worry about man-in-the-middle attacks when your service provider will hijack your session for you?"
Good thing that Gmail is all https now (Score:5, Insightful)
Probably will take Yahoo only another 15 years to catch up. Wish all other services with even a small chance of transmitting private data would do the same. Even if they charged for it (i.e. a premium account).
Re:But... what? (Score:4, Insightful)
Re:But... what? (Score:5, Insightful)
I don't know how Facebook does it specifically, but many sites will give the user a session cookie after entering his/her username and password. All further requests use that session cookie to identify the user. It sounds like a proxy at AT&T served a cached response belonging to someone else and that included a session cookie that was still valid (not logged out or expired).
It may be a bug in the proxy or a bug in the HTTP headers set by Facebook that instruct how a response should be cached. It does show that it is a good idea to use HTTPS when accessing private data, not just for banking. If the site does not offer HTTPS, it is good practice to log out when you're done, so that the server will invalidate the session cookie.
Re:But... what? (Score:4, Insightful)
That's my thought... but I still don't see how things like this get "crossed". Even if your IP address got switched with another during a request, at most I would expect you to wind up is receiving one page. When you load the next page, or make the next AJAX request, you wouldn't have the session cookie and it would kick you back to the login screen.
Unless of course Facebook sends the auth cookie in every response, or the "wires" got crossed just when the other person was making a login request.
Re:Good thing that Gmail is all https now (Score:3, Insightful)
Perhaps, one good thing about it being standardized is that if I send to someone on that service, I also know if's a bit more secure. (Although, if you're telling secrets to another human, there really isn't any hope of it staying one...)
Re:But... what? (Score:5, Insightful)
What is almost certainly happening is that AT&T is using a proxy which implements HTTP Pipelining, but is screwing up and not correctly pairing the requests/responses from different sessions. It's probably just more likely to happen on a site like Facebook where many many users on the same proxy are going to the same non HTTPS site...
CLEARLY a web proxy problem... (Score:4, Insightful)
On the IP layer, this wouldn't happen, because there are cookies contained in the web traffic that are used to route things on the Facebook end, simply because there are NATS and the like.
Thus the problem is whatever in-path HTTP proxy AT&T is using for their phones that crossed things over.
In-path HTTP proxies and caches can be very hard to find and may produce all sorts of interesting subtle problems when there are bugs in them.
Re:But... what? (Score:3, Insightful)
If the site does not offer HTTPS, it is good practice to assume the information you store there is not secure.
Fixed that for you. Data sent in the clear is not secure.
From this we can make another logical step: Therefore this is not a security issue. Data which is not secure cannot have a security issue. It is already public.
There are still a lot of bad caches... (Score:3, Insightful)
Bad in-path caches are something we specifically check for on Netalyzr. Its suprising the number of BAD in-path caches still exist, which cache data that the HTTP server said "for the love of god, don't cache".
More, what has happened is that bandwidth has gotten cheap, so fewer people are DOING caches, and when they are caching, its more likely for latency not bandwidth savings (eg, we see a lot of caching for users from South Africa).
Re:Technical details please! (Score:1, Insightful)
The article is poorly written and obviously is a hearsay of technical information loosely translated into something people might read.
The description of the potential scope of the problem (all of the internet, everybody, all of the time) is laughable. Of course if I get a flat tire from a nail, and if nails are used everywhere, then everyone's tires are at risk from nails all of the time. And we should all stay home. Better to find out why that nail was there and if there is someone dropping nails on the road.
Sounds like a bad session cookie, either at Facebook server or loadbalancer. Or perhaps some network cache/proxy that keeps session info. If it was a TCP connection that an IP router went bonkers on then a lot of other session things would go wrong too and packets would drop. Its a complex world we live in so there is always the possibility that something weird and not so wonderful happened.
er.. awaiting better information
Re:But... what? (Score:4, Insightful)
No, it still doesn't make any sense. If you made a port 80 request to the web site, your phone has to pick a SOURCE PORT to establish the TCP socket.
Someone else requesting a page would have a different Source IP Address and a different source port.
So if you suddenly got their IP address, your phone's TCP stack should drop the packet.
Something is amiss... I think they're intercepting your request with a transparent HTTP proxy (or something like that), and a bug in the proxy server sent the response to the wrong user.
Oh, and by the way.. how session cookies work.... a new cookie gets sent to the browser with every HTTP request, most likely, to extend their session (e.g. time-out idle period extended by issuing a new cookie).
Re:HTTPS won't necessarily fix this! (Score:1, Insightful)