Given the scale and severity of the @facebook breach, I’ll share some thoughts based on our recent @USENIXSecurity paper with @m0eb1t, amrutha, @kaytwo, @stevecheckoway, where we explored the ramifications of your Facebook account being compromised. cs.uic.edu/~polakis/paper… (1/n)
There are many nuanced and not-so-obvious issues that arise due to how Single Sign-On functionality interacts with local account management on 3rd parties (referred to as relying parties in the context of SSO). Facebook's current actions do not prevent these attacks (2/n).
In our experiments we demonstrated how the Facebook iOS app was exposing the session tokens over unencrypted connections, while in this attack the root cause is a complex combination of three different bugs as explained here: newsroom.fb.com/news/2018/09/s… (3/n)
An unexpected finding during our experiments was that when attackers use hijacked FB tokens (i.e., cookies) to access the user’s FB account, the attacker’s session *didn’t* show up in the list of active sessions if the attacker stayed connected for less than 60 mins. (4/n)
As such, looking at the active sessions would not alert the user of the ongoing attack. If this hasn't been fixed by Facebook since our experiments, current advice about looking at active sessions will likely not help you. (5/n)
Another very critical yet overlooked problem is that the stolen tokens can be used to obtain access to a user’s account on other websites that support Facebook SSO *even if the user doesn’t use Facebook SSO* to access them. This depends on 3rd party implementations. (6/n)
Depending on how a site implements local account management, in some cases attackers can gain access to users' 3rd party accounts that haven't been associated with their FB account. In other cases the attacker is simply presented with a new account (under the user's name). (7/n)
While not applicable here, 3rd parties can "instruct" FB during SSO to make users first re-login w/ their password (thus preventing attacks using stolen cookies and not passwords). We found that the vast majority of 3rd parties do not “instruct” FB to make the user re-login (8/n)
More importantly, once attackers gain access to those 3rd parties, they can maintain access to user accounts in those websites using the cookies set by those sites. No matter what FB does, they can’t do anything to prevent attackers’ from accessing those accounts. (9/n)
In our paper we describe various attacks that take advantage of the interplay between SSO and local account management for stealthy and long-lasting access to those user accounts. (10/n)
To make matters worse, we found that the majority of popular sites that we audited, don't offer session management options for terminating active sessions and invalidating cookies. Users currently lack ways to recover from their accounts being hijacked on many 3rd parties. (11/n)
The sheer number of 3rd parties that support FB SSO further exacerbates the issue. Manually going through the account settings of dozens or potentially hundreds of 3rd parties, or contacting customer support in each case, is infeasible. (12/n)
In a less obvious attack, we demonstrated how attackers can use the FB token to create accounts for the user on websites where they don’t have an account already; this could be used for a variety of attacks from spam/phishing to identity-related scams. (13/n)
More surprisingly, attackers can set a long-term trap and wait for users to create an account on those sites and start using them in the future. For instance, attackers might be particularly interested in the user data or account functionality offered by popular website X. (14/n)
Even if the user doesn’t have an account on X, attackers can create the user’s account on X using FB SSO, and wait for the user to join X in the future. Given the nature of SSO, the pre-existence of that account won’t be apparent to the user upon joining. (15/n)
To mitigate these attacks, we proposed an extension to OpenID Connect for universally revoking access: it allows identity providers (like FB) to instruct all 3rd parties associated with a compromised account to terminate all active sessions and invalidate passwords. (16/n)
Overall, I’ve omitted a bunch of details from our paper, but this incident has greater and more long-lasting security and privacy implications than what is being currently reported and users should be extremely cautious about suspicious activities across all their accounts (17/n)
We hope that this incident will incentivize major vendors to better address the shortcomings of current SSO schemes, more thorough evaluation of authentication implementations in practice, and the adoption of our proposed defense.
As shown by this incident, authentication and access control flaws can manifest in complex ways and have implications across many different websites. (19/19)
To clarify: our research goal is to highlight the implications of SSO in general. Our findings are not limited to FB, but apply to any identity provider. Apart from exposure of FB tokens, the 3rd-party issues we reported rely on implementation issues in those sites, not in FB.
