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
The biggest limitation at the moment is that there’s still no Windows OS support, although this will of course change in the near future. (iOS support is not officially supported, and installation on Linux requires a Linux user.) This is new stuff.
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.
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 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.