M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
After some preliminary testing, it appears that a number of vulnerabilities reported in my recent research paper and subsequent talk at HOPE/X have been addressed by Apple in iOS 8. The research outlined a number of risks for wireless remote surveillance, deep logical forensics, and other types of potential privacy intrusions fitting certain threat models such as high profile diplomats or celebrities, targeted surveillance, or similar threats.
Given that Apple has dropped the NDA for iOS 8, it appears that I can write freely about the improvements they’ve made to address the vulnerabilities I’ve outlined in my paper. Here’s a summary of what’s been fixed, what risks still remain, and some steps you can take to help protect the data on your device.
File Relay (com.apple.mobile.file_relay) was the service responsible to causing the biggest potential privacy threat, by dumping large amounts of personal data from the device and bypassing the user’s backup encryption password. The file relay service is now guarded. While the service still exists, all attempts to extract data from it will fail with a permission denied error (see screenshot at the bottom of this post). Only under certain circumstances, such as beta releases and on managed devices can the file relay be activated. Otherwise, the service is no longer available at all – either with physical access to the device (via USB) or via WiFi. This is good news for consumers, as it not only eliminates the risk of wireless surveillance through this mechanism, but also prevents law enforcement forensics tools from dumping this information, which contains a significant amount of sensitive data: complete photo album, SMS messages, address book, typing cache, geolocation cache, application screenshots, and much more.
In addition to file relay, the threat of wireless surveillance has been addressed. Connections to a number of other services (house_arrest, afc, and others) on the device, has now finally been restricted and these mechanisms are deemed “usb only” services. Wireless clients are no longer permitted to obtain file handles to application sandboxes (only USB clients), so third party application data can no longer be dumped across WiFi. Additionally, wireless clients are not permitted to access the user’s media folder via AFC (Apple File Connection) or access certain other types of data. NOTE: Backups can (as expected) still be performed wirelessly, and so turning on the backup encryption feature in iTunes, as well as having a strong password, is very important for security.
Lastly, wireless access to the built-in packet sniffer (com.apple.pcapd) has been disabled, and the service has been listed with a new “usb only” descriptor, so that lockdownd will refuse to attach to it over WiFi. The packet sniffer can only be accessed while the device is connected over USB, eliminating it as a surveillance risk, while retaining its use for debugging and engineering.
Update:
As per Apple’s release notes, they have also provided a way to reset all pairing data (wiping clean all trusted computers). This takes place by resetting Location & Privacy, or by resetting Network Settings in General -> Reset.
While closing off the file_relay service greatly improves the data security of the device, one mechanism that hasn’t been addressed adequately is the ability to obtain a handle to application sandboxes across a USB connection, even while the device is locked. This capability is used by iTunes to access application data, but also presents a vulnerability: commercial forensics tools can (and presently do) take advantage of this mechanism to dump the third party application data from a seized device, if they have access to (or can generate) a valid pairing record with the device. For example, if you are detained at an airport or arrested and both your laptop and your phone is seized, or if your phone is seized unlocked (without a laptop present), a number of forensics tools including those from Oxygen, Cellebrite, AccessData, Elcomsoft and others are capable of dumping third party application data across USB. It is not designed to be protected with a backup password either, putting the data at risk of being intercepted in cleartext. Because a pair record can unlock the data-protection encryption using the EscrowBag included in the record, this data can be dumped if the device has not been shut down or rebooted since it was last used. Still, because this information is only accessible with physical possession of the device (and no longer wirelessly), the risk is less than in prior versions of iOS.
While the amount of data that can be scraped from an iOS 8 device has been greatly reduced, there is still some risk, and therefore still some steps you can, and should, take to ensure the data security of your device. When traveling through airports, or if you suspect you may be detained by law enforcement, powering down the device will cause the data-protection authentication (NSFileProtectionCompleteUntilFirstUserAuthentication) to be discarded from memory, rendering this type of attack unsuccessful, even with a valid pairing record from a desktop machine. Secondly, consider pair locking your iOS device using Apple’s Configurator tool. I have outlined instructions to do this. This will prevent an unlocked device from being able to establish a pair record with any device, other than the computer you’ve initially paired with in setting it up. Lastly, have a look at the tools Stroz Friedberg have outlined in their paper, Mitigating Pairing Record Risks in Apple iOS Devices to deauthorize pairing records on the device that may have been inadvertently created, or to ensure that a device does not have any unauthorized pairings.
While file relay is now restricted, it still exists, but has certain mechanisms to guard it. The file relay can be activated on managed devices where it is explicitly enabled in /Library/Managed Preferences/mobile/com.apple.mobile_file_relay.plist, and it also appears to be enabled in beta releases. Further research into this, and many other changes in iOS 8, is something that needs to be done, to ensure that there are no vulnerabilities in the mechanisms that control this access. Additionally, there are many functions and services now restricted to USB only, and ensuring that those services cannot be brought up over WiFi is also important.
It appears that the threat of persistent wireless surveillance – my biggest concern – has been sufficiently addressed in iOS 8. Apple has also greatly reduced the exposure of Apple devices to commercial forensics tools. While I’m not yet sure how Apple now controls access to these deeper functions, it does appear that they have been better protected from abuse. Props and thanks to Apple for tackling a very complex and subtle problem that was difficult to explain.
With respect to forensics, please be aware that this does not affect law enforcement’s ability to send a device into Apple to be partially dumped as per their law enforcement process. It also does not prevent law enforcement from obtaining warrants to obtain copies of your iCloud data or other data stored on Apple servers. It does, however, protect you from a number of third party tools which can be abused by third parties to illegally invade your privacy. Consider that only recently, such “law enforcement” tools were used by hackers to steal nude photos out of celebrities’ iCloud accounts.
The result of attempting to dump any one of dozens of file relay data sources, which would (in iOS 7 and earlier) deliver clear text copies of personal data including address book, SMS messages, photo album, geolocation data, system caches, and other data. As you can see below, the result of requesting these sources is now an access denied error.
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |