Vendors, Disclosure, and a bit of WebUSB Madness | Hacker News Reader

Vendors, Disclosure, and a bit of WebUSB Madness

pwnaccelerator.github.io

175 pointsjwildeboer45 comments

Was there some work-around I'm missing or did they literally go "yeah this website can send anything to the YK device directly, waht could go wrong?". Because the folks at Google Security are definitely smart and many orders of magnitude more experienced than me, and that's a vuln even I can understand / see the problem with so something institutional must have gone way wrong if WebUSB shipped on the stable release without some kind of block-U2F-forgery filter.

As far as Yubico, I get that they are doing something pretty hard in the hardware / product-market-fit domains, and I respect that and I want them to succeed, but they appear to be seriously dropping the ball on the software part of their product [1], as well as "simplicity breeds security". They could do so much better on the actual UI/UX if they piece-by-piece copied the setup UX of a "smart" vacuum cleaner.

1. I emailed & on-site support ticket submitted them days ago about some of their certs having expired on 2017-05-10, and have gotten not a peep in response & no fix in sight. Did nobody set a team calendar reminder and is nobody responsible for checking it on a monthly / quarterly / at the very least end-of-year cycle? That seems pretty elementary "underwear goes inside the pants" kind of security competence.

https://i.imgur.com/bOCfXJ2.png https://developers.yubico.com/yubikey-neo-manager/Releases/y...

  did they literally go "yeah this website can send
  anything to the YK device directly, waht could go wrong?".

WebUSB displays a prompt, albeit an uninformative one [1]. The idea is to trick the user into enabling WebUSB when they think they're enabling U2F.

[1] https://developers.google.com/web/updates/images/2016-03-02-...

Well that clearly doesn't look like a U2F prompt.

Of course U2F devices should be excluded from the list, and there should be some warning text about "do not allow important devices on random websites", but that doesn't seem like a huge deal.

  Well that clearly doesn't look like a U2F prompt.

Thus downgrading U2F from "makes phishing impossible" to "relies on the user taking care to spot phishing attempts"

So just like any other phishing attempt then. What did we gain again?

Playing devil's advocate here (because I do agree this would be ridiculous but I think this is worth pointing out), but you can never completely rule out tricking the user. They could always download a file and run it to bypass the browser or something. So the question really is how easy it is to trick the user here.

> We realized this is not limited to U2F / FIDO and developed a generic proxy that allows to forward any USB device exposed to WebUSB to a remote system.

~sigh~

It's really depressing to learn that reality was much worst than any of my "this is going to end badly" predictions[1]. I originally thought[2] the problems would start on the hardware side with devices that were never designed for security. Forwarding everything with a proxy is shockingly worse.

[1] https://news.ycombinator.com/item?id=11466197

[2] https://news.ycombinator.com/item?id=11466415

Aside from the "no HID" (does a YK even count as a HID if you turn off the default slot 1 functionality?), was the proxy designed to have a firewall / sandboxing of some sort? Google engineers have done some incredible things and while ambitious, it seems this kind of thing is well within their reach.

Ouch.

> Also there seems to be a kind of relationship between Google and Yubico that I would love to know more about.

I've gotten this impression too, though looking back, it may be because Google suggests you Google for U2F, and every time I search for U2F I see Yubico. Anyone know more about this?

Yes, the U2F spec was developed by Google and Yubico, founding members of the FIDO Alliance. Google seems happy to have more companies on board—their Advanced Protection Program, which requires getting two security keys, suggests buying a Feitian device (which supports U2F as well as Google Smart Lock on iOS via a non-U2F Bluetooth protocol) and a Yubico one.

The real reason is Google buys YubiKeys enmasse from them for employee use (every employee has one), and works with them closely on in various ways.

In fact, they were closely involved when developing the USB Type-C variant.

