I'm curious if the oAuth flow requested a specific scope to have permission to remove the user from their Ads account. If so, did Facebook make it clear that the permission was be requested.
Permissions scoping is a really under-utilized tool.
I see this most often with extensions, which usually want to act on all domains when they should really need an allow list of just 1-2 domains. There are also many app integrations that use an API token that just straight bypasses login with NO security restrictions.
I would use a lot more app integrations if I knew I could trust the host platform to keep the apps honest.
I think we're missing a lot of innovation because we lack secure and reliable integration points between commodity services. Banking and Health are the most obvious issues. It should be trivial for me to authorize a third-party app to download transaction history from any bank without giving it the ability to change anything. I should be able to assemble my entire medical history by pulling from any medical office I interact with, and push that to any provider I choose to use.
There are lots of industry incentives to prevent this though. It's just like the Cable Card saga. You need strong, un-captured, technically-literate regulators to fix this stuff and unleash broader innovation.
It's possible that the attack didn't happen through the regular oauth credential request flow — if the OP logged in to Facebook inside of an app-controlled webview, the app could have just exfiltrated the user's login cookie and performed the change using "first-party" Facebook APIs.
The problem with many attacks is we've now been trained to do dumb things - like putting our password into webviews inside 3rd party apps - by reputable companies. So it doesn't feel as insane as it should do.
It's not just limited to webview's and tech companies.
When my bank calls me up about an issue with my account, they won't talk to me unless I give them my date of birth and email address for 'data protection' purposes.
They're always really confused when I say I will have to call them back.
This is what I think too. WebView doesn't show the domain of the page, and it is not possible to see if you are really in Facebook login page, or somewhere the attacker controls. Unless the attacker was using Yubikey or some sort of hardware token, the victim would have entered the TOTP code too, which the attacker can ask and pass to authenticate successfully.
How does a YubiKey prevent that kind of relay attack? If those keys blindly sign whatever's given to them, there's got to be a way to trick a user into signing something malicious.
This [1] says that U2F avoids phishing by having the browser tell the 2FA device the domain, but that seems a bit weak to me. The same site even has an app where the info is relayed via a browser plugin, so literally relaying the data that's supposed to be trusted. The only way I can see that actually working is if the security key knew to only sign challenges for a specific domain.
The security of the browser implementation is important. It provides the origin for the security hardware to sign, and the authenticating server ("relying party") verifies it. If your browser tells the key it's google.com when it's really evil.com, then sure, you can log into google.com if the user signs the request.
The WebAuthn spec says: "Direct communication between client and authenticator means the client can enforce the scope restrictions for credentials. By contrast, if the communication between client and authenticator is mediated by some third party, then the client has to trust the third party to enforce the scope restrictions and control access to the authenticator. Failure to do either could result in a malicious Relying Party receiving authentication assertions valid for other Relying Parties, or in a malicious user gaining access to authentication assertions for other users."
If you click further into the older FIDO spec, they cover this more explicitly: "Malicious software on the FIDO user device is able to read, tamper with, or spoof the endpoint of inter-process communication channels between the FIDO Client and browser or Relying Party application.
Consequences: Adversary is able to subvert [SA-2].
Mitigations: On platforms where [SA-2] is not strong the security of the system may depend on preventing malicious applications from being loaded onto the FIDO user device. Such protections, e.g. app store policing, are outside the scope of FIDO."
I must say that it was a pretty clever scheme.