Bluetooth Vulnerability Affects All Major OS

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:

52 thoughts on “Bluetooth Vulnerability Affects All Major OS

      1. 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.

    1. 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?

      1. 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.

        1. 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.

      1. 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.

        1. 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.

      1. 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..

    1. 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.

  1. 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.

  2. 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.

    1. 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..

        1. 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!

  3. 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.

  4. 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?

  5. 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.”

  6. 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.

  7. 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.

  8. 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?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.