Chrome lets hackers phish even 'Unphishable' Yubikey users • Hacker News Board

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

#81

Post by petee » Sat, Mar 03, 2018, 2:26 AM UTC

blitmap wrote: post #66

Sir_Cmpwn wrote: post #26

Earlier quoted context omitted.

The existence of WebUSB is awful. Why anyone ever thought it was a good idea to let JavaScript touch your USB devices is beyond me.

Strongly disagree here. I think WebUSB will enable a lot of cool things, though it will definitely be hard to sandbox. I want to program an Arduino from a web IDE. I want to control a 3d printer or pen plotter from a web application. I want to store things on a flash drive on my iPhone using a web-based file explorer? This last one sounds strange. On a tangent, I see application runtimes moving into the browser by de…

Just because its possible, doesn't mean we should!

I see nearly no good reason for any of those uses to be web-based, and certainly not with hardware control! If you want to store files on your flash drive, the browser should handle that, not give out direct usb access...

Hearing this exists was a shock, like when the first Android 'Instant' load app showed up on my phone (apps that you don't install, but run themselves if you goto a website or a physical store, and without asking you)

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

#82

Post by saltcured » Sat, Mar 03, 2018, 2:32 AM UTC

superdaniel wrote: post #52

mfontani wrote: post #13

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…

The usual rationale from companies forcing SMS two factor is that you need to have a convenient account-recovery mechanism before you enable something strict and lock yourself out. They don't want the support cost of dealing with these lockouts.

Unfortunately, these same companies often then claim that there is no harm in SMS two factor since "clearly it is stronger than one factor". But they are blind to their own systematic design flaw which is that the same SMS setting to enable two factor also usually enables one-factor password-recovery via this supposedly trusted phone.

Given what we know about SMS security, it is pretty obvious that one-factor SMS is weaker than one-factor good strong password. And if the good strong password can be merrily reset by whomever hijacks your phone, you have really just decreased your security posture while performing this whole security theater around two-factor and hardware tokens.

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

#83

Post by Buge » Sat, Mar 03, 2018, 2:40 AM UTC

skybrian wrote: post #25

crispyporkbites wrote: post #2

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…

More importantly: "the phishing site would also have to ask the user's permission to enable WebUSB access to their Yubikey, and then tap the physical button on the key." So don't do that. It would be nice to know exactly what this dialog looks like, but it seems low risk?

>So don't do that.

How about you tell users to simply not enter their password into phishing sites?

When users want to do something (sign in) and there are instructions on the page telling them to do something (enter password or accept usb) then the users will do it.

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

#84

Post by Buge » Sat, Mar 03, 2018, 2:43 AM UTC

LethargicStud wrote: post #9

I'm unclear as to how this would work in practice. Chrome supports U2F out of the box, so getting a big weird pop-up asking to access your USB device, you'd at least be suspicious. Upon registration, the server also collects a nonce, which is used for verification[0]. The attackers would need to get that nonce from the site. Hopefully, the site disables CORS so a phishing site cannot request a challenge. Lastly, on L…

CORS is irrelevant.

>The attackers would need to get that nonce from the site.

The attackers have their own machine with a browser running on it that visits the real site and gets the nonce, then hands that nonce to the victim to be signed by their key.

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

#85

Post by kuschku » Sat, Mar 03, 2018, 2:43 AM UTC

throwaway23424 wrote: post #8

Santosh83 wrote: post #7

Earlier quoted context omitted.

They're slowly inventing operating systems, complete with hypervisor technology, with all the gargantuan complexity that it implies, to please big business that wants the client OS to essentially become obsolete.

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.

A browser is more secure than a linux namespace with SELinux rules that require explicit approval for any access?

A browser is more secure than Qubes?

The flaw is in legacy software, not in what is possible. Had humanity spent the effort that was spent on browsers on operating systems instead, we'd have had the same security improvements without all the negatives.

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

#86

Post by Buge » Sat, Mar 03, 2018, 2:47 AM UTC

crispyporkbites wrote: post #16

Ajedi32 wrote: post #14

Earlier quoted context omitted.

Or just don't click "Connect" on the USB access permissions prompt when it pops up. Unfortunately though, as with any phishing attack, this flaw is most likely to be effective against uninformed users, and those users are the least likely to take proactive measures to protect themselves beforehand. Fortunately: > "We will have a short term mitigation in place in the upcoming version of Chrome, and we're working close…

What kind of uniformed user uses a YubiKey? I supposed you could trick them by saying that the login process has changed and they need to enable WebUSB to let their YubiKey work

The purpose of a Yubikey is to prevent users from making mistakes.

This phishing attack removes the benefit that Yubikeys provided.

Sure a smart users can decline the permission prompt. But a smart user can also simply not enter their password into phishing pages.

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

#87

Post by Buge » Sat, Mar 03, 2018, 2:51 AM UTC

exabrial wrote: post #28

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.

How would that help? Couldn't the webusb simply lie to the u2f device about what the channel is?

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

#88

Post by Buge » Sat, Mar 03, 2018, 2:53 AM UTC

nimbius wrote: post #34

U2F != OTP, which is Yubikey 4. For some reason the FIDO alliance decided they didnt want OTP. Yubikey 4 allows openPGP keys as well as OTP Yubikey functionality, making it half HSM/half token. the FIDO keys offered by Yubi only do asymmetric cryptography.

>For some reason the FIDO alliance decided they didnt want OTP.

OTP is regularly phishable, not requiring any webusb. Before this webusb attack, u2f was unphishable.

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

#89

Post by X-Cubed » Sat, Mar 03, 2018, 3:01 AM UTC

heroprotagonist wrote: post #68

blitmap wrote: post #66

Earlier quoted context omitted.

Strongly disagree here. I think WebUSB will enable a lot of cool things, though it will definitely be hard to sandbox. I want to program an Arduino from a web IDE. I want to control a 3d printer or pen plotter from a web application. I want to store things on a flash drive on my iPhone using a web-based file explorer? This last one sounds strange. On a tangent, I see application runtimes moving into the browser by de…

Considering your use cases, why not simply require an extra step in the browser to enable it instead of turning it on for all users? EG, take a few seconds to turn on a flag in configuration, or add a plugin.

There is a permission prompt that appears, websites can't use the WebUSB functionality until you allow them too.

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

#90

Post by exabrial » Sat, Mar 03, 2018, 3:06 AM UTC

eximius wrote: post #56

exabrial wrote: post #28

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.

... sigh.