AT&T Glitch Connects Users To Wrong Accounts

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?"

Caching

[nOw2]

I can't say for AT&T or Facebook what happened in this case, but I have seen similar things happening with poor-quality web caching proxies.

I am specifically talking of the horror that is Microsoft's ISA server.

At a previous job at an office powered by an MSDN subscription, there were cases where users would open websites for the first time and find themselves immediately logged in as someone who had already used and logged into that site on a nearby LAN computer.

Almost certainly

[dereference]

I have no inside details on AT&T or Facebook, but what you've described is almost certainly the problem. AT&T very likely use fairly aggressive caching proxies, especially lately to help mitigate their infamous capacity issues. I'd say that what happened here is pages are being cached without proper regard for cookies. That's fine for sites that don't have custom accounts, and only use cookies for tracking various page view statistics. But Facebook (like nearly every other site in the world that requires a login) issues a cookie to identify you, once you've entered your credentials. So that cookie is how the server knows it's you, and not somebody else. If AT&T's forward caching proxies ignore this cookie, and just give you the most recent page served from Facebook, you're sure to hijack somebody else's session. And, since your first request sends your new credentials, the person you've hijacked (if still online) will now have passively hijacked your session, explaining the last scenario from TFA where sessions appeared to have been swapped.

Hardly new in end effect...

[shoppa]

The article says:

Several security experts said they had not heard of a case like this, in which the wrong person was shown a Web page whose user name and password had been entered by someone else.

But I, as a just random user of some commercial (read: mail-order, telephone company, etc.) websites have several times over the years requested information about my account and orders - and seen instead somebody else's information. In these cases the cause seems to have been non-unique cookies although that is purely a guess, maybe indeed there was some hijacking going on at the network level.

Some of these websites were supposedly "https" but some inspection of HTML source revealed this was just the frame, the actual information was frequently in non-secure inner frames. Poked around a tiny little bit and found that by altering the URL's in those frames I could see arbitrary customer's account info.

I didn't have the courage to tell anyone - after all, accessing somebody else's account information is a federal crime.

Re:Cool

[TheRaven64]

Wait, let me get this straight:

You used a connection, realised that it had a security hole that was disclosing login information to third parties, and then provided it with your login information.

Re:This makes no sense...

[Ungrounded Lightning]

How in the World can this be AT&T's fault ...

1) Alice and Bob are both logging in to facebook. They send the last message of the login at nearly the same time.
2) Facebook
3) AT&T gives Alice's cookie to Bob. (Several ways to do this.)
4) Because Bob's browser was expecting the reply with the cookie from Facebook it accepts it and continues with the login step. Except for having the wrong cookie everything is as it should be.
5) Bob's transactions are marked with Alice's cookie until he logs out, logs in again, or the session expires. He's logged in as Alice.

If you read the fine article, one of the examples is exactly that. In step 3) "Bob" and "Alice" had their replies-with-cookie swapped so they each ended logged in as the other.

Re:But... what?

[mysidia]

I doubt that. It's more likely they intercept the TCP request and pass it through a HTTP proxy farm (transparent connection hijacking)

I think many don't use NAT at all... Remember the iPhone SSH vulnerability? Can you explain how it is that jailbroken iPhones are being compromised by an SSH vulnerability, if carriers are using NAT?

The source port number field is only 16-bits: so there are only a certain number of connections that can be NAT'ed behind one IP address. Basically, 30k source ports per IP.

Whenever a TCP connection is made, a new source port is required. Also, the source port is required for the duration of 1 MSL (approximately 5 minutes) after the connection is closed. So that means, if I browse the web on my phone for 20 minutes, and visit google and 20 web sites, a minimum of 17 source port numbers will be required by my activity, after considering things like images, AJAX, multitasking, e-mail and other apps, it's more like 50 or 60 source ports needed.

So only a few hundred phones can NAT to the same IP without being at high risk of using up TCP port slots, anyways.

On carrier grade networking gear, NAT'ing is very expensive, due to the state keeping requirements, and creates new possible failure modes for their network.

Every outbound connection requires a NAT translation entry, kept for the duration of the connection, and again, a MSL after the shutdown of the socket. And then there's DNS, which generates even more translations....