[firloop]

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.

[jonplackett]

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.

[andybak]

Yes. A thousand times yes.

oAuth outside a browser is just training people to be phished.

[jonplackett]

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.

[Ayesh]

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.

[donmcronald]

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.

1. https://krypt.co/blog/posts/prevent-phishing-on-the-web-with...

[jrockway]

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."

(https://w3c.github.io/webauthn/#sctn-client-authenticator-pr...)

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."

(https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-se...)

[donmcronald]

I learned a lot from that. Thanks!