Web Bluetooth: The New Hotness and Its Dangers

Google’s most recent Chrome browser, version 53, includes trial support for Web Bluetooth, and it’s like the Wild West! JavaScript code, served to your browser, can now connect directly to your Bluetooth LE (BTLE) devices, with a whole bunch of caveats that we’ll make clear below.

On the one hand, this is awesome functionality. The browser is the most ubiquitous cross-platform operating system that the world has ever seen. You can serve a website to users running Windows, Linux, Android, iOS, or MacOS and run code on their machines without having to know if it’s a cellphone, a desktop, or a virtual machine in the Matrix. Combining this ubiquity with the ability to control Bluetooth devices is going to be fun. It’s a missing piece of the IoT puzzle.

On the other hand, it’s a security nightmare. It’s bad enough when malicious websites can extract information from files that reside on your computer, but when they connect directly to your lightbulbs, your FitBits, or your BTLE-enhanced pacemaker, it opens up new possibilities for mischief. The good news is that the developers of Web Bluetooth seem to be aware of the risks and are intent on minimizing them, but there are still real concerns. How does security come out in the balance? Read on.

Nothing New, Everything Changes

Of course you could just write a Bluetooth LE application. But then your users have to be able to install it on their computers, on their phones, and on whatever other platforms people will be using in three years — perhaps the dashboard of their flying cars. Web applications are delivered to and deployed on your browser between those funny <script> tags with a click. They run anywhere you can install a browser, and there’s nothing easier.

For home automation applications, this is huge. The same app, a web page, will deploy on your phone and your computer. We can envision reactive websites and cool local controllers. And of course, the opposite — the physical world can react to websites. Web Bluetooth will provide a level of integration in the IoT scene that we frankly hadn’t even thought of, and web designers are salivating at the prospect of getting their bits out into the real world.

For Hackers: Some Assembly Still Required

For us, right now, the new release of Chrome comes with a handy BTLE device debugging console. If you can write JavaScript, and are willing to jump through some install hoops, you can take advantage of this right now. (There are tons of samples and demos at the bottom of the page.) It looks like the browser is going to be the most friendly BTLE development environment around.

What Could Go Wrong?

There’s been a lot of thought put into the new types of threats that Web Bluetooth will open up. If you’re really interested, you should read through the Web Bluetooth draft group report’s security section yourself.

The obvious threats are old news. Attacks like cross-site scripting (XSS) that have been around since forever will be given a new arsenal. If your browser trusts a given server that’s vulnerable to XSS, anyone on the Internet could be connecting to your device. Because of the special sensitivity and power of physical devices, however, web exploits will become real-world exploits.

Privacy

Not very subtle, Google.

Web Bluetooth will expose more information about the user to the Internet, and the large monopolistic companies that serve as its gatekeepers will profit at the expense of our privacy. Build a BTLE LED that lights up when you have new Gmail? You’ll have to give permissions to Google. Since Bluetooth devices have a unique, persistent device ID, you can be pretty sure that Google will use this information to track you online, because that’s their business model.

We could just as easily worry about Facebook, especially given their hypocritical (and predictable) about-face on Whatsapp last month. Want to augment your Oculus VR experience with your FitBit? Now Facebook can correlate your heartbeat with which news stories you’re reading or which pictures of your friends you’re viewing. They’ll do it — no conspiracy theory required.

If we hadn’t already lost (or given up entirely on) the battle for privacy online, this would matter. You will be fingerprinted and tracked using Web Bluetooth, more precisely and more persistently than ever before: running in an incognito window or refusing cookies won’t change the physical token attached to your computer. Web Bluetooth runs both ways, connecting the physical world to the web as well.

The Device Itself

Finally, we don’t think it’s too much to assume that many BTLE devices are insecure. The protocol is still fairly new, and it’s significantly more complicated than USB which still makes our head spin. The security models underlying BTLE were developed with only local attackers in mind because it is a short-range radio protocol. Web Bluetooth opens BTLE up to all of the baddies out on the Internet, which is a significantly different threat. It’s a good bet that the cheap devices just won’t be designed for it. Even some of the expensive ones will fail.

Take the example of an IP-based child-monitor camera that’s relatively safe when it’s confined inside the firewall of your home router. We all know what happens when they jump out to the broader Internet. It’s probably not a big deal that someone can run a replay attack on your BTLE front door lock — they’d have to be in the neighborhood when you’re using the transmitter to compromise it. It’s totally a big deal when everyone who hits a website gets scanned. (Note: assumption of XSS or other web exploits here.)

The Solution?

The solution proposed by the Web Bluetooth group is basically to ensure that the browser makes sure that the user knows what devices are pairing and which services they’re exposing. This means clicking on popup dialogs. While empowering the user is probably the best way to go, it’s still imperfect.

Limiting the device to known services is great, but if the device itself is buggy, an intruder might be able to find a workaround. When a BTLE device requests an unknown service, there will be a pop-up so that the user can deny it. How many people are going to click “no” when they really wanted to control their (malicious) BTLE lightbulbs? How many users are going to worry about their eroding privacy, for which there is no popup?

