> 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 somehow able to trick the yubikey neo into accepting a challenge from a different domain, by using the webusb API.
Reading further:
> The technique would only work with U2F keys that offer protocols for connecting to a browser other than the usual way U2F tokens communicate with a computer, known as the Human Interface Device or HID, which isn't vulnerable to the attack. The Yubikey Neo, for instance, can also connect via the CCID interface used by smartcard readers
> An assumption was made by Chrome that all U2F is HID, which doesn't hold for the Neo, whereas Yubico made an assumption that USB will never be accessible by web pages directly
So:
- Don't use a Yubikey Neo anymore
- Don't use Chrome
- Don't use U2F because FireFox doesn't support it
- Never use your yubikey because hardly anything supports it
Sigh
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 Bluetooth U2F key, and a NFC U2F key (works if you install Google Authenticator)
* Unfortunately, not FF on Android as I can't find how to enable U2F there yet :/
Speaking of which, why does Vanguard force you to still have SMS two factor available even when you add a U2F device...
Unfortunately for a large number of users that effectively means it doesn't work.
Which key did you use? I tried Yubikey 4 (via OTG cable) and 4C (directly) and the U2F flow with Authenticator did not work (just like the key would not be recognized for U2F).
but still hardly anything supports U2f :-(
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 default with very few performance-critical applications remaining outside that stack. Photoshop and AAA games might be exceptions. Services like databases and web browsers would not have a need to be in Chrome.
(don't hurt me, I know I'm strange.. ~)
Originally the scale was connected via serial port to the desktop. A little Perl service we called "the scale daemon" exposed the current weight on some localhost port. The backend would constantly poll that service and the web browser would poll the backend to keep the value on the page up to date. It was a nifty solution albeit a bit clumsy and it meant running an extra piece of software on 50+ machines in a warehouse.
At some point our scale vendor stopped selling scales with serial connections or maybe it was that the PC vendor stopped including serial ports. It was 10+ years ago and I can't recall exactly. What I do remember is that the guy that wrote the scale daemon had moved on and I had to figure out how to make it work with USB. It was fun and probably not as hard as it seemed at the time, but wow, being able to get at that scale from inside the browser would have massively simplified things.
So don't do that. It would be nice to know exactly what this dialog looks like, but it seems low risk?
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.
I wish more websites offered the option to use it.
So does Chrome ask for permission to allow USB access? Or maybe there's something about this I'm not getting.
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.
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 closely with the FIDO Alliance to develop a longer-term solution as well."
If, when logging in, you see a big modal dialog asking if you want to grant webusb access to the site, then DONT select your yubikey out of the list of connected USB devices and click "Allow".
As long as you can convince yourself to avoid taking that particular unusual action, it sounds like you're fine.
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 Linux (I know, a minority), you need to make an entry in rules.d[1] to even allow Chromium to access USB devices.
I can see how this potentially maybe could catch someone, but I don't see it as much of a risk.
[0]: https://blog.fastmail.com/2016/07/23/how-u2f-security-keys-w... [1]: https://developers.google.com/web/updates/2016/03/access-usb...
While its obviously not a total solution, I do think that maybe the permissions prompt should be a bit more scary: https://developers.google.com/web/updates/images/2016-03-02-...
I'd rephrase that to something more along the lines of "example.com wants full control of". Maybe with an option for device manufacturers to opt-in to support for WebUSB, allowing for protocol enhancements to improve security and a less scary permissions prompt.
>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.
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...
WebUSB terrifies me.
Are there any good writeups about security of different web browsers?
is Chrome a real issue?
As for Chrome being a real issue, some points off the top of my head: - Its extension store breeds out malware in regular intervals (feels like there's headlines about that at least every other month). - Pretty bad autofill exploit that was left unfixed for years: https://github.com/anttiviljami/browser-autofill-phishing (Might've been fixed in the past year, I haven't checked, but I doubt it.) - Chrome Sync is not end-to-end-encrypted without the use of a second password, which effectively means that it is unencrypted for 99.9% of Chrome users. Google also actively uses this data, weaving your browsing history into the profile that they keep of you. So, if they ever have a data leak, a lot of data is going to come from people using Chrome, too. The NSA/CIA/FBI also tap into this data, possibly using it for cyber war attacks, so if you live in a country other than the USA, you're making yourself a prime target and an easy target by inputting this data through Chrome.
Sure, it's vulnerable to the man behind your back. But if such threat exists, you shouldn't type your password anyway.
It looks like this vulnerability is limited to Chrome at the moment. Good to know if using Chrome (or even Epichrome for SSBs) when doing things like online banking.
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.
OTP is regularly phishable, not requiring any webusb. Before this webusb attack, u2f was unphishable.
I'm curious (assuming even) that it could be subject to this exploit?
