Security researchers from Armis Labs recently published a whitepaper unveiling eight critical 0-day Bluetooth-related vulnerabilities, affecting Linux, Windows, Android and iOS operating systems. These vulnerabilities alone or combined can lead to privileged code execution on a target device. The only requirement is: Bluetooth turned on. No user interaction is necessary to successfully exploit the flaws, the attacker does not need to pair with a target device nor the target device must be paired with some other device.
The research paper, dubbed BlueBorne (what’s a vulnerability, or a bunch, without a cool name nowadays?), details each vulnerability and how it was exploited. BlueBorne is estimated to affect over five billion devices. Some vendors, like Microsoft, have already issued a patch while others, like Samsung, remain silent. Despite the patches, some devices will never receive a BlueBorne patch since they are outside of their support window. Armis estimates this accounts for around 40% of all Bluetooth enabled devices.
A self-replicating worm that would spread and hop from a device to other nearby devices with Bluetooth turned on was mentioned by the researchers as something that could be done with some more work. That immediately reminds us of the BroadPwn vulnerability, in which the researchers implemented what is most likely the first WiFi only worm. Although it is definitely a fun security exercise to code such worm, it’s really a bad, bad idea… Right?…
So who’s affected?
It is difficult to provide a comprehensive list of all affected devices. All unpatched Windows systems from Vista and up: Microsoft secretly released patches in July for CVE-2017-8628. All Linux devices running BlueZ are affected by an information leak and all Linux devices running kernel version 3.3-rc1and up (released in October 2011) are affected by a remote code execution flaw. All Android phones, tablets, and wearables of all versions are affected, except for those which use only Bluetooth Low Energy. Google patches were issued in the September Android Security Bulletin. iPhones, iPads and iPods devices running iOS 9.3.5 and lower and AppleTV devices with version 7.2.2 and lower are affected. Linux-based OSes are likely to be affected, for instance Samsung Tizen OS. I know my Samsung Galaxy S8 is, or so the Android app that the researchers published shows.
It is probably a good idea to check and apply the latest patches available for your favourite devices, especially if they are mobile and you carry them everywhere with Bluetooth on. That being said, the obvious solution is to turn off Bluetooth. This is probably something you already do in order to save battery. Unfortunately, this might not be possible for everyone, especially those who heavily rely on Bluetooth devices, like hands-free, for example.
Meanwhile, enjoy the demo:
While this is terrefing you most but very close to have a stable bluetooth connection right?
With right antenna – up to a kilometer or so. Also – think airports/shopping centers/etc.
PS. Google bluesniping
Long distance injection of Bluetooth packets is possible but long range reception is a lot different. The antenna in a standard device and the transmit power really limits how far amy exploit will go. Bluetooth was never meant for long range communication.
No, just no. Do you understand how antenna gain actually works?
Do you understand how transmitter power works? Sure I can send a packet you will receive from a transmitter of 1MW, can I see your ACK from your 25mW transmitter?
Are we talking about transmitter power here?
with out of band transceivers anywhere in the universe..
Like everyone in your coffee shop, office, train car, bus, or the vehicles around the attacker sitting in traffic?
Wait a minute now …
The attack requires that you can listen to Bluetooth in “promiscuous mode”. That is, we want to capture data that is not for us (most likely, data traffic between the victim’s phone and the victim’s headphones). This to capture “BDADDRs”, a requirement for the attack to work. See page 7.
We remember “promiscuous fashion” from the time when wardriving was a thing. We also remember how hard it was to get exactly the right hardware (preferably with external antenna connector) and exactly the right driver to work. Took hours. I do not know how many WiFi adapters I bought on Ebay. At least 10.
If there is no connected Bluetooth device that generates data traffic (ie 99.8% of all mobile phones) then you should “capture the WiFi MAC address and guess it”. Ahh … yes … just that.
The researchers use special hardware (quite expensive) for this and a laptop with linux. Already the price and skills required limit the usability of the attack.
I’m having trouble seeing a software that can do the same on random hardware. Or any other hardware at all … apart from what’s in the researchers lab. How many phones have athero’s ar9285 chip today?
google translate… *facepalm*
Just wait until there appears an Arduino sketch to ESP32 to do it. Wifi sniffer code for ESP32 exists already.
Have they made the exploit code available yet? Or have there been any implementations in Kali Linux?
He’s asking for a friend.
Yeah that’s the one ;). I’m a white hat security analyst. Would be useful for Digital Forensics acquisition of devices etc..
I bet there are more.. Researchers kind of abandoned BT stacks almost a decade ago even though they have a massive market..
BT stacks have a reputation of being crappy (even the pay ones) so no big surprises here.
makes me think of the intel curie aduino 101. its EOL, intel abandoned it and its unlikely to get any security updates. when I worked with that board, intel did not even have BT to BT working (arduino to arduino); you could only talk to phones and pcs/macs. the obvious use-case of controller to controller didn’t even hit their radar and they never implemented it.
I never liked bt or trusted it. ble is even worse, its got such an ugly conceptual api!
the sooner we kill bt and replace it with a real networking stack, the better.
Sorry to kind of derail, but I avoided the Curie because I thought Intel would EOL it early. It did, seemingly because they didn’t get the support they wanted. I wonder who else thought the same? I think Intel has a reputation problem among makers they just made a whole bunch worse with Curie.
Old news to some of us
:)
Source? I’m not aware of any other recent Bluetooth stack research..
Some people see the corporate dumpster fire that is the BT API, and disabled it years in advance.
It has been broken many times in the past.
Just like Systemd, the attack surface is too wide to reliably secure the OS layer.
There will always be unintended operational modes caused by updates to a highly coupled code base — thus cool buzzwords like 0-Day.
If they “found 8”, than there are probably 64 they didn’t find yet.
never heard of systemD 0 day. source?
https://vignette.wikia.nocookie.net/en.futurama/images/a/ac/Boneitis.jpg/revision/latest?cb=20100925103612
Surely the PlayStation 3 and 4 are susceptible to similar attacks they use Bluetooth hardware for controllers.
Think the Logitech Unifying receiver is related to BT.
false. its 2.4ghz but its clearly NOT bluetooth. its a proprietary rf dongle and not BT. BT would be a license/cost issue and you don’t want that unless you HAVE to show a bt icon/logo. plus, bt is hella complicated and bad for battery life. proprietary rf does not have those issues, usually.
https://lekensteyn.nl/files/logitech/
https://www.google.com/patents/US8386651
Unfortunately nothing seems to get to the hardware layer which would tell if one could be hacked to BT.
If you’re thinking about jailbreaking it’s not needed.. bootldr is defeated on PS3 and can’t be patched(100% of security killed forever), PS4 is x86 and FreeBSD and people already have code exec..
x360 and xone have better security. It’d have to be able to write DMA because that’s the only thing not cryptographic protected in RAM on those..
In ‘certain’ circles this has been well known and preventive measures taken to mitigate the damage possible.
Sometimes a fortunate accident allows the creation of an application ‘feature’ which isn’t understood by the customer but can be leveraged to give a competitive edge over competition.
Surely you can figure out the possibilities.
So much $$ to be made with this one.
So basically every vulnerable device is accessible in r/w mode. People can, after getting caught with prohibited data on their devices, say that it was probably planted by some third party. If a bt worm is ever created, it can use certain public spaces as a dead-drop for whatever sensitive (encrypted) data. A high enough concentration and amount of people present would allow for the payload to stay available at the location (or propagate from device to another) for the intended recipient to receive and decrypt it at his leisure. The same mechanism can be used to plant data on the devices and frame people. No go explain to your wife why you have pictures from job when you were supposed to be golfing.
Shhh
The video shows the attacker gaining shell access. Fair enough, remote shell is whithin UNIX-like OS “hacking possibilities”.
How does that possibly work on Windows OS?? I’ve readed the paper and it explains BNEP abusing etc, but cannot see how an (elevated) command prompt be obtained that way. Also kudos to Microsoft for being fast to fix this vulnerability. A couple years ago that would be an hilarious joke, mind you.
It effects the MS BT stack driver in vanilla Windows. Getting SYSTEM or Administrator CMD.EXE or reverse-shell from ring 0 isn’t exactly a challenge..
A better question is how does it work against stuff like CET, PDF, SMAP, SMEP etc..
Sorry to remove some of the Kudos for Microsoft (and let’s be honest they don’t have much give away) but there is a fix for Linux https://unix.stackexchange.com/questions/392001/how-do-i-secure-linux-systems-against-the-blueborne-remote-attack
Also true. And Debian insists that the release that currently runs the Pi3 happens to be fixed.
I also noticed that it seems they’ve forgotten to cite as support for their fixed claim as also found on Slackware 14.2 both arches.
I wouldn’t call disabling all bluetooth permanently a fix…
Yeah WIFI does basically the same thing.. Replace audio protocols with HTTP or icecast streaming or RTSP etc..
If you had read the whole page that I linked, you would have seen that disabling the bluetooth stack was something that you could do if you were not in a position to install the patches linked within the same article!
So no fix for my Palm LifeDrive and Tungsten E2? :P ;)
Let’s all point and laugh at all of those who mock the 3.5mm jack!
All major, and derivative, Linux distributions should already have the available patches applied. As usual the real problem is the systems that are not maintained, or can’t be updated such as a huge number of cheap android phones from Chinese manufacturers who offer amazing value for money but very little long term support. I recently asked about updated firmware on one companies forums only to see my post removed. There needs to be a legal remedy for this or all of these compromised devices will become gateways for attacks on otherwise secure networks and systems that are connected to them in some way.
The paper says that linux does not use kernel space address randomization, which is, to my knowledge, false for all desktop distrib and android (it was indeed not used on the wifi chip in the case of broadPwn, which was one of the main flaws that allowed the worm to exist). As I understand it, each starting address of each lib and each program is randomized, which means you can’t reliably know how much the buffer should be overflowed (but inside of the programs’ space, it is not randomized on non patched kernels).
The paper does not explain how they go from buffer overflow to remote code execution, at least on linux. Does it seems clear to someone?
That’s why one shouldn’t run non-critical software in kernel mode. Microkernels FTW again!
Another reason I need to replace my Mac’s Bluetooth keyboard with a wired one. And also another illustration of Apple’s stupidity at trying to make all their users go wireless—as by removing the headphone jack from iPhones. Law One of electronics is “Never go wireless when you can have a wire.” Wireless means no security.
Apple’s old slogan, “Think Different,” seems to have been replaced by “Think Stupid.”
Wireless can be as secure as a wire though not as reliable. Wireless can always be jammed, to jam a wired connection one need serious power e.g. a nuclear weapon.
Or a pair of scissors.
It NEVER fails that there’s someone ready to leap at the chance to shit on Apple without even knowing the facts.
“Apple had no vulnerability in its current versions” – https://www.armis.com/blueborne/
People running outdated iOS software may be vulnerable, provided their bluetooth is enabled. No mention of the Mac.
This is such bullshit.
There isn’t a single flaw that affects all OSes. There are several totally different flaws. And having Bluetooth turned on isn’t they only requirement. For the worst flaw – RCE on Android – you have to be using Bluetooth internet connection sharing.
So, can you turn off bluetooth on all devices, such as automobiles?
What about V2V? When people finally wake up to the security flaws there, will the ability to turn off V2V communication be mandated? One can hope, but I wouldn’t bet on it.
Anything that is wireless can be hacked, as can anything that is wired to the net, as can anything that has swappable devices or data carrier attached to it
OK then.
I guess the best way to deal is to hide or spoof?