Important note: Some media coverage on this topic falsely or inaccurately depicts the attack conditions. To be clear: Any vulnerable device can be compromised if the attacker is in Bluetooth range. That is the only precondition.
During our research on Bluetooth headphones and earbuds, we identified several vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In this blog post, we briefly want to describe the vulnerabilities, point out their impact and provide some context to currently running patch delivery processes as described at this year’s TROOPERS Conference.
During our recent research, we experimented with different Bluetooth USB dongles. There are tons of options, and sometimes, it’s challenging to determine what chipset a dongle actually contains, what Bluetooth features it supports, and whether it works on Linux. Inspired by the recent ESP32 Bluetooth research, we wondered whether we could turn our Raspberry Pi Pico Ws into a functioning Bluetooth dongle. We had a few lying around, and the advantage here is that we know exactly which Bluetooth controller it uses – the Infineon CYW43439. It’s also very easy to get one. You can just buy the Pico W for a few bucks, even cheaper than some Bluetooth dongles. You also have a controller family that has been researched quite a bit in the internalblue project. However, there was one disadvantage. We did not find any code that exposes the CYW43439’s HCI interface via USB. So we had to write that on our own.
As part of our research into the Auracast feature set in Bluetooth, we also started looking into vendor implementations. At the time we started with our research, there weren’t a lot of products on the market yet. But new products are coming out pretty frequently now.
One of the vendors that had Auracast implemented pretty early was Samsung. At the time the Samsung Galaxy S23 and S24 phones were able to broadcast Audio, while the Galaxy Buds were able to join these broadcasts.
In our previous blog post we analyze the security of Auracast broadcasts. In short, broadcasts can be encrypted by specifying a so-called Broadcast Code (or Passcode). We show that the key derivation used to derive an AES key from the Broadcast Code is not sufficient to properly protect the broadcast. The weak key derivation, combined with the way the encryption works, allows an attacker to perform an efficient offline brute-force attack against captured Auracast packets. However, when the Broadcast Code is chosen properly, this attack can be made very difficult and likely economically unreasonable.
However, we found that the Bluetooth specification is lacking in this regard. Both the specification of the Broadcast Code itself, and the example values given in the specification and other documents are inadequate.
This, in our opinion, inadequate specification and the poorly chosen examples of Broadcast Codes lead us to suspect that vendors may not be aware of the requirements for a secure Broadcast Code.
This is essentially what happened with Samsung’s implementation.
Auracast, the new Bluetooth LE Broadcast Audio feature has gained some publicity in the past months. The Bluetooth SIG has introduced the LE Audio feature-set to the Bluetooth 5.2 Specification in 2019 and vendors are only now starting to implement it. Auracast facilitates broadcasting audio over Bluetooth LE to a potentially unlimited number of devices. It does not require pairing or interaction between the sender and the receivers.
We also presented this topic at 38c3. This blog post will contain similar contents albeit with some more details.
Using a static passkey for Bluetooth Low Energy pairing is insecure. Recent versions of the Bluetooth specification contain an explicit warning about this. However, in practice, we often see static passkeys being used. Moreover, there are no public implementations of proofs-of-concept that can practically show why using a static passkey is an issue. This is why we implemented one.
Nowadays, Bluetooth is an integral part of mobile devices. Smartphones interconnect with smartwatches and wireless headphones. By default, most devices are configured to accept Bluetooth connections from any
nearby unauthenticated device. Bluetooth packets are processed by the Bluetooth chip (also called a controller), and then passed to the host (Android, Linux, etc.). Both, the firmware on the chip and the host Bluetooth subsystem, are a target for Remote Code Execution (RCE) attacks.
One feature that is available on most classic Bluetooth implementations is answering over Bluetooth pings. Everything an attacker needs to know is the device’s Bluetooth address. Even if the target is not discoverable, it typically accepts connections if it gets addressed. For example, an attacker can run l2ping, which establishes an L2CAP connection and sends echo requests to the remote target.
In the following, we describe a Bluetooth zero-click short-distance RCE exploit against Android 9, which got assigned CVE-2020-0022 . We go through all steps required to establish a remote shell on a Samsung Galaxy S10e, which was working on an up-to-date Android 9 when reporting the issue on November 3 2019. The initial flaw used for this exploit is still present in Android 10, but we utilize an additional bug in Bionic (Android’s libc implementation), which makes exploitation way easier. The bug was finally fixed in the security patch from 1.2.2020 in A-143894715. Here is a demo of the full proof of concept:
Recently we posted first part of our Bluetooth research diary. Today, we want to continue on that topic and tell you about Bluetooth proxying and packet replay with a new tool.
This time we had a new gadget to play with: our colleague Florian Grunow shared with us a curious IoT device – Bluetooth socks… real socks that you control with an app to heat your feet. The future is here… 😉 Continue reading “Research Diary: Bluetooth. Part 2”
As you probably know we perform research on a regular base at ERNW.
We – Olga and Rafael – started with a research project about Bluetooth. Our first goal was to gain some knowledge about the tools used by most Linux systems to communicate with Bluetooth hardware, such as BlueZ. A good help for that was the amazing Bluetooth hacking workshop we had before (check the link in our blog!)
