The 2018 Facebook Data Breach
On September 28th, 2018, Facebook announced it’s biggest data breach to date. They estimated 50 million accounts were affected at the time of the disclosure. Subsequent to the disclosure, security professionals from all verticals took to the interwebs to provide what most would consider sensible advise:
- Time to update your passwords;
- Time to enable Two Factor Authentication (2FA);
Neither, however, would offer users an appropriate response to this type of data breach. This knee jerk reaction speaks to a bigger problem we have in our community of misinformation, often as a result of our own lack of understanding of a problem.
misinformation (noun):
: incorrect or misleading information
//Indubitably, a great deal of paranoid and otherwise irresponsible misinformation about the Kennedy assassination has traveled far and sold well …
This post will analyze the details that have been publicly shared. It will highlight why, when I was asked, my response to users was, “Nothing. Do nothing. Nothing you do will help you mitigate or prevent this specific type of data breach. If you were forced to log out, assume your account was possibly affected.”
How Many People Were Affected
The latest report has the total affected divided into two distinct cohorts:
[table width =”100%” style =”table-striped table-bordered” responsive =”false”]
[table_head]
[th_column]Cohort[/th_column]
[th_column]Description[/th_column]
[th_column]Data Stolen[/th_column]
[/table_head]
[table_body]
[table_row]
[row_column]400,000[/row_column]
[row_column]This was the original attack vector (i.e., how they got in).[/row_column]
[row_column]This includes posts on their timelines, their lists of friends, Groups they are members of, and the names of recent Messenger conversations. See note below.[/row_column]
[/table_row]
[table_row]
[row_column]30,000,000[/row_column]
[row_column]Access tokens for this cohort were extrapolated from friends of the original 400k cohort.[/row_column]
[row_column]The specifics of what was stolen for these 30 can be found in the next table.[/row_column]
[/table_row]
[/table_body]
[/table]
Note: Message content was not available to the attackers, with one exception. If a person in this group was a Page admin whose Page had received a message from someone on Facebook, the content of that message was available to the attackers.
The 30 million affected were divided into three cohorts defined by the type of data stolen:
[table width =”100%” style =”table-striped table-bordered” responsive =”false”]
[table_head]
[th_column]Cohort[/th_column]
[th_column]Data Stolen[/th_column]
[/table_head]
[table_body]
[table_row]
[row_column]15,000,000[/row_column]
[row_column]This included name and contact details (phone number, email, or both, depending on what people had on their profiles).[/row_column]
[/table_row]
[table_row]
[row_column]14,000,000[/row_column]
[row_column]This included username, gender, locale/language, relationship status, religion, hometown, self-reported current city, birthdate, device types used to access Facebook, education, work, the last 10 places they checked into or were tagged in, website, people or Pages they follow, and the 15 most recent searches.[/row_column]
[/table_row]
[table_row]
[row_column]1,000,000[/row_column]
[row_column]The attackers did not access any information.[/row_column]
[/table_row]
[/table_body]
[/table]
Data provided by the latest Facebook release.
Understanding the Hack
The attackers were able to daisy chain three specific bugs that allowed them to abuse the “View As” feature. The “View As” feature allows you to check how another user might see your post; this is used by folks that apply specific controls and rules to their profile (e.g., Maybe I don’t want everyone to see private photos, or maybe I want to restrict how co-workers can see my pictures, etc…). This view as feature was a great way to confirm the settings were right. This feature has been removed since the breach.
The attackers exploited the first 400k cohort, then laterally moved into the accounts of friends. As they viewed the accounts of the 400k they were able to steal the access tokens for any of the friends associated with the accounts originally exploited. This is how it ballooned to 30M different users.
The Three Bugs Leveraged
First: View As is a privacy feature that lets people see what their own profile looks like to someone else. View As should be a view-only interface. However, for one type of composer (the box that lets you post content to Facebook) — specifically the version that enables people to wish their friends happy birthday — View As incorrectly provided the opportunity to post a video.
Second: A new version of our video uploader (the interface that would be presented as a result of the first bug), introduced in July 2017, incorrectly generated an access token that had the permissions of the Facebook mobile app.
Third: When the video uploader appeared as part of View As, it generated the access token not for you as the viewer, but for the user that you were looking up.
Understanding Access Tokens
Leveraging these three bugs the attacker was able to steal what is known as an “access tokens.” These access tokens are not your username, or passwords.
An access token is an opaque string that identifies a user, app, or Page and can be used by the app to make graph API calls. The token includes information about when the token will expire and which app generated the token. Because of privacy checks, the majority of API calls on Facebook need to include an access token. – Facebook Access Tokens
There are four very distinct types of access tokens: User Access Token, App Access Token, Page Access Token, and Client Token. These tokens get specific permissions associated with them, depending on their function. Permissions can include a wide range of actions – view, read, modify, or write. The ones stolen in this instance were User Access Tokens.
These tokens are what you would call a security token (a.k.a authentication token). This method of authentication is recognized as token-based authentication. It streamlines the authentication process for us as users (it helps provide a more streamlined experience) and is what you’d consider a stateless solution.
Think of when you’re interacting with a social platform. Think of the number of times you have to log in over a 30 days period. The odds are, if you are using the same browser, not often. This is facilitated by Facebook via their access tokens.
This form of token-based authentication is prolific on the web today. Some tokens have very long lifespans (e.g., 30 days) others have very short lifespans (e.g., 15 minutes). A great example of where you might find long lifespans is a social platform (e.g., Facebook). Short lifespans might be reserved for more sensitive systems (e.g., a bank or security provider).
What Can You Do As a User?
Nothing. There is little we can do in this situation.
The only possible response was made on our behalf by Facebook:
To protect people’s accounts, we’ve fixed the vulnerability. We have also reset the access tokens of the almost 50 million accounts we know were affected and we’ve also taken the precautionary step of resetting access tokens for another 40 million accounts that have been subject to a View As look-up in the last year. Finally, we’ve temporarily turned off the View As feature while we conduct a thorough security review. – Facebook
This action alone fixed the problem – addressing the vulnerability and the users actions. By resetting the access tokens it forced anyone that, they thought, might have been affected to log back in (i.e., their access tokens were deleted).
This is the alert you can expect to see logging back in after your tokens were removed. (Facebook)
If we move beyond the unfortunate event of the breach itself, there is much to be said for the speed at which an organization like Facebook was able to respond and contain the exposure. In many ways, the impressiveness and success can be attributed to the implementation of a token-based authentication mechanism.
If nothing else, this shows the power of using tokens for app auth instead of passwords.
They can simply invalidate the tokens and people log back in to re-authenticate their apps etc… much better than passwords being breached. Kudos on them for quick action.
— Chris Teitzel (@technerdteitzel) September 30, 2018
Needless to say, the purpose of this article isn’t to speak against the importance of strong credentials or employment of 2FA. It is, however, meant to understand this breach while also highlighting why it’s so important that we do not just pass information until we have a better grasp of the specifics.
As always, if you feel I misrepresented any of the facts, let me know.