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.
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.
Privacy
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.
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
Adding: i like the crossplatform application part of it, not that an external website accesses my gadgets :)
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…
Just like they did in mr. Robot to drive the woman out of her house
This movie from the 70s comes to mind.
https://www.youtube.com/watch?v=H6O1NRs-YuU
I’m going to go off topic with this one . . . but WOW! What a disturbing manifestation of rape culture this film is. Ugh.
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!
ah, the naivety
also: you’re
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?
I’m sorry but ten years ago if someone said the NSA was collecting data on everything we do online, phone records, SMS and reading post you would have said the same thing only to be proved wrong.
He would have been reading crytpome then. Most of us are old enough to remember carnivore anyway. I like the way you put words in his mouth but your post is misguided and unnecessary, idiot.
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.
We also have an article at https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2 describing the tradeoffs we made in deciding to build Web Bluetooth, and comparing its security to the alternative: installing a native app.
On privacy, we block access to Bluetooth’s “unique, persistent device ID” (actually more than one of them), as described at https://webbluetoothcg.github.io/web-bluetooth/#remote-device-identifiers and https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt#L48. Devices can still intentionally embed a tracking id, but they won’t accidentally expose the ones defined by Bluetooth itself.
Hi Elliot, as for SensorLocation in your image captioned “Not very subtle, Google.”, those values are actually defined by the Bluetooth SIG at https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.body_sensor_location.xml
It isn’t malicious :>
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).
Knock-knock!
Who’s there?
USB.
USB Who?
NAK
Well there’s 249 more locations reserved for future use.
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.
Hmmm how much screwing with your car can it do if you’ve got an ELM 327 installed?
But on the other hand, sites like Autozone etc might give them away free and it will read your car and order you parts.
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.
Yeah its a diagnostic aid not a dead part indicator really. Get an O2 code, you should check your plugs , and “read” those the old fashioned way.
I don’t understand
You mean there are people out there who are concerned with privacy and actually have bluetooth turned on on any device?
Also, AOL is still billing them 29.99 a month and they can’t remember why.
i’m sure it would have been difficult to assure, but if you’d make this one way communication only … .so bt – 2 – chrome .. and not the other way around … who cares ?
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.
So it’s new and we will have to wait and see if it holds up against hackers or if anyone even bothers to really use it. The problem I see is that your basically limited to using Chrome right now.
I believe there is also Opera, and for iOS there is now this app: https://itunes.apple.com/us/app/webble/id1193531073
It’s also part of NW.js which is used for creating native apps based on HTML, and there are some wrapper for it for Node.js.
As you say, we’ll have to see what happens – but I’m quietly optimistic, especially as it seems like the only cross-platform API for BLE that is available at the moment.