Hijacking Apple iOS 4
We’ve just come back from HITB held in Amsterdam; we really had a good time there, and we would like to thank the whole staff for all the effort they put on it :-).
During our presentation “Hijacking Mobile Data Connections: State of Art” we discussed some relatively simple methods to extend the scope of the attack to iPhones/iPod/iPad and Android-based devices.
Regarding Apple products we suggested, as a countermeasure, to update the iPhone to iOS 4; we didn’t give any details to back up this, basically because iOS 4 had been released just a few days before and, apart from noticing some changes in the way it handles remote reconfiguration, we didn’t have time to perform full tests and report the results. In order to avoid any possible misinterpretation, we would like to point out a few additional details on this topic.
Apple’s iOS 4 features a new constraint when installing a Configuration Profile: if the user already has a Configuration Profile, previously installed, he can download a new one, but he cannot install it because an Error box like the one below is shown.
The only way around this is to manually remove the old one (if it’s not locked) and then proceed with the installation.
On the other hand, if the user has no installed Profile, he can download and install the new one in the usual way.
This mechanism protect all users that already have an installed profile; sadly, however, it does nothing to address the vulnerability of users that don’t have any installed profile.
Additionally it must be considered that this raises another issue, having to do with how phone backups are managed. When the user backups his handset, configuration profile is stored in the backups itself, and is recovered when he later restores it; this also applies to locked profiles (PayloadRemovalDisallowed=true), that is, profiles that the user cannot modify or remove. In iPhone OS 3.x the user can work around this by installing a new profile and using it instead of the malicious one. In case of iOS 4, on the other hand, this is not possible anymore (for the reason explained above), so the user has no simple way, apart from reflashing the handset (and losing all his backup data) to restore it to a safe condition. The only solution, at this point, relies on the availability of an older backup, performed before the attack was carried out, and thus not including the malicious configuration profile.
Another point that deserves attention, as shown by the screenshots below, is related to the details of the new configuration that the handset shows to the mobile user before he accepts the it.
As opposed to the iPhone OS 3.1 behavior, iOS 4 presents to the user additional information about the Certificate used for signing the mobileconfig file, e.g. “Subject Name”, “Issuer Name”, “Signature Algorithm” (but also other useful information such as the email address which has been used when requesting the certificate itself), before the mobileconfig installation actually takes place.
By analyzing these information, the user should be able to decide if the configuration source is to be trusted or not. While this provides some useful information, it must be noted that only the first few characters of the strings are displayed.
Hence a smart attacker can forge a long enough common name and email address, to hide the suspect part of the strings.
Furthermore, the security flaws disclosed by Cryptopath blog still works, since a signature-only certificate is valid to sign a configuration profile and Safari root CAs list is used to validate the signature.
So, while iOS gives some degree of additional protection to (probably) most users, we must conclude that there is still an open vulnerability windows, that an attacker can exploit to perform the attack.