The ultimate fallout from the Facebook data breach could be massive

Less than a week ago, Facebook announced that unknown attackers have managed to string together three bugs affecting the social media platform, which allowed them to steal access tokens of at least 50 million users – and likely more.

The tokens allowed the attackers to take over victims’ Facebook accounts but could also have been used to log into accounts the victims opened on other websites and apps by using Facebook Login (i.e. using Facebook as an IdP – identity provider).

The fallout from the incident could be enormous

The possibility of other accounts being compromised in this way was recently made public by a group of researchers from the University of Illinois at Chicago.

They researched how Single Sign-On (SSO) is deployed by various services and pointed out a number of new attacks that leverage SSO for maintaining long-term control of user accounts.

These attacks are made possible by the inadequate implementation of the SSO specification by the majority of relying parties, as they do not require users (or attackers) to re-enter their (or their victims’) Facebook username and password during the SSO process.

Some other things the researchers discovered (and that one of them – Jason Polakis – helpfully summarised in this Twitter thread):

• On Facebook, the attacker’s session doesn’t show up in the list of active sessions if the attackers stay connected for less than 60 mins (or it didn’t when they conducted their experiment).
• Attackers can use the FB token to create accounts for the user on websites where they don’t have an account (handy for spam/phishing/identity theft attacks), or they can wait for users to create an account on those sites and start using them in the future.
• The attackers can minimize their digital footprint of these attacks and maintain access to the user’s non-Facebook accounts, even if the user changed the password or killed active sessions (where they are shown).

“Our analysis reveals that 89.5% of the [95 most popular] relying parties we evaluate do not offer options for invalidating active sessions. Moreover, manually revoking access and changing passwords is ineffective in many RPs, and practically infeasible as it cannot scale; due to the preemptive account hijacking attack, the user would also have to check every new RP she uses in the future,” they noted.

“For 74.7% of the RPs users have no way to recover from our attacks. This reflects the shortcomings of SSO schemes and the fractured state of the ecosystem; without a process for universally revoking permission across all RPs and simultaneously invalidating all existing sessions in every RP account associated with the compromised IdP account, SSO facilitates attackers in maintaining persistent and pervasive control over victims’ accounts.”

Polakis also pointed out the urgent need for major vendors to better address the shortcomings of current SSO schemes, more thorough evaluation of authentication implementations in practice, and the adoption of their proposed defense: a backwards-compatible extension to OpenID Connect that adds support for universal authentication revocation.

The latest news from Facebook

As Facebook is playing their cards very close to their chest, it has been difficult for some of the relying parties such as Tinder to see whether their users’ accounts have been affected by this breach.

Many companies have said that they mounted an investigation into the matter.

Facebook told CNN that developers of apps that use Facebook login can detect the forced logout actions they took on Friday and protect people using their apps. Also, that they will soon provide additional recommendations for developers and users.

Facebook also posted an update on the situation on Tuesday, and said that they have analyzed their logs for all third-party apps installed or logged in during the attack they discovered last week, and that they have yet to find any evidence that the attackers accessed any apps using Facebook Login.

“Any developer using our official Facebook SDKs — and all those that have regularly checked the validity of their users’ access tokens – were automatically protected when we reset people’s access tokens. However, out of an abundance of caution, as some developers may not use our SDKs — or regularly check whether Facebook access tokens are valid — we’re building a tool to enable developers to manually identify the users of their apps who may have been affected, so that they can log them out,” shared Guy Rosen, VP of Product Management at Facebook.

Otavio Freire, CTO at digital risk protection company SafeGuard Cyber, noted that it looks like Facebook is asserting that those who used the functionality but didn’t utilitze the SDK weren’t adhering to terms of service which would limit Facebook’s liability.

We also still don’t know when the attack happened and how long it lasted. One of the exploited flaws was introduced in July 2017 so, theoretically, the attackers could have started exploiting it soon after.

Freire also pointed out that the users of the apps that do not use Facebook’s SDK have not been protected by Facebook’s reset of access tokens, and are likely still vulnerable to account hijacking (if those services have not closed active sessions using Facebook login credentials).

“We’re continuing to look at the hack for implications. Just because these three functions/bugs were isolated and exploited doesn’t mean there aren’t other combinations and those combinations could have been around for years,” he added.

A world of risk is opening up

Polakis noted that “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.”

Freire also pointed out the risks companies face due to this breach:

• Attackers could have used the stolen tokens to gain access to all of a corporation’s brand account pages, which could allowed them to see all brand agency relationships, tactical plans, private messaging history and pre-release content. Also, they could have accessed personal accounts of CEOs and other company higher-ups and used the information gleaned from them for blackmail, social engineering, or spear phishing attacks against company employees.
• Attackers could create new accounts impersonating the company or employees on social networks/web services where the company has no official presence.

SafeGuard Cyber can prevent these things from happening or remediate them quickly, he notes. They perform account surveillance on behalf of enterprise customers, they detect and remediate threats (e.g., account hijacking and posting of malicious content), help employees protect their accounts, and so on.

“In terms of corporate assets impersonation, SafeGuard Cyber uses a series of algorithms and ML-driven capabilities to detect accounts that imitate the compromised account. These impersonation can take on many forms. The most basic would be appropriation of the brand imagery, and the most sophisticated a full profile with a large amount of followers (likely bots) and content almost similar. The platform gathers all necessary data via searches, analyzes against these algorithms and then gives the user the means to request a takedown while auditing the takedown process,” he told Help Net Security.

When it comes to threat remediation, users don’t have to worry about their accounts being compromised if the company solution gets compromised.

“The SafeGuard Cyber platform has been granted specific capabilities from the platforms that enable us to behave as the user programmatically. This is done without any username and password being stored on the SGC side. We used redundant approaches to keep that control (of which for obvious reasons we cannot disclose) that monitors if we still have control. If control is lost a secondary monitoring process takes over.”