An iPhone user’s worst nightmare is to have someone gain persistent control over his/her device, including the ability to record and control all activity without even needing to be in the same room. In this blog post, we present a new vulnerability called “Trustjacking”, which allows an attacker to do exactly that.
This vulnerability exploits an iOS feature called iTunes Wi-Fi sync, which allows a user to manage their iOS device without physically connecting it to their computer. A single tap by the iOS device owner when the two are connected to the same network allows an attacker to gain permanent control over the device. In addition, we will walk through past related vulnerabilities and show the changes that Apple has made in order to mitigate them, and why these are not enough to prevent similar attacks.
A recap of related past vulnerabilities / attacks
Prior to iOS 7, connecting an iOS device to a new computer didn’t require any authorization from the device owner. Juice jacking    uses this behavior and is able to steal sensitive information from devices and may install malware on the victim’s device. Apple solved this issue by adding the popup requesting the user to authorize new computers before allowing any sync operations.
Another publication discusses Videojacking, which utilizes the ability of Apple’s connector to be used as an HDMI connection and get a screen recording of iOS devices while connected to a malicious charger.
Both exploits allowed an attacker potential access to sensitive information, but their major limitation was that everything is possible only while the device is physically connected to the malicious hardware – disconnecting the device stops the attack flow.
Trustjacking allows an attacker to gain a more continuous and persistent hold of the device and retain the same abilities long after the device has been disconnected from the malicious hardware. To understand how this works, we first need to explain iTunes Wi-Fi sync.
What is iTunes Wi-Fi sync?
Trustjacking – how does it work?
Upon connecting an iOS device to a new computer, the users are being asked whether they trust the connected computer or not. Choosing to trust the computer allows it to communicate with the iOS device via the standard iTunes APIs.
This allows the computer to access the photos on the device, perform backup, install applications and much more, without requiring another confirmation from the user and without any noticeable indication. Furthermore, this allows activating the “iTunes Wi-Fi sync” feature, which makes it possible to continue this kind of communication with the device even after it has been disconnected from the computer, as long as the computer and the iOS device are connected to the same network. It is interesting to note that enabling “iTunes Wi-Fi sync” does not require the victim’s approval and can be conducted purely from the computer side.
Getting a live stream of the device’s screen can be done easily by repeatedly asking for screenshots and displaying or recording them remotely.
It is important to note that other than the initial single point of failure, authorizing the malicious computer, there is no other mechanism that prevents this continued access. In addition, there is nothing that notifies the users that by authorizing the computer they allow access to their device even after disconnecting the USB cable.
Imagine the following scenario: A victim connects his phone to a free charger in an airport; upon connecting his phone to the charger a popup message appears on his device, requesting him to approve the connected device. Approving this request might seem reasonable: the victim wants to charge his device, the service seems legitimate and it appears that nothing suspicious happens following the approval.
From the user perspective, all he had to do is connect his device to a malicious charger / computer (might also be his own computer, as outlined later on) and choose to trust it.
Reading the text, the user is led to believe that this is only relevant while the device is physically connected to the computer, so assumes that disconnecting it will prevent any access to his private data. Even if the device is only connected for a very short period of time, it is enough for an attacker to execute the necessary steps to maintain visibility of all actions performed on the device after it is disconnected.
The attacker needs to take two steps:
- Allow the device to connect to iTunes
- Enable iTunes Wi-Fi sync
These steps can be automated by malicious software. They interestingly do not require any additional approval from the victim and don’t trigger any indication on the device that something is happening. Once these actions are completed, the device does not need to be physically connected to the attacking hardware anymore. Now the attacker can control the device remotely, as long as the victim and attacker are connected to the same network.
In order to be able to view the victim’s device screen, the attacker needs to install the developer image suitable for the victim’s device iOS version; then, he can take screenshots repeatedly and view the device’s screen in near real time. Installing the developer image can be conducted over Wi-Fi and does not require regaining physical access to the device. Although a restart may remove the developer image from the device, the hacker has continued access and can reinstall it easily.
Taking it to the next level
In addition to remotely viewing the victim’s device screen, Trustjacking also allows an attacker to do much more.
One of the features that an attacker can leverage is remote iTunes backup. By creating a backup of the device’s contents the attacker is able to get access to a lot of private information such as:
- SMS / iMessage chats history
- App data
In order to get this information we had to parse the iTunes backup.
The backup consists of several metadata files and the backed up files themselves. Each file is stored in the path SHA1(“%domain%-%relativePath%”) and the directory with the name set to the first 2 hex digits of the hash.
For example, a photo with the path “Media/DCIM/100APPLE/IMG_0059.JPG” will be stored in the path “b1/b12bae0603700bdf7719c3a65b22ca2f12715d37” as “b12bae…” is the SHA1 hash of “CameraRollDomain-Media/DCIM/100APPLE/IMG_0059.JPG”.
All of the backed up files are listed on the “Manifest.db” file which is an SQLite3 DB and can be easily listed by querying it.
A simple query such as:
`SELECT * FROM Files WHERE relativePath like ‘%Media/DCIM%’ ORDER BY relativePath;` will list all of the pictures that have been backed up, including their hash.
Reading SMS / iMessage requires parsing another SQLite3 DB which can be found on the file “3d/3d0d7e5fb2ce288813306e4d4636395e047a3d28” (SHA1 equivalent of “HomeDomain-Library/SMS/sms.db”).
The two interesting tables are “chat” that lists all of the chats, and “message” that contains all of the messages for those chats, with “chat_message_join” to join them.
And there is more. An attacker can also use this access to the device to install malicious apps, and even replace existing apps with a modified wrapped version that looks exactly like the original app, but is able to spy on the user while using the app and even leverage private APIs to spy on other activities all the time. In the following video demonstration we demonstrate how they can identify the apps on the device and replace an app with a repackaged version of it. Notice the fraction of second in which the app is deleted and reinstalled.
Is the attack confined to Wi-Fi only?
The attacks that we have described require the device and the attacking computer to be connected to the same network. Usually this means being in proximity to the victim’s device and connected to the same Wi-Fi, but this is not the only option.
By combining this attack with the malicious profile attack, we are able to connect the device to a VPN server and create a continuous connection between the victim’s device and the attacker’s computer and leverage this attack anytime and without the restriction of being in proximity with the device or connected to the same network.
Following our responsible disclosure process, Apple chose to add a mechanism that should make sure that only the real owner of the iOS device can choose to trust a connected new computer. This is done by requiring the user to enter his / her passcode when choosing to authorize and trust a computer.
As can be clearly seen in this screenshot, the user is still being told that this authorization is only relevant while the device is connected to the computer, making him believe that disconnecting his device guarantees that no one can access his private data.
While we appreciate the mitigation that Apple has taken, we’d like to highlight that it does not address Trustjacking in an holistic manner. Once the user has chosen to trust the compromised computer, the rest of the exploit continues to work as described above.
What if the attacker infects the victim’s computer rather than using a malicious charger?
A limitation of the malicious-charger attack flow is the potentially short period of time the victim and the iOS device are in the same proximity/network as the malicious computer. It would be far more devastating if the user’s own computer becomes the malicious actor. This powerful use-case of Trustjacking can happen when the device owner’s own PC or Mac has been compromised by malware. In this case, the attacker can utilize the relation of trust the victim has between his iOS device and his computer, along with the fact one’s own computer is usually in close proximity to the mobile phone (e.g. home, office, etc.) to achieve deep insight not only to the actions on the infected computer, but also to the victim’s mobile phone activity over time.
Unfortunately, there is no way to list all of the trusted computers and revoke access selectively. The best way to ensure that no unwanted computers are being trusted by your iOS device is to clean the trusted computers list by going to Settings > General > Reset > Reset Location & Privacy, now you will need to re-authorize all previously connected computers next time you are connecting your iOS device to each device.
In order to protect device backups and avoid attackers leveraging Trustjacking in order to get their hands on additional private information, enable encrypted backups in iTunes and choose a strong password.
Installing a Mobile Threat Defense solution such as SEP Mobile or Norton Mobile Security will help to protect your device from other implications of such attacks. SEP Mobile will identify and protect the end user against the installation of malicious profile, apps or attempts to compromise the device via this technique, and leveraging integrations with the SEP product line, customers have full visibility into both mobile and desktop operating systems.
For app developers – avoid including sensitive data in iTunes backup as this will reduce the risk on attackers leveraging Trustjacking in order to get such data by accessing your app’s backup.