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?

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

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

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

[XPeter]

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