zlacker

[return to "Facebook Network Breach Impacts Up to 50M Users"]
1. herpde+nE[view] [source] 2018-09-28 21:47:47
>>colone+(OP)
Excerpts from the press call transcript [1] by Guy Rosen explaining what lead to this breach being possible:

> The first bug was that, when using the View As function to look at your profile as another person would, the video uploader shouldn’t have actually shown up at all. But in a very specific case, on certain types of posts that are encouraging people to post happy birthday greetings, it did show up.

> The second bug was that this video uploader incorrectly used the single signon functionally, and it generated an access token that had the permissions of the Facebook mobile app. And that’s not the way the single sign-on functionality is intended to be used.

> The third bug was that, when the video uploader showed up as part of View As -- which it wouldn’t do were it not for that first bug -- and it generated an access token which is -- again, wouldn’t do, except for that second bug -- it generated the access token, not for you as the viewer, but for the user that you are looking up.

> It’s the combination of those three bugs that became a vulnerability. Now, this was discovered by attackers. Those attackers then, in order to run this attack, needed not just to find this vulnerability, but they needed to get an access token and then to pivot on that access token to other accounts and then look up other users in order to get further access tokens. This is the vulnerability that, yesterday, on Thursday, we fixed that, and we’re resetting all of those access tokens to protect security of people’s accounts so that those access tokens that may have been taken are not usable anymore. This is what is also causing people to be logged out of Facebook to protect their accounts.

[1] https://fbnewsroomus.files.wordpress.com/2018/09/9-28-press-...

◧◩
2. gboudr+G01[view] [source] 2018-09-29 04:27:40
>>herpde+nE
> The second bug was that this video uploader incorrectly used the single signon functionally, and it generated an access token that had the permissions of the Facebook mobile app. And that’s not the way the single sign-on functionality is intended to be used.

Is it just me or does this sound like an terrible idea in the first place? Guess we can't know for sure, but why would anything unrelated to authentication generate access tokens?

◧◩◪
3. rblatz+d21[view] [source] 2018-09-29 05:10:03
>>gboudr+G01
Technical debt, multiple systems using multiple old authentication routines getting slowly upgraded to new auth methods. And no one taking the time to fully understand the ramifications. And honestly it seems like that was the right choice for the teams responsible. They all made tons of money delivered features and now years later a bug is found.
◧◩◪◨
4. sizzle+m51[view] [source] 2018-09-29 06:23:49
>>rblatz+d21
Would you feel the same way if this vulnerability was for, say, a major banking website?
◧◩◪◨⬒
5. marvin+ud1[view] [source] 2018-09-29 09:38:36
>>sizzle+m51
I work for a major (by Norwegian standards) bank. This level of authentication integration trickery wouldn't be attempted by us. Mainly because we try hard to avoid serious technical debt (due to timeline/delivery pressure) in our security infrastructure. We occasionally take such shortcuts in places that are not mission-critical, but they are always considered carefully as the tradeoff that they are. I believe that we are considerably better at technology development than most of the banks in the US.

That said, I've heard stories of similar bugs in the industry. The difference was that they were more shallow in the effort to reproduce; deep enough to get through QA but discovered quickly in production.

But honestly, Facebook has more resources to spend on security than any online bank. Banking security should be defense-in-depth: Strong first layer security, serious monitoring of suspicious activity & openness for reports by users, a certain level of manual approval of irrevocable transfers, a certain revocability of transfers that are able to be automatically processed, transfer size limits to deny one breach to have huge consequences.

And finally, a credible economic and legal system that ensures only a tiny minority of people want to rob a bank because there are much better options for making money, and banking regulations that leave the responsibility for security vulnerabilities squarely with the bank's shareholders.

Anyone can be owned with enough effort, so it's not just about creating software that's as secure as you can make it. You need to have sound policies as well.

◧◩◪◨⬒⬓
6. cbzoia+gf1[view] [source] 2018-09-29 10:15:51
>>marvin+ud1
Meanwhile I work for a major US IB. While I don't work on anything customer facing our internal SSO infrastructure basically consists of a single cookie that gets access to almost everything.. And its really not difficult to sniff one from another user (like say getting them to visit a link like http://mydesktop.companyname.com/..).

Its so bad that for certain systems we check the origin of your connection and will only trust you if you've come from the DMZ rather than internal.

[go to top]