// JSON-LD for Wordpress Home, Articles and Author Pages. Written by Pete Wailes and Richard Baxter. // See: http://builtvisible.com/implementing-json-ld-wordpress/

Man in the Middle? No, Just Your Carrier

As you may be aware, several individuals using AT&T-based cellular phones recently reported being logged into the wrong Facebook account when accessing the Facebook site from their phones.  Current reports indicate that the root cause is AT&T’s network, which misdirected Facebook cookies.  These cookies, set to reflect that an individual has logged in, are to be stored on each user’s device.  Is this issue a cause for concern?  Is the issue likely limited to Facebook?  Does Facebook bear any responsibility?

In terms of concern, I’d say there is cause for major concern. We implicitly trust that the single request/response interaction between the browser and the server must be represented by a single network connection.  Unless an attacker inserts him or her self into the virtual connection circuit, the server’s response to the browser (containing the cookie) must be the same connection that sent the original credentials.

In this case that trust appears to be misplaced.  It is easy to understand how this is possible.  The carriers are free to manage connections however they choose.  In reality the carrier is likely proxying between the cellular network and the Internet, like any NAT-based approach.  A little coding error, such as an improperly shared resource, and results destined for one phone are returned to another.

Classically this seems like a race condition.  Certainly in the latest incident that explanation seems consistent with the facts since the two people who ended up on each other’s Facebook accounts were on-line at the same time.  Nothing particularly interesting about multi-threaded code containing a race condition.  It has happened before and will happen again.

This leads me to my second question, is this likely limited to Facebook users on the AT&T network? That seems doubtful.  It is hard to imagine that the carrier’s infrastructure that proxies requests includes specialized instructions just for Facebook.  it seems very likely that any connection-related flaw can occur for any web interaction.

Since AT&T customers are not reporting myriad incidents of incorrect pages we can assume that the flaw requires not only simultaneous requests but also other special conditions such as requests to the same destination and possibly from the same locality.  The latter is just conjecture, but certainly this issue isn’t globally swapping web requests and responses for AT&T customers on a regular basis.

Finally, putting on an application security hat, is there anything that Facebook could do to mitigate this type of issue? After all, it is infrastructure completely out of Facebook’s control that appears to be creating the problem.  This is apparently not related to Facebook’s creation of cookies, managing of sessions and so forth.  Yet it seems to me that a likely mitigation is under Facebook’s control; the use of SSL.

A flaw that swaps requests and responses over an unencrypted channel won’t lead to a failure at the receiving end.  Both users’ phones were expecting an HTTP response and they each got one.  But if SSL had been in use then the two connections would have negotiated different symmetric keys and the misdirected response would have been gibberish when received by the wrong phone.

In my opinion any sites that utilize authentication over unencrypted channels are culpable in situations like this.  They are enabling a well known style of attack, man-in-the-middle, and lowering their security posture.  This leaves users vulnerable to attacks and flaws in infrastructure, such as this AT&T example.

If access to a business’ content or service requires authentication then that business must use encryption to manage the authenticated session. Anything less creates a false sense of security for users, since they are helpless to identify an attack, whether malicious or accidental.  The simplicity of implementing SSL should make this bit of laziness unconscionable.

Here are a few reports regarding the AT&T/Facebook incidents:

Tags: , , ,

Leave a Reply

You must be logged in to post a comment.