Lessons from the Latest Facebook Breach
On Friday morning, Facebook announced that 50 million users had been affected by a security breach. They responded first by expiring the users’ access tokens and forcing them to log in again, a procedure also applied to another 40 million accounts which may or may not have been affected by the same exploit in the past. As the world’s largest social network, which is itself used to authenticate users for other websites and applications, the significance of this breach cannot be overstated.
What happened, exactly?
Facebook has not been completely forthcoming about the details — perhaps they themselves are still investigating the scope and nature of the attack and evaluating their liability. A press call featuring Facebook’s VP of Product Management Guy Rosen may shed some light, however. Rosen claimed that it was not a single bug in isolation, but the interaction of “three distinct bugs” that produced the security hole. These bugs were contained in the “View As” feature (a type of user impersonation tool for evaluating privacy settings) and the Video Uploader, the single-sign on authentication for which was incorrectly implemented.
A malicious user could use the View As feature on their profile to impersonate another user (in a limited read-only capacity, as intended) and then take advantage of the Video Uploader’s faulty Single-Sign On implementation to generate full access tokens for the targeted user. At this point, they are no longer viewing their own profile as another user – they could fully become that user, up until the access tokens were revoked by Facebook.
Once the tokens were revoked and the View As feature was disabled, this attack vector was closed and malicious users could not generate new tokens for their victims’ accounts.
What can we learn from this?
An obvious lesson, perhaps, is that if your engineering department’s motto is “move fast and break things” you will eventually break things. Writing unit and integration tests for your features, and allowing sufficient time for manual testing either by developers or Quality Assurance engineers, are practices that can only increase security. The video uploader’s Single Sign-On, which generated access tokens with the same permissions as that of the Mobile App, was obviously wrong. Even easier to catch, the video uploader was not intended to be present within any “View As” views to begin with but was exposed through edge-cases.
Almost as troubling as knowing you had your account and personal data compromised is not knowing. While Facebook likely knows fuller details, end-users have had no indication, save from being forced to log back in and possibly seeing a message in their news feed, whether unauthorized third parties had gained control over their accounts and what they accessed. This points to the importance of access logs for all critical resources so that a full accounting can be given, both for threat mitigation and for compliance.
Finally, the web’s increasing reliance on single sign-on providers like Facebook, Google and Amazon should give us pause. The benefits are obvious: the headaches of account creation, password management and more are obviated for end-users, who can utilize the same account for an increasing number of websites and apps. But if these services are compromised – as they were last week and will be again in the future – the consequences will be magnified. In light of the above, third-party managed SSO integrations like Facebook’s should be considered very carefully for any mission-critical applications and sensitive data.
If security and data privacy are top priorities for your organization, be sure to conduct regular audits and follow Privileged Account Management best practices. CyberSana can help – find out how.