In this post I want to talk about a very essential part of my workflow when dealing with Bluetooth devices, particularly IoT devices with a corresponding mobile app: Live capture of Android Bluetooth traffic with Wireshark.

Before you stop reading because you think you know how to do this already, the method does not involve pulling bug reports off your phone, and it does not require root. And most importantly it gives you a live packet log in Wireshark.

Continue reading

This blog post describes the journey of how we discovered an interesting Bluetooth SoC within the Datong NP330, a Printer Server IoT device. Our initial goal was to reverse-engineer and analyze the Bluetooth controller that is included in the device. So we wanted to be able to dump the firmware or, if possible, get shell access on the printer server. During that journey we found a few vulnerabilities that ultimately let an attacker fully compromise the device. This is possible over Bluetooth or network via unauthenticated remote code execution with root privileges.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

In a recent assessment, we were testing a device that offered a Bluetooth interface for data export and configuration. This device uses Bluetooth Low Energy (BLE), and a static passkey (or PIN) is required to pair with it. This passkey is displayed for a few seconds when the device is booted and stays the same on each reboot. In fact, it is derived from static, device-specific data.

Continue reading

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.

Continue reading

On November 3rd, 2019, we have reported a critical vulnerability affecting the Android Bluetooth subsystem. This vulnerability has been assigned CVE-2020-0022 and was now patched in the latest security patch from February 2020. The security impact is as follows:

• On Android 8.0 to 9.0, a remote attacker within proximity can silently execute arbitrary code with the privileges of the Bluetooth daemon as long as Bluetooth is enabled. No user interaction is required and only the Bluetooth MAC address of the target devices has to be known. For some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address. This vulnerability can lead to theft of personal data and could potentially be used to spread malware (Short-Distance Worm).
• On Android 10, this vulnerability is not exploitable for technical reasons and only results in a crash of the Bluetooth daemon.
• Android versions even older than 8.0 might also be affected but we have not evaluated the impact.

Users are strongly advised to install the latest available security patch from February 2020. If you have no patch available yet or your device is not supported anymore, you can try to mitigate the impact by some generic behavior rules:

Continue reading

This blogpost contains summaries of talks from this year’s TROOPERS19 Active Directory Security Track.

Microsoft IT (Secure) Journey to IPv6-Only

Veronika McKillop, Network Architect, Cloud and Connectivity Engineering (CCE)

The speaker, Veronika McKillop, working at Microsofts network infrastructure services, has given a talk about the process of switching a company network from IPv4 to IPv6-only.

Within the talk the following topics were introduced: Dual Stack, Drivers for IPv6, Status of IPv6 in Networks and Security in IPv6 Networks. The talk covers the reasons why a company would like to switch from IPv4 to IPv6. Technics like NAT64 and DNS64 are introduced. The requirements to software and especially drivers to work in IPv6 environments are described. Also the problems to switch from IPv4 to IPv6-only in heterogeneous networks are addressed.

Continue reading