> 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-...
If they'd done a proper post mortem and corrected the fundamental issue, and made sure it wouldn't have re-occured, this should not have happened.
There was a time where you could read other peoples' chats using this feature.
=)
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?
Set your preferences to show posts of your native language only, start poking around the timelines, and follow people who post something interesting. Follow, boost, reply, it only takes a few days before you have plenty of interesting content in your feed.
There's zero chance on Mastodon that you'll get caught up in a gigantic data breach like this. Probably less chance you get caught up in any kind of breach -- it's too obscure to be a target, plus the code is open source so many eyes on it, etc.
And you'll enjoy these guaranteed benefits, as well:
- No longer subject to the most sophisticated data vacuuming adtech in the world
- If you get bored/annoyed you can just take a break from Mastodon because it doesn't own your life the way Facebook tries to
Security through obscurity...
Open source != secure. I can guarantee that a hell of a lot more folks with a lot of security expertise have combed through the fb codebase than Mastodon.
...is not a solution by itself but is a perfectly valid part of a defense in depth strategy, for example running SSH on a port other than the default is a common and good practice.
> I can guarantee that a hell of a lot more folks with a lot of security expertise have combed through the fb codebase than Mastodon.
This is the same argument Microsoft always made in defense of Windows security back in the XP era. "We hire the best experts in the world so Windows must be fantastically secure." And Windows security turned out to be a train wreck. Now in Microsoft's defense it has improved considerably over the years, but Windows desktops still get owned far more often than Linux desktops do, for a reason that would probably apply to Mastodon today as well: not that many people use it, so it is not nearly as common a target for exploits.
I don't think I deserved downvotes for making these points btw, that button is way overused on HN.
This really depends on what kind of target you are. Are you a random person on the internet? Then making yourself a smaller target by using obscure services might help. Are you someone with sufficient value for a spear phishing attack? Not so much. “Sufficient value” might just be “you slighted the wrong person on the internet.”
There’s also a lot of trade offs involved, some of them less than obvious. For example mastodon servers may be run by a person/team who’s trustworthiness rating is harder to evaluate Tran facebooks. The server you’re on might by run by well-meaning but incompetent people. The server you’re on might have one participant that is a target of sufficient value for spear phishing and your data might be taken and leaked just to obscure the real target.
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.
As every feature on FB needs to take "View as" into account when handling their own permissions, a lot of developers on FB's payroll get a chance to f'up. We are all humans, so the probability of this happening is very high. The impact (for the users) is also high, given that it's automated and concerns every user on FB equally.
When dealing with a very probable, high impact risk in a software project, considerable additional effort is warranted to mitigate that risk: in this case maybe taint checking and additional implementations of the same feature in different programming paradigms, to ensure the system is fail-stop.
But in contrast to airlines and railways, the interests of FB and their users are not aligned. For Facebook, this risk is not (or was not deemed to be of) high impact, so we did't get any of this.
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.
With that said, this is a bigger vulnerability precisely because Facebook is a free service - at banks, you need to be a customer with real-world identity to even begin to attempt to exploit this.
No effort needed, if you click your Facebook bookmark, or follow a link or whatever, the browser goes "Oh, this is Facebook" and traps it inside the box with the rest of Facebook without any extra steps from the user. There's a cute blue "Facebook" icon added to the URL bar so you can see it's working.
(I mean, or, stop using Facebook, but for many that isn't a reasonable option)