Live data from Hacker News

Chrome lets hackers phish even 'Unphishable' Yubikey users

wired.com

51–60 of 113 posts

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#51

Earlier quoted context omitted.

The web browsers are so much more secure than what we had before (just accepting executable binaries from other people), so I look at this as a way forward.

I'm not that confident. Browsers blindly accept and execute whatever they receive. The more features that get added, the larger surface there is to exploit. A case in point: WebUSB as mentioned in the article.

The nice thing though is that, although the added attack surface is there, its not really accessible to web pages until a user grants the necessary permissions. Not really all that different from telling users to execute a native app in that respect.

In this case it's not even an exploit really; more like social engineering. (Tricking users into granting the phishing site unrestricted access to their Yubikey, then using that access to trick the user into authenticating a login session for the phishing site.)

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#52

This is the attack: > If a victim logs into a fake Google site, the phishing site passes on their username and password to the real Google login page. Then the spoofed site passes back Google's request for the user's U2F token and collects the Yubikey's unique answer, all via WebUSB. When that answer is then presented to the real Google site, the attackers gain access to the victim's account. So basically they are so…

> - Don't use U2F because FireFox doesn't support it It does! Open about:config and switch security.webauth.u2f to true. It'll Just Work. I've in the recent past modified a barebones Perl webapp to try and understand U2F better, see https://u2fdemo.darkpan.com/ I've been able to log in / use U2F from: * FF on Windows and OSX * Chrome on Windows, OSX * Chrome on Android using either a OTG cable for a U2F USB key, a Bl…

Firefox barely supports U2F. It works on Github and Dropbox, but doesn't work on sites like Vanguard and Google. Every time I do a Firefox update I do a search of the bug listing and they seem to have an incomplete implementation of the spec. They're kicking the can until they fully implement the WebAuth API and jump over dealing with whatever earlier spec they were targeting.

Speaking of which, why does Vanguard force you to still have SMS two factor available even when you add a U2F device...

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#53
post #41

This is the attack: > If a victim logs into a fake Google site, the phishing site passes on their username and password to the real Google login page. Then the spoofed site passes back Google's request for the user's U2F token and collects the Yubikey's unique answer, all via WebUSB. When that answer is then presented to the real Google site, the attackers gain access to the victim's account. So basically they are so…

It's surprising that this works. Last time I checked WebUSB the device would have to have a descriptor allowing its use via web page effectively white listing what can be used on the web.

Looks like they changed it: https://wicg.github.io/webusb/#attacking-a-device

While I understand the reasoning behind that move, I'm not sure I fully agree with it. I don't think users will necessarily understand the implications of granting a site access to a device that wasn't designed with attacks from malicious code as part of its threat model. At the very least, the wording on the permissions dialog should be changed to indicate that the user is granting the site _full control_ over the device they're connecting it to.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#54
post #49

Earlier quoted context omitted.

Then click "deny", or (in the case of a native app) refuse to install the executable. Either way you're safe. For those that _do_ require [such use cases][1] though; they can now do so without needing to expose their system to an unsandboxed native app. [1]: https://wicg.github.io/webusb/#motivating-applications

I know to do that. How about my grandma, who just clicks whatever button looks like it'll make the message go away sooner? The web is a disaster and WebUSB is a prime piece of evidence supporting this.

Would that include the "Run" button on a downloaded executable?

While obviously we want to do as much as we can to discourage users from shooting themselves in the foot, there are limits. At some point, eventually you _do_ have to trust that the user knows what he's doing.

Giving users a choice on when to allow a page access to one specific USB device is not a "disaster".

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#55

The Yubikey is great and has uses outside of U2F, which I've never had much faith in.

U2F is actually a very cool spec, basically a user friendly version of client side certificates (which could be user friendly, but arent).

What are your concerns?

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#56

I wish channel bound tokens were mandatory in the u2f spec, or a browser key was part of the auth request to the token, for exactly this reason. U2f is "optionally" unphishable.

FIDO discussed this on their site. It's optional so corporate firewalls that perform MITM can continue to work with U2F.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#57
post #42

Earlier quoted context omitted.

Assuming the sandbox works. If the sandbox is porous, the attack surface balloons from apps I choose to install to every link I click.

Not every link you click. Only sites that you grant access to the necessary attack surface. The Web USB API can't be attacked by sites that you haven't granted access to it.

What if that privileged website has XSS vulnerability?

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#58
What is the usecase for WebUSB? Here [1] someone from Google suggests vendors should write device drivers in Chrome HTML and Chrome Javascript. Please don't.

Or (my assuption) it might be for devices that cannot work without browser and network connection.

[1] https://developers.google.com/web/updates/2016/03/access-usb...

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#59

Earlier quoted context omitted.

> - Don't use U2F because FireFox doesn't support it It does! Open about:config and switch security.webauth.u2f to true. It'll Just Work. I've in the recent past modified a barebones Perl webapp to try and understand U2F better, see https://u2fdemo.darkpan.com/ I've been able to log in / use U2F from: * FF on Windows and OSX * Chrome on Windows, OSX * Chrome on Android using either a OTG cable for a U2F USB key, a Bl…

Firefox barely supports U2F. It works on Github and Dropbox, but doesn't work on sites like Vanguard and Google. Every time I do a Firefox update I do a search of the bug listing and they seem to have an incomplete implementation of the spec. They're kicking the can until they fully implement the WebAuth API and jump over dealing with whatever earlier spec they were targeting. Speaking of which, why does Vanguard for…

> Firefox barely supports U2F.

Haha it's funny you put it this way because actually it's Firefox that implements FIDO U2F standard correctly and Chrome is not. Chrome uses low level API to communicate with their built in extension and the high level shim that they provide is not 100% spec compliant.

Google did not bother to use the U2F correctly on their accounts site, Github for example did it correctly and their 2FA works on any browser (that is FF and Chrome).

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#60
post #45

Earlier quoted context omitted.

Native desktop apps are limited in number are nowhere near the dumpster fire the web is. My desktop isn't routinely downloading and executing payloads from the web. They're clearly different.

This is about the Web USB API, not the entire web in general. Are you routinely granting web pages access to your USB devices? That's not a permission that web apps get by default (unlike with native desktop apps btw). It comes down to this: if you ever found yourself in a situation where you needed to connect a USB device to a remote service, would you prefer to download that service's unsandboxed native code to you…

There are operating systems which don't by default give every application running as every user account access to every storage device.
Post reply on HN