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

Comments

But... what?

[i_ate_god]

Facebook login information is stored on the phone, is it not?

Re:But... what?

[nate_in_ME]

I'm guessing what happened in this case is that AT&T had other users who had logged into their Facebook accounts as well, and after logging in, the wires essentially got crossed, and the wrong Facebook data got sent to each handset.

Re:But... what?

[MtHuurne]

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?

[bondsbw]

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:But... what?

[something_wicked_thi]

Yes, but typically, the way you log in to one of these services requires that you have cookies enabled. There's a cookie in your local browser that has information derived from your password. For example, imagine facebook stores your password in its database as a sha1 hash of a salt and your password. E.g. the entry facebook has stored might look like this:

salt = string(rand64())
password_hash = sha1(salt + password)

Now, to authenticate, you send facebook your password and they use the saved salt to see if it matches the stored sha1 hash. What they send you back would be a token to put into your cookie like this:

token = (date, username, sha1(password_hash + date))

Now, they make the token good only for a certain amount of time after the date. Say three hours. When facebook gets another request, it checks to see if the token is valid by comparing the date and username and then looking up the password hash for that username. It then recomputes the sha1 hash in the token to make sure it's valid.

Using this model, it's completely impossible to log in to another account by "switching the wires". You can log in to an account simply by stealing the cookie, but that grants you log in access for only a single session.

Re:But... what?

[mother_reincarnated]

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...

Re:But... what?

[samkass]

My guess is that it's as simple as this: the http returned by a request to "www.facebook.com" was cached by AT&T and delivered to other users who attempted to fetch that URL in an attempt to save bandwidth. The login credentials are irrelevant... once AT&T cached the page it thought of as "www.facebook.com" it would deliver it to anyone who asked for that URL. It probably only changed for the next person because someone insisted on logging out and back in, and the caching server detected the change then re-cached the NEW user's page.

This used to happen a lot on the internet to unencrypted streams that allowed log-ins. These days most caching servers are properly configured, but it's still an easy mistake to make if you're setting up a caching proxy.

Re:But... what?

[Bob9113]

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.

Re:But... what?

[coolgeek]

Apparently not.

Re:But... what?

[mysidia]

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:But... what?

[jc42]

Putting the IP address in the session cookie is a recipe for disaster considering how widespread NAT, dynamic IPs, and proxies are.

Some recent testing of web sites on the iPhone and G1 phone have also shown that using the client's IP address as part of the "session" information simply doesn't work. With both of these phones, successive HTTP requests from a single phone often come from different IP addresses. In the tests I did, the set of IP addresses was small (2 to 4), and I suspect that it might have something to do with being in contact with several cell towers. The phones appear to be "NATted" behind several different addresses. So from the client's viewpoint, a session that depends on the IP address appears to work intermittently.

It's yet another argument in favor of IPv6, except that the phone companies and ISPs don't seem to be at all interested in going that way.

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....

How half of all customer support calls begin

[jarocho]

Quote from the article:

"I thought it was the phone -- 'Maybe this phone is just weird and does magical, horrible things and I have to get rid of it...'"

the american response

[anonieuweling]

should be:

SUE the hell out of them.

Good thing that Gmail is all https now

[rolfwind]

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:Good thing that Gmail is all https now

[XPeter]

Gmail has supported HTTPS since it's release, only now are they making it standardized.

Re:Good thing that Gmail is all https now

[rolfwind]

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...)

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.

The feeling is mutual

[lildogie]

She ought to consider how the phone is probably feeling the same way about its user.

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.

CLEARLY a web proxy problem...

[nweaver]

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: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.

There are still a lot of bad caches...

[nweaver]

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: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.