Can you elaborate more on that? To my knowledge, it was the Intel, TI, Tyco, STM quadriga who was responsible for the nearly complete standard of USB Type-C, with software/consumer industry being given "eat or die" choice, with Apple's engineers apparently actually trying to stall the standard release.

If you meant to reply to my comment, Google is perhaps the largest deployer of Yubico products, and that is where their collaboration holds the most weight.

If there is a security issue with YubiKeys, it puts Google's corporate systems at risk.

I was asking about Usb type c. To my knowledge, Apple, MS, and Google were there just to give blessings on RFCs

I think he tried to say that Google was heavily involved with the development of the USB-C variant of the Ubikey (for example, for use with MacBook pros) rather than with the USB-C standard itself.

> Also there seems to be a kind of relationship between Google and Yubico that I would love to know more about.

Google and Yubico developed U2F, so....

Still, precisely because of this, I would say it's poor form for Google to award Yubico a bug bounty relating to U2F (would they award a bug bounty to an Android manufacturer for a kernel bug?).

It also seems like poor form for Yubico not to disclose their research when asking about the same topic to another researcher, and poor form for Google to be unwilling to award two bounties (this isn't the patent office, acknowledging and even incentivizing multiple discovery is fine).

WebUSB was an obviously bad idea right from the start, just like Web Bluetooth was, both of which I believe were proposed by Google. It all comes from this nonsense idea from Google that "all devices should be directly connected to the internet" (and thus owned by botnets).

Mozilla team, if you're reading, please reject implementing or at least enabling such APIs with extremely high-risk to the user by default in your browser - "sandbox" or not.

Why is it an obviously bad idea? In light of the work on NaCL, is there still no way you can imagine it could ever work?

What does NaCL have to do with this, it's a cryptography library?

The issue is that 99.99% of USB devices aren't designed with the possibility of hostile payloads coming from the host, so the security rests entirely on the webusb permission dialog. Which should be presented as "grant this website administrative access to your computer" but isn't.

> What does NaCL have to do with this, it's a cryptography library?

The other NaCl https://developer.chrome.com/native-client

Could the browser create a tight whitelist of payloads that are definitely not hostile, then expand it slowly to add functionality?

Native Client had layered sandboxes and was still exploited. I suspect that sandboxing, in general, is not right; we must find safety and correctness by construction, not by ad-hoc rules or policy or permissions.

This is a million dollar question, but it was answered long time ago: there is no substitute for a programmer who knows what he is doing.

This is something most companies can't do. Small co., can pull it out that for some times, but as companies grow, the temptation to "simply make money" overwhelms even most principled person.

The problem is that even when a programmer knows what they're doing, it does not then follow that I want them doing it.

"We were so preoccupied with whether we could, that we didn't stop to question if we should"?

How can you build applications on the web that use Bluetooth or USB devices without these APIs? Here there is a lot of hate for web based applications but I think this is because the web unlike native apps has a huge amount of transparency that means we can have solid debate about the approaches and solutions taken. In your closed source native app who knows what you chose for security, tracking and anything else about your app is not transparent. I always prefer web based applications over native. Native means I have far less trust in the application. Is it even using tls for network requests? So many things we can’t see in a native app.

Web assembly trashes that idea of transparency.

Also, maybe bluetooth and USB devices don't need to be on the net.

> Web assembly trashes that idea of transparency

Only if you believe minified JS is significantly easier to audit, which seems rather unlikely.

In both cases, the thing which works is securing the capability rather than the code. Having generic USB support is risky but e.g. having mediated access to cameras and microphones has been fine.

We couldn't even trust JS devs with high-performance timers and SharedArrayBuffers without enabling attacks like Spectre and Meltdown.

I find it highly unlikely we are going to be able to trust "mediated" access.

  How can you build applications on the web that use
  Bluetooth or USB devices without these APIs?

Same way you use mice, keyboards, sound cards, printers, webcams and so on: a generic, secure interface supported by all device makers, OSes and browsers.

The whole benefit of web apps is they demand less trust because they're better sandboxed. Poking holes in the sandbox (like WebUSB) makes web apps worse, not better.

Yeah, and if the powers that be (browser vendors) don't implement the generic interface you need (e.g.: signature tablets, cash drawers, NFC readers, memory card readers, etc.) then you:

a) Don't do it and pivot your company to doing something else.