It’s not too harsh to say that the most of the users out there are uninformed about the new attack surface of Web Bluetooth, and thus unable to make the decision rationally. Heck, we were uninformed just a week ago. And this all assumes that there will be no bugs in the browser, acting as the user agent in the authorization. Shoving all of the responsibility to the user seems a bit like passing the buck. They’re all just going to click “OK” all the time. That’s lousy, but we can’t think of anything better.

The Unknown Unknowns

All of the above is concerned with malicious webpages using the browser to take over your Bluetooth. The idea that bad Bluetooth devices could compromise browsers isn’t on the radar yet. We’re not even exactly sure how this attack would work — maybe a buffer overflow in handling BTLE data? — but we’re sure that some enterprising hacker out there will find a way and write the requisite firmware. Pull this off and you earn a genuine Hackaday Pat-on-the-Back, or a job at a three-letter agency. Your choice.

“With great power comes great responsibility.”

Web Bluetooth should become mainstream in a year or so. We’ll see BTLE become a lot more useful as it becomes simpler to write applications that interact with BTLE devices simply because they are web applications. You can try it out now, if you’re willing to jump through some minor hoops. It sounds like a lot of fun.

Those of you with a security mindset should also have a field day with Web BTLE, and frankly the more eyes on it now the better. (Google pays well for bug bounties.) It adds cool new weapons to old exploits, so you can get creative. The one thing we haven’t figured out is how to get our privacy back.

29 thoughts on “Web Bluetooth: The New Hotness and Its Dangers”

I like the idea of a cross platform solution to talk to devices (bluetooth or HID-usb).

Last time (more then a year ago) I checked the HID-USB access you could only use it in chrome app. That app must first authorized to use USB before it worked. Kinda like apps on smartphones. Never got it reliable to work though

So how long will it be before someone writes a script to attack “Smart” houses and manipulate the lights, door locks, alarm, speakers, etc. and turn it into a “Haunted” house? That would be great for psychological warfare… Why fight rival companies when you can just drive their CEO’s to madness…

Unfortunate to read about all these “threats ” about Web Bluetooth especially on a site like Hackaday. Seriously, unless your Donald Trump, a $$$ corporation , no one really cares about messing with your information. So just play with it and have fun!

Yea, I’m glad to see your post. I feel like an era of “maker” optimism on HaD has been replaced by edgy posts and editorials lashing out wildly at established developers and technologies in an attempt to stay relevant.

I understand the security risk and concern, but an article like this needs examples of a job done right rather than hypotheticals worded so vindictively. Why can’t we have fun here anymore?

You call me an idiot for putting words in his mouth, Then to prove your point you do exactly the same by saying “He would have been reading crytpome then” So who is the idiot?
and since we are doing the whole evaluation of posts thing.
Your post is contradictory and lacking in general but I’ll give you an A+ for effort.

Malicious, no. Hilarious, yes. I’ve always been so disappointed there isn’t a rectal location on the body sensor profile. Other and Unknown don’t have the same panache.

Also, I find BLE to be quite simple generally speaking. USB HID is a steaming mass, those descriptor reports are murderous. I also !love that you can either get all of your data sometime, or some of your data all the time, but not both (bulk vs iso).

Of course they’re not “malicious” any more than Google’s and Facebook’s like buttons that pop up everywhere and track your web browsing, correlating it with your personal account if you happen to be logged in to any of their services at the time.

My point was just that, as it stands, my current heart rate is not among the data points that those companies are able to get on me. But it is most definitely the creepiest of the data that they _will_ be trying to collect.

I guess this is a good thing because of the shift into the ‘cloud’ means that what you could do on your own computer before you now can do on someone elses computer far away and pay them for the privilege.
saying that i must be an idiot because i have never ever successfully managed to pair two bluetooth devices in my entire life, there is always some kind of problem.

The mischief factor is relatively low until an enterprising individual starts using the CAN lines, which I’m not sure the ELM327 can do. More like your insurance company using it for a blackbox and boosting your rates every time you go too fast. But those are already out there. You can get vehicle speed, throttle position, and a few other tattletales pretty easily.

ELM327s are pretty much read-only, and OBD-II messages are vague enough in my experience that a CEL could me any number of things, so I’d end up with a whole bunch of bogus shipments from the Zone (or RockAuto!). I’ve had it point to exactly the right part once across 3 cars from 3 makers.

Erm, I’ve actually implemented a WebBluetooth device and the security is fine. Connection attempts have to be initiated in a click handler (which can be worked around) but also the user has to select the device from a pop-up dialog.

This article is just ignorant fearmongering. Learn a bit more about it before you denounce it.

Web Bluetooth has had a lot of thought put into security. Saying “well they might just click through the dialog” is just a cheap shot. If you assume that the user will randomly click whatever dialog appears without looking at it then you can get them installing a native app and from there you can do whatever you want.

What this *actually* means is device manufacturers will be able to write a single web app that runs in the browser’s standardised, well-proven and constantly updated sandbox, rather than at least 4 (Android, iOS, Windows, MacOS) buggy, poorly maintained native applications that run outside the sandbox and which could contain all kinds of hideous security issues.

Web Bluetooth can’t hit mainstream soon enough as far as I’m concerned. I can’t wait to ditch all the apps using up my phone’s Flash and running in the background.