Users value their privacy, and Apple understands that. We even see related PR activities.
"What happens on your iPhone, stays on your iPhone." Let's see if it's true.
TL;DR
If Bluetooth is ON on your Apple device everyone nearby can understand current status of your device, get info about battery, device name, Wi-Fi status, buffer availability, OS version and even get your mobile phone number
Introduction and motivation
Apple devices are appreciated for the ecosystem that connects them all. It really is very convenient to start using an app on one device and continue on another. Plus, you still have access to your files even when you're offline. It seems to contradict the "What happens on your iPhone, stays on your iPhone" policy, doesn't it?
So, let's find out how Apple's privacy actually works.
Wireless. Wireless everywhere.
If you want to share a photo with a friend of yours, how does your iPhone know that it's actually their device nearby? How does your MacBook see you've run Safari on your phone? The answer is quite simple: Bluetooth and Wi-Fi. Apple devices constantly send out large data packets via Bluetooth LE. Even if you're not currently using your iPhone, communication still takes place.
In this research, we've analyzed what kinds of data we can obtain by listening to Bluetooth LE frequencies.
Nearby
Let's consider a simple attack scenario. What an attacker could find out if they're were in the same subway car with you?
We know that your phone sends lots of data via BLE even when it's on hold. It includes phone status, Wi-Fi status, buffer availability, OS version, and so on. The same goes for your MacBook, Apple Watch, and AirPods.
See how it happens.
AirDrop
AirDrop is a technology that allows Apple users to share files without Internet access. There's no registration, and the service is anonymous and secure. Or is it? We already know that it's possible to receive unsolicited content while taking a sub and that Generation Z uses AirDrop to cheat on exams.
Well, AirDrop seems to be less anonymous than we thought. It's possible to identify you: your phone sends out SHA256 your phone number hash to all the devices around you every time you hit Share.
Here's what an attacker could do:
- Create a database of SHA256(phone_number) : phone_number for their region; e.g., for Los Angeles it's: (+1-213-xxx-xxxx, +1-310-xxx-xxxx, +1-323-xxx-xxxx, +1-424-xxx-xxxx, +1-562-xxx-xxxx, +1-626-xxx-xxxx, +1-747-xxx-xxxx, +1-818-xxx-xxxx, +1-818-xxx-xxxx)
- Run a special script on the laptop and take a subway train
- When somebody attempts to use AirDrop, get the sender's phone number hash
- Recover the phone number from the hash
- Contact the user in iMessage; the name can be obtained using TrueCaller or from the device name, as it often contains a name, e.g., John's iPhone).
Just watch the demo!
Wi-Fi password sharing
Another thing Apple users can do is share Wi-Fi passwords. You just have to choose a network from the list, and your device will start sending Bluetooth LE requests to other devices asking them for the password. How does your friend know that the person requesting a password is you? Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email. Only the first 3 bytes of the hashes are sent, but that's enough to identify your phone number (actually, the number is recovered from HLR requests that provide phone number status and region).
Is it possible to make the victim's device try to connect to a Wi-Fi network and thus force it into sending BLE requests? That's an open issue.
Watch the demo!
Bidirectional
As you know, an iPhone not only sends a lot of BLE requests but also receives them. This can be used by an attacker to disguise themselves as a certain device.
For example, as AirPods
or a friend's phone, to get the password to the corporate Wi-Fi
Protection
This behavior is more a feature of the work of the ecosystem than vulnerability.
We've detected this behavior in the iOS versions starting from 10.3.1 (including iOS 13 beta).
Unfortunately, the only thing you can do is to turn off Bluetooth on your device.
But also we noticed that the old devices (like all before iPhone 6s) are not sending BLE messages continuously even if they have updated OS version. They send only limited number of messages (for example when you navigate to the Wi-Fi settings menu) probably Apple does that to save battery power on an old devices.
PoCs
You can find all scripts in our GitHub repository: Apple bleee
Links
Here are links to resources about the protocols used by Apples devices:
In this article, we will outline our research process, from our initial ideas to first POCs. Technical specialists may find this interesting.
You can proceed reading or download whitepaper here
What if…
Let’s take a look at the BLE traffic. For this purpose, we’ve slightly modified the scripts from py-bluetooth-utils repository
Unlock the phone and run the BLE sniffer.
python ble_adv_search.py -m 54:69:F1:23:2B:47
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
...
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
...
Turn the phone off.
...
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c0010050b1c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c001005031c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c001005031c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c001005031c0fc556
[54:69:F1:23:2B:47] 0e02011a0aff4c001005031c0fc556
...
We can see that only one byte reflects the change in screen status. Apple uses ADV_IND messages to send out current status data.
That’s the structure of a typical advertise data packet:
0 1 2 3 4
+---------------------------------------------------------------------------+
| |
| Access Address |
| |
+------------------------------------+--------------------------------------+
| | |
| Header | |
| | |
+------------------------------------+ |
| |
| Advertising Address |
| |
+-----------------------------------------------------------+---------------+
| | |
| Length/Type(0x01)/Flags | Length |
| | |
+---------------+-----------------------------------------------------------+
| | | |
| Type(0xFF) | Company ID(0x004c) | Message type |
| | | nearby/airdrop|
+-----------------------------------------------------------+---------------+
| | |
|Message Length | Message data |
| | |
+---------------+-----------------------------------------------------------+
Turning the phone on and off, navigating the menu, changing settings and running different apps (phone, calendar, photos, settings), we’ve identified the fields responsible for the Wi-Fi and buffer status and several types of BLE messages.
0x05 - Airdrop
0x07 - Airpods
0x10 - Nearby
0x0b - Watch Connection
0x0c - Handoff
0x0d - Wi-Fi Settings
0x0e - Hotspot
0x0f - Wi-Fi Join Network
Nearby
That’s a Nearby message:
0 1 2 5
+--------+--------+--------------------------------+
| | | |
| status | wifi | other |
| | | |
+--------+--------+--------------------------------+
where status can be:
0x0b - Home screen
0x1c - Home screen
0x1b - Home screen
0x11 - Home screen
0x03 - Off
0x18 - Off
0x09 - Off
0x13 - Off
0x0a - Off
0x1a - Off
0x01 - Off
0x07 - Lock screen
0x17 - Lock screen
0x0e - Calling
0x5b - Home screen
0x5a - Off
That’s enough to write a simple packet analyzer that allows us to get data from all nearby Apple devices in real-time.
To analyze the BLE packets further, we chose to use Adafruit Bluefruit LE Sniffer that helps analyze the Wireshark BLE traffic.
Wi-Fi password sharing
Then, we analized how users are identified when two devices interact.
This process is used for connecting to Wi-Fi.
While trying to connect to a network, the device sends the following BLE packet:
c03080fc5563125c9d087555a77e3e2005f10020b0c
Trying to connect to various SSID on different devices (yes, we could’ve just reversed sharingd in IDA/radare/gydra) we found out that this message has the following format:
0 1 2 5 8 12 15 18
+--------+-------+------------------------+-------------------------+-----------------------+----------------------+----------------------+
| | | | | | | |
| flags | type | auth tag | sha(appleID) | sha(phone_nbr) | sha(email) | sha(SSID) |
| | (0x08)| | | | | |
+--------+--------------------------------+-------------------------+-----------------------+----------------------+----------------------+
As you can see, the device sends the first 3 bytes of the SHA256 hash of phone number/email/appleID sha256(phone_number)[0:3].
Probably, devices hash all contacts and then compare them to the values from BLE messages, and in case there is a match offer to share the Wi-Fi password (if they have it, of course).
We’ll look into this process in more detail in the following articles. What we tried to do here is to recover a phone number from those 3 bytes of the hash.
First, we have to understand phone number formats. E.164 is a recommendation describing various formats.
- A phone number can have a maximum of 15 digits
- And it can be divided into:
- Country code (1-3 digits)
- National destination code (NDC)
- Subscriber number
Of course, formats vary with country, but the idea is the same. So, we can calculate the values of SHA256 for the numbers of a particular city.
: We made a table of phone numbers for a city with a population of about 5 000 000. Considering the large number of subscribers, collisions are inevitable. In average, we have a collision of 10-15 numbers for 3 bytes of hash.
We made an API for quick requests to the table to get a number from a hash:
There are two approaches to ensuring the accuracy of identification:
- HLR (Home Location Register) Lookup that allows identifying inactive subscribers and subscribers from other regions
- A number must be associated with an AppleID, so we can identify valid numbers by checking if iMessage is available for a certain number (we’ll talk about this approach in more details in the future articles).
Combining these two approaches, we can accurately identify a phone number in almost 100% of cases.
Can we activate the Wi-Fi password sharing popup on a device? That’s an open issue.
Thus, we have a script that identifies the users connected to Wi-Fi.
Moreover, we can send BLE requests for a Wi-Fi password hoping that the victim will provide us, for example, with a corporate network password. We’ll talk about this vector more in our other articles as well. By the way, you can use an Android app (like nRF Connect) to clone and repeat different BLE messages.
Airdrop
Let’s see if this mechanism of identifying users for the purpose of sharing Wi-Fi passwords is universal. Apple Airdrop is one of the points we can investigate, as it has 3 privacy options:
- Receiving Off
- Contacts Only
- Everyone
So, how do devices identify each other?
BLE sniffer:
000000000000000001123412341234123400
The structure of the message is:
0 8 9 11 13 15 17 18
+-----------------------------------------+--------+----------------+---------------------+-------------------+------------------+--------+
| | | | | | | |
| zeros |st(0x01)| sha(AppleID) | sha(phone) | sha(email) | sha(email2) | zero |
| | | | | | | |
+-----------------------------------------+--------+----------------+---------------------+-------------------+------------------+--------+
As you can see, in this case, devices sends only 2 bytes of the SHA256 hash, which is enough to identify the phone number. Traffic analysis showed that BLE is only used to initiate AirDrop transfer. The transfer itself happens via Wi-Fi using the AWDL technology that establishes a peer2peer connection between the server (receiver) and the client (sender).
To analyze the AWDL packets, we can use Wireshark and the awdl0 interface available on all devices.
As you see, after sending a few MDNS packets, the devices exchange their certificates and then use the secure TLS connection for data transfer.
We were about to begin the reverse engineering of the sharingd app, which is responsible for AirDrop, when people from Technische Universität Darmstadt released a white papper A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and macOS Through Apple Wireless Direct Link about AirDrop .
This white paper beautifully describes the functioning of AirDrop. Now, we’ll take a brief look at the AirDrop protocol workflow:
During authentification, the device sends its identification data (sender’s record data), that contains the full SHA256 hash of the phone number. Thus, if we answer all Airdrop BLE requests, we’ll get the sender’s contact data, including phone number hash.
We’ve slightly modified the opendrop utility to do that.
Here are the results:
Others
Below, you can see various BLE message formats that we encountered during our research.
Handoff
0 1 3
+--------+----------------+----------------------------+
| | |
|clipbrd | seq.nmbr | encr.data
| | |
+--------+----------------+----------------------------+
Airpods
0 3 4 5 6 7 9 25
+------------------------+--------+-------+--------+-------+-----------------+------------------------------------------------------------+
| | | | | | | |
| some | state1 |state2 | data1 | data2 | data3 | data4 |
| | | | | | | |
+------------------------+--------+-------+--------+-------+-----------------+------------------------------------------------------------+
By sending this message, we can make Apple devices display AirPods inforamtion as if they were connected. Just watch this funny video:
Wi-Fi settings
0 4
+-----------------------------------------+
| |
| iCloud ID |
| |
+-----------------------------------------+
Hotspot
0 2 3 4 5 6
+----------------+-----------+------------+-----------+------------+
| | | | | |
| data1 | battery | data2 | cell serv | cell bars |
| | | | | |
+----------------+-----------+------------+-----------+------------+
