Days after Facebook acknowledged a data breach of its platform – impacting 50 million accounts – the company said it has found no evidence that attackers accessed any apps using Facebook Login. But security experts are still on edge that the breach could have let attackers access third-party apps and websites. That’s in part due in part to the company’s Single Sign-On feature API, which lets users log in to websites using their Facebook credentials- and can be obtained via access tokens.
The social media platform on Friday said that hackers exploited a flaw in its platform that left the access tokens – the digital keys that keep users logged into Facebook – of almost 50 million accounts ripe for the taking. Guy Rosen, VP of product management at Facebook, stressed Tuesday that so far, there has been no evidence that the threat actors behind the breach have accessed apps via Facebook’s login tool.
“We’ve had questions about what exactly this attack means for the apps using Facebook Login,” said Rosen, in a Tuesday post. “We have now analyzed our logs for all third-party apps installed or logged in during the attack we discovered last week. That investigation has so far found no evidence that the attackers accessed any apps using Facebook Login.”
The vulnerability, which was discovered by Facebook engineers on Tuesday, existed in Facebook’s “View As” feature, which let users see what their profiles look like from other account.
Facebook has since fixed the vulnerability and reset the access tokens for the 90 million total accounts subject to the “View As” look-up in the last year. But the possibility remains that the attackers could have used the access tokens to access APIs containing profile information, such as name or gender. And one of those APIs, the Single Sign-On API, is used by third-party apps or sites that users can log into using their Facebook credentials.
Bernard Harguindeguy, SVP of Intelligence at Ping Identity, said that Facebook’s API – which lets apps communicate with the platform – needs to be monitored in the wake of the breach. “It’s a real wake up call for the industry in general to securing APIs,” he said.
Jason Polakis, assistant professor in the Computer Science Department at the University of Illinois at Chicago, told Threatpost that Facebook’s announcement that no apps have thus far been accessed is “encouraging,” but lacks important details, such as the time period the audit took place and what that means for apps. “People need more details regarding what Facebook information of theirs was actually accessed by attacker and how long the actual attack lasted,” he said.
Risks also remain for users who may have used Facebook Single Sign-On for other third-party apps, Polakis said. “As long as current practices of SSO deployment remain as is, users face the risk of their data being exposed on a massive number of websites if any of their identity provider (e.g., Facebook, Google) accounts are compromised.”
Polakis and a team of researchers in August manually evaluated 29 websites and 66 popular iOS apps that support Facebook Single Sign-On (SSO) to look at the flaws that emerge from the feature. In signing into these 29 websites, the research team was still able to log into 22 of them – even after dropping access to Facebook accounts.
“While the SSO paradigm enables seamless integration and effortless navigation, it also epitomizes the single point of failure which the internet’s architects have strived to avoid since its inception,” the paper said. “And even though this property is not a vulnerability in and of itself, we have shown that SSO as it is currently implemented exposes users to numerous dangerous and stealthy attacks, some of which extend to services not connected to the original provider.”
Facebook said it hopes to combat more security issues similar to this breach in the future by building a tool to enable developers to manually identify the users of their apps who may have been impacted, so that they can log them out, said Rosen in his post.
But still, moving forward, “there is dire need for mechanisms to evaluate how SSO is implemented by 3rd parties and what account management and compromise remediation options are available to users,” Polakis told Threatpost. “Identity providers publishing optional ‘best practice guidelines’ is not enough, as developers can choose to ignore them or implement them incorrectly.”
