Forgot your password?
typodupeerror
Security Communications Technology

AT&T Glitch Connects Users To Wrong Accounts 138

Posted by Soulskill
from the reach-out-and-touch-some-one-at-random dept.
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?"
This discussion has been archived. No new comments can be posted.

AT&T Glitch Connects Users To Wrong Accounts

Comments Filter:
  • But... what? (Score:3, Informative)

    by i_ate_god (899684) on Saturday January 16, 2010 @10:04AM (#30790330) Homepage

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

    • Re:But... what? (Score:4, Insightful)

      by nate_in_ME (1281156) <me@YEATSnatesmith.me minus poet> on Saturday January 16, 2010 @10:18AM (#30790430)
      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? (Score:4, Insightful)

        by bondsbw (888959) on Saturday January 16, 2010 @10:32AM (#30790512)

        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? (Score:4, Insightful)

          by mysidia (191772) on Saturday January 16, 2010 @03:21PM (#30792780)

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

      • It's really not that unusual. If you log in at amazon.com (or lots of other places) you see the "logged in as $name", and right near that a link that says, "not $name? log out". I remember once I went to some site and was logged in as someone else, but that was back in 1998...
        • by richlv (778496)

          that's actually something completely different - it's meant for cases when somebody else has logged in using the same browser before (and thus cookies claim that person is still logged in)

          • Perhaps, but the one time it happened to me it was on a computer to which only I had physical access.
            • Re: (Score:3, Funny)

              by coolgeek (140561)

              Apparently not.

            • "Perhaps, but the one time it happened to me it was on a computer to which only I had physical access."

              Information gets out, and people get access to information in ways of which you may be unaware. For example, based on your post I have determined the name of the OS you run!

      • Re:But... what? (Score:5, Informative)

        by something_wicked_thi (918168) on Saturday January 16, 2010 @10:35AM (#30790536)

        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.

        • It depends on what they mean by 'switching the wires'. There's nothing magic about cookies. They are just short strings that are sent with every HTTP request and response. A misconfigured HTTP proxy may forget to take them into account or ignore the nocache commands, so when you got to a URL you get back whatever the last person saw, irrespective of the fact that the cookie is different.

          That's why you use end-to-end encryption for anything that contains personal information.

          • The "magic" about cookies is that they are stored in your browser. Therefore, once you've got your cookie, no amount of "wire switching" is going to give that cookie to someone else.

            What could happen is that the response to the login session goes to the wrong browser, but that seems a lot less likely since you'd need two sessions logging in simultaneously.

            Yes, it's possible that it's a cache control header being ignored by a proxy, in which case the site would most likely be read-only.

            • Replying to myself:

              It seems that maybe it is that unlikely scenario. If you go to the second page of TFA:

              The Sawyers experienced a different glitch. Coe said an investigation points to a "misdirected cookie." A cookie is a file some Web sites place on computers to store identifying information -- including the user name that Facebook members would enter to access their pages. Coe said technicians couldn't figure out how the cookie had been routed to the wrong phone, leading it into the wrong Facebook accoun

              • by coolgeek (140561)

                A misconfigured proxy server (or web application with a front-end proxy that doesn't setup the Cache-Control header properly, for that matter) will store the cookies that were sent by the application server, and send copies of the same cookies along to the next requestor.

                So, you go to the page http://facebook.com/profile [facebook.com] (for example, I'm not a fb user), your browser sends your cookie because you logged in yesterday, the application server sends the cookie back in the response. Then I come along, not logge

                • by welsh git (705097)

                  errr, proxies cache content, not the headers. Under your scenario, yeah, someone could receive someone elses "page" but they would NEVER get the cookie, so your POSTS would still fail

        • There's a cookie in your local browser that has information derived from your password.

          Why would the cookie have to be derived from your password? Isn't that generally a bad idea? I thought most web sites generated a completely random token for your cookie when you log in. On their end, they associate that random token with an authenticated session. They don't need the user to have any actual information in the cookie, just a unique ID that they can use to look up data on their end.

          • A strong hash of your password is, for all intents, random. The point of a hash is that it's very hard to go from the hash back to the input string to the hash.

            • A strong hash of your password is, for all intents, random. The point of a hash is that it's very hard to go from the hash back to the input string to the hash.

              But if what you're looking for is randomness why not just go out and get an actual random number? There's no reason to directly tie it to the password at all. All you're doing is opening yourself up to offline dictionary attacks and rainbow table lookups if someone gets a hold of the cookie, and hashes are being shown all the time to have various def

          • by coolgeek (140561)

            Yes, it is a generally bad idea. The use of any constant or predictable value in a cookie used for maintaining a session is a bad idea. You want the value to rotate periodically to a new value to defend against someone copying cookies off of another person's computer.

      • Re:But... what? (Score:5, Insightful)

        by mother_reincarnated (1099781) on Saturday January 16, 2010 @10:42AM (#30790610)

        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? (Score:5, Informative)

        by samkass (174571) on Saturday January 16, 2010 @10:45AM (#30790622) Homepage Journal

        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.

        • 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:But... what? (Score:5, Insightful)

      by MtHuurne (602934) on Saturday January 16, 2010 @10:31AM (#30790508) Homepage

      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.

      • Almost certainly (Score:3, Interesting)

        by dereference (875531)
        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
      • Re: (Score:3, Insightful)

        by Bob9113 (14996)

        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.

        • It's true that the HTTPS protocol would have prevented this, but it can only prevent this type of activity within the https connection! There's no reason why AT&T wouldn't have the phones set up to use an HTTPS proxy - meaning that the connection between the phone and the proxy is like any other http proxy, and the proxy server then initiates the HTTPS connection!

          Take a look in your browser settings for "HTTPS proxy", virtually all browsers support this type of behavior, and if AT&T was "aggressivel

          • by Bob9113 (14996)

            Using an untrusted proxy (and I assume you don't trust some third party corporation whose contract with you essentially says "all your base are belong to us") to handle your SSL connections is the same as not using SSL.

          • by welsh git (705097)

            I'm not disagreeing with what you say, but pointing out that everything on facebook is public anyway.

            In less you specifically set it, everything is visible to your 'friends' and this also means any application your friends have used... all those piddly quizzes etc. that people run once, and never de-authorise, have virtually as much information to stuff as that person does itself.

            That includes photos, and notes and everything else.

            If you use facebook, go to settings -> application settings and look at ho

    • by zten (576209)
      I've used m.facebook.com on AT&T across different phones while using my account's SIM card without having to log in again.
  • by Anonymous Coward

    It's a feature, NOT a flaw.

  • by jarocho (1617799) on Saturday January 16, 2010 @10:10AM (#30790374)
    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...'"
  • by anonieuweling (536832) on Saturday January 16, 2010 @10:15AM (#30790406)
    should be:

    SUE the hell out of them.
  • by rolfwind (528248) on Saturday January 16, 2010 @10:18AM (#30790426)

    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: (Score:2, Informative)

      by XPeter (1429763)

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

      • Re: (Score:3, Insightful)

        by rolfwind (528248)

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

        • by XPeter (1429763)

          (Although, if you're telling secrets to another human, there really isn't any hope of it staying one...)

          Score:5, Truth.

        • by coolgeek (140561)

          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.

          Except you're suggesting a browser-based email service, so all bets are off once the next browser vulnerability is discovered.

      • by tsa (15680)

        its

        • something that I was wondering about for a long ti... hey! Why am I suddenly finishing this sentence under someone else's account? I'm tsa dammit! Who the hell is The Wild Norseman anyway?!?

    • Seems to me that the only reason https has not become more widespread already is the computational load it places on web servers and browsers, due to the encryption. Given that even mobile devices now have more CPU horsepower than a desktop system from the early days of the Web, it is high time that we move anything that involves even marginally sensitive data to a secure protocol.
      • Given that even mobile devices now have more CPU horsepower than a desktop system from the early days of the Web...

        True, but don't forget that an iPhone can only do one... thing... at... a... time.
  • Reading the article's comments (Ya, I know ban me for RTFA lol) the issue appears to be quite widespread, and possibly on Facebook's end. They appear to not sue encryption once you log in, so that is definitely a weakness there. But that "costs" more bandwidth... but if Google can do it and switch to HTTPS... but of course this is email, not public humiliation we are talking about here.

    • He readily admits to reading the article! Not only the article, but even the comments! We can't have that on Slashdot - we've got to nip this in the bud.

  • Did the session IDs get crossed? This is the only thing I can think of: that the cookie got sent to the wrong handsets, perhaps because they were logging in simultaneously. This would be very worrisome if it were true, as it would not apply to other sites besides facebook, e.g. banking sites.

    However, I'm wondering if it may be a problem with the Facebook login system. Perhaps there is something wrong with how they identify a browser who is currently logging in, and they confused handsets on the carrier (
    • Correction, first paragraph should end with "as it would apply to other sites besides facebook, e.g. banking sites."
    • Re: (Score:1, Insightful)

      by Anonymous Coward

      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

  • Caching (Score:5, Interesting)

    by nOw2 (1531357) on Saturday January 16, 2010 @10:38AM (#30790574)

    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.

  • This happened to me in Virgina a few weeks back. AT&T is my service provider. Promptly logged out so I could get onto mine.
    • Re: (Score:3, Interesting)

      by TheRaven64 (641858)

      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.

  • Might have been a NAT problem on ATT's WAP gateway.

  • by shoppa (464619) on Saturday January 16, 2010 @11:03AM (#30790734)

    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.

    • by jc42 (318812)

      Several security experts said they had not heard of a case like this, ...

      But I, as a just random user of some commercial ... websites have several times over the years requested information about my account and orders - and seen instead somebody else's information. ... I didn't have the courage to tell anyone - after all, accessing somebody else's account information is a federal crime.

      And here we have a nice summary of how the legal (and political) system gets it all wrong. They often set up laws that pun

  • In the pre-LAN days of the 1980s we used to use terminal servers to connect dumb terminals to the computers. Their purpose was to dish our point-to-point connections on demand.

    Once in a while, perhaps due to a power glitch, the terminal servers would drop all connections and then immediately reconnect everyone at random. Users abruptly found themselves in the middle of someone else's session.

    Old technology or new, connection errors are bound to happen once in a while.

    The true risk here is misplaced conf

  • by nweaver (113078) on Saturday January 16, 2010 @11:09AM (#30790754) Homepage

    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.

  • I have an iPhone with the facebook app with t-mobile. After updating to the newest version, I keep getting notifications for other people. I let facebook know but didn't get a reply. Is anyone else having this problem?
  • Really now? And people are just now realizing this?

  • This is sheer incompetence IMO. It is sad to see the organization which originally spawned Bell Labs -- arguably the most important private sector research organization the US has ever seen -- reduced to this. (Not to mention the fact that Lucent, nee Bell Labs, is now but a mere appendage to the French telecom operation Alcatel.)
    • First, we don't know for sure that this is not a Facebook problem (an organization not renowned for technical competence). Second, the company currently known as AT&T has no connection with the original AT&T other than the name.

      > ...Lucent, nee Bell Labs...

      Nee Western Electric.

      • If it was a Facebook problem I think we would've also heard about it from people who don't have AT&T as their ISP. Though I tend to agree that Facebook isn't exactly the pinnacle of security best practices either...
  • I had something like this happen to me on T-Mobile a couple weeks ago. A mother and daughter were trying to call each other one night, and each call went to me. It went on for over an hour. I even tried to call their numbers back and got my voicemail.
  • ....that if you really need data to be secure, end to end security is the only way to go. That way, no matter what happens in the network (short of man in the middle attacks by a trusted or very resourceful attacker), either only you get your data, or nobody does.

    Of course I'm here on slashdot via a non-secure connection, but the worst that happens here is someone steals my account to post obnoxious shit. (and who would notice?)

    • by jc42 (318812)

      ....that if you really need data to be secure, end to end security is the only way to go.

      If you dig around in any archives related to the topic of computer security, you'll find this comment all over the place, and in the earliest documents you can find. It's well understood that if you rely on a lower "comm" layer for security, the people in charge of that layer have full access to everything you send or receive.

      This is why so many security people tend to just snicker at network-level security features.

  • by gmuslera (3436)
    Unless are women, the people working at your service provider (and all the layers between you and your target site) are in fact man in the middle. That they decide to "attack" by their own choice or i.e. government order is up to them, but is up to you being aware of that and take measures to minimize risks. Unless we are talking about facebook, of course, there lack of privacy don't seem to be a big priority.
  • What makes this "little known"?
    This is the whole reason we have SSL(TLS) and happens all the time, except usually nobody notices.

  • Security flaws (Score:1, Offtopic)

    by Jaktar (975138)

    It turns out that both of these women who use AT&T phones had both heard of Internet Explorer and Firefox. The nation of Liberia is now warning users who have ever heard of Internet Explorer or Firefox to switch to Liberia's own Liberexplorer for a limited time only. Supplies are running out fast and there is a strict limit of 2^10000th power per customer. Just five easy installments of $10.99 and you're in the clear. Act now!

  • cell phone internet uses a nat based system the higher priced plan have real ip's. I think that media net is nat based.

  • When describing how she knew it was not her account, Candace replied that

    "He's white -- I'm not,"

    Apparently the fact that the account holder was also male was not the first thing to cross her mind. I thought we had gotten farther than this.

    • Apparently the fact that the account holder was also male was not the first thing to cross her mind. I thought we had gotten farther than this.

      The article says what tipped her off was a photo of the site's owner. I would think that skin color would stand out as much as gender when you first see a photo.

      Plus, really, I'm a bit tired of all this pussy-footing around when it comes to race. We should be able to reach a place where we treat everyone else with respect, yet still are able to recognize our differences for what they are - not better than someone else's, nor worse; just different. A person's race is a legitimate part of their heritage and t

  • I have been getting facebook notifications for someone in Germany, I get notified of all the comments posted on their profiles. I thought this was something wrong with the facebook application itself, but this confirms my suspicions that there is a deeper issue at hand.
  • by sjames (1099)

    So, AT&T, tell us again what makes your service worth those outrageous rates? It seems you can't even assure that you won't deliver my data to a complete stranger.

  • The Sawyers experienced a different glitch. Coe said an investigation points to a "misdirected cookie." A cookie is a file some Web sites place on computers to store identifying information -- including the user name that Facebook members would enter to access their pages. Coe said technicians couldn't figure out how the cookie had been routed to the wrong phone, leading it into the wrong Facebook account.

    I cannot understand why Facebook didn't add the ip address to the hash of the login; making it impossible to use the same cookie with another IP address.
    I simply cannot understand. I even think mobiles generate their own UNIQUE identification code which can be used too for the mobile version of facebook.

    I'd think BOTH are in error; facebook for having ratsass security and the phone company of making this possible.

    Makes one wonder too; how safe we really are for MITM attacks; looking to this case...

    • by jc42 (318812)

      I even think mobiles generate their own UNIQUE identification code which can be used too for the mobile version of facebook.

      So where might my code find this?

      I just checked what my apache server tells a CGI program of mine when I connect from my cell phone. The only ID string I see is

      HTTP_USER_AGENT: "Mozilla/5.0 (Linux; U; Android 1.6; en-us; T-Mobile G1 Build/DRC83) AppleWebKit/528.5+ (KHTML, like Gecko) Version/3.1.2 Mobile Safari/525.20.1"

      I can easily tell what kind of phone this is. So can my code, whi

      • do these things remember cookies ?
        As soon as that's possible, an unique id can be assigned ...
        Add to the mix the useragent, ip, proxy info and (hash of an) internal identifier == unique id.

        I've seen earlier some entries from Perl code around cpan about mobile authentication, possibly with a few brands only; but cannot remember the right module anymore. There is some Ericsson code available through the web.

        I wonder if this "bug" is also possible through Facebook Connect, because that would mean an extreme pr

        • by jc42 (318812)

          do these things remember cookies ?

          The browser on my G1 has an explicit "Accept cookies" setting, so the answer is "sometimes". ;-) This is, of course, typical behavior in most browsers. There's also the usual "Clear all cookie data" item in the Settings menu. But it does mean that you can't simply rely on cookies working. As with things like javascript, the person running the browser can disable cookies.

          Add to the mix the useragent, ip, proxy info and (hash of an) internal identifier == unique id.

          Or you

          • This is no more difficult than a cookie to spoof by a man-in-the-middle such as an ISP.

            If the IP and other environment variables are passed together with that id; it would be "more" locked to location and client.

            For facebook with it's own security gateway (Facebook Connect), I've been expecting this session id to be at least that secure ...

Lo! Men have become the tool of their tools. -- Henry David Thoreau

Working...