By Ian Stroszeck
No Personally Identifiable Information (PII) was collected in the act of research for this assignment. Scanning Bluetooth Low Energy frames from Apple devices has an inherent risk in potentially intercepting data that could have information such as MAC addresses, hashes of phone numbers and other device-specific information. Reasonable measures were taken to ensure that I would not collect, harvest, or retain any personally identifiable information. Replication of this study in full or in part is done at your own risk. Don’t be stupid!
From Apple’s own website, they state that privacy is one of their core values. This makes the privacy concern originally discovered by group of security researchers called Hexway even more concerning. According to the group, information such as the MAC address down to the current state of the device, OS level and even phone number can be accessed simply by sniffing for through the unencrypted Bluetooth Low Energy traffic emitted from most modern Apple Products.
I was able replicate the work of security research groups Hexway and FuriousMAC, who analyzed and researched in detail the formatting of the BLE packets sent by Apple devices. In the process of my own research, I discovered that Apple has still not yet fixed this privacy concern, which was raised in March of 2019. Given the usefulness of sending certain device information as part of Apple’s continuity features, it is likely that these issues may not ever be fixed.
Bluetooth is a wireless short-range radio communication technology that has been around for decades. Originally adopted in 1998 by the Bluetooth Special Interest Group (SIG), the Bluetooth standard was designed originally for wireless headsets by Swedish inventor, Johan Ullman. Over time, the technology was standardized into IEEE Standard 802.15.1, which has since been superseded as the technology has changed.
Over time, as improvements were made to the standard to increase range and throughput while decreasing battery usage, Bluetooth was split into several different core configurations, namely Basic Rate (BR), Enhanced Data Rate (EDR), and Low Energy (LE). BR/EDR, as it’s usually referred to, is the older configuration that is what people traditionally think of when they think of Bluetooth. BR/EDR were effectively the two main configurations of Bluetooth up until version 4. Bluetooth as a whole is operated at the 2.400-2.4835 GHz band with 80x 1MHz channels for BR/EDR and 40x 2MHz channels for LE.
Bluetooth Low Energy, also known as Bluetooth Smart, was implemented as part of the Bluetooth v4.0 specification in an effort to better tailor the standard towards more Internet of Things (IOT) applications, as well as for other novel uses. As the name would suggest, BLE was intended to offer a similar range, compared to standalone BR/EDR while requiring considerably less power to operate. The first phone to have a built-in capability for BLE (Bluetooth v4.0) was the iPhone 4S, released in 2011.
Since the release of Bluetooth v4.0, the technology has been integrated almost everywhere– from phones, to watches, to fridges, toasters, headphones and more. Coupled with its low energy usage, Bluetooth v4.0 has been an easy choice when deciding how to best interface smartphones with an array of IOT devices. However, this near ubiquitous usage has caused some concern for the potential privacy and data protection implications that come along with the ways in which the technology is sometimes implemented and used.
PROCESS & RESEARCH
My research started by accident while attending ShmooCon 2020. After listening to a talk being given by a group known as FuriousMAC about the Apple Continuity Protocol and some reverse engineering they did on Apple’s implementation of BLE, I wanted to check this potentially huge privacy concern out for myself.
In doing some cursory research about Apple’s implementation of BLE, I found some other projects that had also looked at BLE and utilized some of their open-source work to ascertain whether or not the problem still existed.
To start, here is a table of the software and hardware that I used for both analyzing the BLE traffic and the devices I used for testing:
|Analysis Tools||Testing Devices|
|Wireshark (2.6.3)||Apple iPad Air (iOS 12.4.6)|
|Apple_bleee||Apple 1st Generation Airpods|
|hcitools & related built-in programs|
|Kali Linux (2018.4)|
## Clone Apple bleee repo
git clone https://github.com/hexway/apple_bleee.git && cd ./apple_bleee
apt install -y bluez libpcap-dev libev-dev libnl-3-dev libnl-genl-3-dev libnl-route-3-dev cmake libbluetooth-dev
sudo pip3 install -r requirements.txt
git clone https://github.com/seemoo-lab/owl.git && cd ./owl && git submodule update --init && mkdir build && cd build && cmake .. && make && sudo make install && cd ../..
## Set up ubertooth
apt-get install ubertooth
# For VMware: VM > check "USB 3.0" and uncheck "Share bluetooth with host device"
systemctl enable bluetooth.service
systemctl start bluetooth.service
hcitool dev # Checks to make sure that the embedded bluetooth device is working
## Capturing BLE in Wireshark
# Wireshark > Capture > Options > Manage Interfaces
# New > Pipe > type "/tmp/pipe" > Save
ubertooth-btle -f -c /tmp/pipe
# Back to Wireshark > Edit > Preferences > Protocols > DLT_USER
# Edit (encapsulations table) > New > Under DLT, "User 0" > Payload > type "btle"
After doing this, I started analyzing some traffic first, in Wireshark. After a little bit of digging, I tried to replicate the environment where it was stated that the public MAC address would become visible. Without much effort, I was able to search for the MAC address of my iPad and subsequently found multiple BLE packets from the device.
As was stated in the report by FuriousMAC, the MAC address of the Bluetooth device was still viewable, even though according to Apple, all iOS devices are supposed to engage MAC address randomization.
Next, I wanted to see what kind of traffic I could gather from the Apple bleee scripts. At first, I wasn’t able to get any hits by any devices. After further inspection, I realized that when a virtual machine (like Kali linux was currently set up as) is running, it by default shares the Bluetooth adapter with the host machine, which forces all communications to go through the host machine. I figured this out by trying to manually connect my iPad to the kali VM, but instead of Kali responding, my Windows 10 machine would accept the request instead. I realized that I needed to connect the adapter solely to my VM, which was done by modifying the settings of the VM itself.
Upon further research, I found out that VMware imposes a limitation on Bluetooth support by only allowing out-going connections when in “shared mode”. This meant that I could not advertise my kali machine directly to remote devices, nor would I be able to connect to them, therefore causing my issue.
Once my VM issue was solved and I started up the ble_read_state.py script to see if now, I would get any hits. Lo and behold, I did! …but not from my iPad..
As you can see, using the built-in Bluetooth chip in my PC (not my Ubertooth), I discovered that the issue still existed! From the picture, there are 3 iPhones listed, which presumably must have been from my neighbor’s house next door (since I’m back at home due to COVID-19). Using the script, I can still ascertain the state of the device, the device type, OS, and other information.
Strangely, the one thing I was not able to reproduce was probably the biggest find by the original researchers, which was the phone numbers, which should have appeared in the column 2nd from the right. My thought is that since I did not have the database available to set up the hashing computation and have it properly connected to the read state script, this is likely the reason that this data was not available.
For part 2, I tried to emulate the Airpod spoofing that was also part of the Hexway GitHub repository. Again, after a bit of trial-and-error, I was able to successfully replicate the spoofing on my iPad.
Overall, after researching the Bluetooth standard and spending most of my time trying to get the dang setup properly working in my VM, I didn’t have as much time to go into a deep dive into the Wireshark traces and analyze the individual flags and try to correlate them to specific states, as was shown by furiousMAC. However, from my rudimentary analysis using the knowledge I did have and the tools at my disposal, I was able to conclude that the public MAC address advertisement still exists and that Apple devices still transmit considerable amounts of data about themselves to anyone who is looking. Seems pretty contrary to Apple’s whole ideology around privacy. Perhaps this is the balance necessary between ease of use between Apple devices and security.