b) Implement your own solution with companion native apps that build this missing bridge. Out of public scrutiny and with many times less resources, but hey: the browser is secure! ;)

>How can you build applications on the web that use Bluetooth or USB devices without these APIs?

You simply don't

This shouldn't be downvoted. Web platform isn't a place for device usage like that, that's a Pandora's box.

I always prefer web based applications over native. Native means I have far less trust in the application.

Really? Web applications can essentially change at the whim of the owner or server(s) hosting them, every time you refresh the page. You have far more control and "transparency" over when a native application changes.

Is it even using tls for network requests? So many things we can’t see in a native app.

You're just not looking hard enough. ;-)

As all the vulnerabilities discovered and exploited in closed-source software shows, along with those in open-source which have been there for many years without being discovered, whether the source is open or closed is nearly irrelevant.

To quote the mentality of those who see beyond that debate, "Source code? We don't need no stinkin' source code!"

> How can you build applications on the web that use Bluetooth or USB devices without these APIs?

Unfortunately, the only viable alternative right now is to install a companion native application. That companion app launches an (https/ws) server that talks to the device and exposes some api for your site to use through javascript.

It is a disgusting can of worms, but if you squash them all you get a working system at the end.

I'm seconding that with demand to sanitize all useless, bug prone APIs google introduced solely for own use.

Keep in mind that the big success of the current Google CEO is ChromeOS. Basically a minimum OS booting straight to a browser.

As "everything" is supposed to live inside a browser window, there "naturally" needs to be rich APIs for accessing whatever the user may decide to plug into ports or their wireless equivalents.

We are going full circle here, with the web "browser" becoming the new leased line terminal. Keep in mind that at the end of the mainframe era, some "terminals" had local hardware that could rival a micro-computer.

This is why the X protocol included support for printing, as the printer would be hooked up to the X "terminal" and not the mainframe (DEC had their own wire protocols for talking either to terminals or printers for doing bitmap and vector graphics).

Everything old is new again, and i wonder if i will live long enough to witness some rainbowhaired dev blog (or whatever it will be called at the time) about how they are gleefully ripping out all this cruft from the "soon" to be retired web protocol.

This is what bugs me a lot, when it comes to bugbounties including HackerOne. The absolute lack of accountability and transparency. One can only hope the companies act in good faith. In my opinion this should rather be handled by an independet organisaton like the CERT community or since it's a vital security interest at state level. Though latter might be prone to conflicting interests as well.

I am starting to wonder how many breaches there have actually been of Google user data, they are so secretive and insular it wouldn't surprise me in the least if it has happened multiple times and was covered up.

In the future, as these mega corporations become even larger and more powerful, brave employees who are willing to violate NDAs are the only source of info we will have at all.

If that account is true, this definitively has some "smell" to it...

>To make it clear: I’m not after fame, credits, or want to take some bounty away from @girlswhocode!

Why mention them then, if not to pressure them into refunding the donation?

I assume to call them out. If someone pulls a dick move once and gets away with it. They will do it again. If they get called out they will think twice next time.

The charity had nothing to do with this. They didn't choose to be the recipients of a 'stolen' bounty.

I'm not sure where I mentioned charity?

I wrote an assumption based on what i read in the article.

Or to point out that the researchers’ beef is with Google and Yubico and not the nonprofit? To correct an injustice of two corporations who are collaborating to shaft an independent researcher? There’s a lot of reasons if you give even a shred of benefit of the doubt to the author of the piece.

Reply on news.ycombinator.com