Read previous part: Injecting Malware into iOS Devices via Malicious Chargers 4 - Pulling off the Mactans Attack
The final part of the presentation covers the problems that may prevent the Mactans attack from getting through and the applicable workarounds for those.
Chengyu Song: Okay, let’s discuss some problems we found during this research and some proposed potential countermeasures. So, problem #1 – incorrect trust model for pairing. The current trust model used by iOS is that any host is implicitly trusted if the device is not passcode-locked. However, as we have shown in our attack, the host can be malicious. It can be a Mactans charger, or simply be a PC or a Mac infected with malware that can also infect an iOS device. And a minor problem, as we already mentioned, is that once pairing is done, it’s permanent. More specifically, after the key exchange has finished the host can continue talking to the device even if the device is passcode-locked again. This can be dangerous in two ways. First, it only requires one very quick unlock during the charging for the malicious host to compromise the device, as we have demonstrated. And second, if the private key associated with the trusted certificate that the device already accepted is stolen by the attacker, the attacker can reuse this private key to communicate with the device without further pairing.
To fix this problem, we propose the device should explicitly ask the user to authorize the pairing. In fact, after we reported this weakness to Apple, they invited us to evaluate how it is with the new iOS 7 beta 2. During the examination, we noticed Apple has added a new feature, that is, when you connect the device to a near host, iOS 7 will pop up a window and ask the user whether this host is trusted or not. And to fix the permanent pairing problem, we suggest all mobile operating systems should add some kind of management functionality to allow users to manage trusted hosts. This can be in a similar form as managing your Wi-Fi connections in the desktop OS.
So, problem #2: there’s no visual difference for different connection states. In fact, there is only one notification icon for iOS now for synchronization. It will only show up when you are during backup and restore. It will not show up when Mactans tries to install the provisioning profile; it will not show up when it tries to install the Trojan app; and it will not show up when it tries to do some debugging. So, this is the prime reason why our attack is very stealthy.
The fix for problem #2: we suggest adding more notification to indicate what is happening on the device. Note that the fix for problem #1 already partially fixes the problem, because right now if you plug an iOS 7 device into Mactans charger you will immediately notice that something is wrong, because a charger should never ask for pairing. But as the host can also be a PC, this does not solve the whole problem. So we suggest, for example, adding different icons for different connection states – one for synchronization, one for app installation, and one for debugging. It would also be better to include some mechanism similar to one in Android where, when you have a new installed app or you’re updating an app, there will be a notification in the notification center telling what has happened.
Problem #3: provisioning profile abuse. While each app has to go through a very strict review process to get signed, the provisioning profile signing functionality is not well guarded. For this reason, Mactans charger can automatically generate a provisioning profile for the target device on the fly.
To fix this problem, we suggest adding additional procedures to stop this kind of abusing. For example, a CAPTCHA can be added to stop automatic provisioning profile generation. And a better detection mechanism can be deployed to detect suspicious behavior such as adding a large amount of UDIDs to a provisioning profile. Although this cannot prevent a targeted attack, we think it can be helpful to stop large-scale malware infection.
Problem #4: over-privileged default capabilities for USB. As we already mentioned, USB can be used to obtain device information. It can also be used to install and remove apps and provisioning profiles. It can be used to perform backup and restore, and even firmware reset. It is also used for debugging. Among these capabilities, we think the two related to development, namely installing provisioning profiles and debugging, are the most dangerous ones, because without the ability to automatically install provisioning profiles our attack won’t succeed, and with the capability of debugging you guys can come up with different kinds of creative attacks.
To fix this problem, we suggest reducing the default capabilities of USB. For example, when a provisioning profile is being installed the user should be asked for authorization – this can be done similarly to how you ask the user whether or not to trust a host for pairing. The debug mode should never be able to turn on through USB. In fact, Android does a better job in this scenario, because to turn on the debug mode on Android phone the developer has to manually touch the version information 7 times before the menu even shows up.
So, problem #5: the hidden app property. During our research we found this property is only used by a few Apple’s own apps or maybe ones from the carrier. We think of little or no legitimate use for third-party apps, and it has a very high abuse potential.
The fix for this problem can be easy. Apple can make this entitlement and restrict it to be used by Apple’s own apps, similar to how Apple restricts code generation and entitlements to Mobile Safari only.
Before we finish, one more thing. In this talk we have demonstrated how we can leverage the USB protocol and a personal developer’s account to inject malware into any iDevice. However, this is not the only way. In the coming USENIX Security Conference, our colleagues will present how a malicious app can bypass the app review process and get distributed through the official App Store.
Thank you!