[1]There are several flaws in the way that the iPhone handles digital certificates which could lead to an attacker being able to create his own trusted certificate and entice users into downloading malicious files onto their iPhones. The attack is the end result of a number of different problems with the way that the iPhone handles over-the-air provisioning, trusted root certificates and configuration files. But the result of the attack is that a remote hacker may be able to change some settings on the iPhone and force all of the user's Web traffic to run through any server he chose and also to change the root certificate on the phone, enabling him to man-in-the-middle SSL traffic from the iPhone.
The chain of vulnerabilities and the attack was outlined in an anonymous blog post on the iPhone flaws [4] on Friday. Charlie Miller, an Apple security researcher at Independent Security Evaluators, said that the attack works, although it would not lead to remote code execution on the iPhone.
"It definitely works. I downloaded the file and ran it and it worked," Miller said. "The only thing is that it warns you that the file will change your phone, but it also says that the certificate is from Apple and it's been verified."
The problems start with the fact that the iPhone signs its own credentials using a certificate signed by Apple when it is requesting a configuration file from a remote server during the provisioning process. The only way to establish the validity of the Apple certificate is to verify each of the certificates that leads to the Apple root certificate authority, and that can only be done by getting the data from a jailbroken iPhone.
Interestingly, the Apple root CA on top of the iPhone chain is not the same as the one published on the Apple web site. Fetching the root certificate published on Apple’s web site [5] shows:
Serial Number: 2 (0x2)
CN=Apple Root CA
keyid=2B:D0:69:47:94:76:09:FE:F4:6B:8D:2E:40:A6:F7:47:4D:7F:08:5E
Different name (CN), different serial numbers (1 vs 2) but the same key id. It looks like somebody reused the same keyset to generate a second certificate. Hard to tell whether this is an oversight or intentional, but the fact is: you cannot technically relate an iPhone signature to the Apple root CA certificate published on their web site. Even with the same keyset, verification will fail because Subject and Serial are different.
The iPhone by default will trust configuration files that it receives over the air or while connected to a PC, as long as the file is signed by a trusted implementation of the iPhone Configuration Utility, a desktop application used to create config files for iPhones. However, the iPhone also will accept a file that is signed by a signature-only certificate, which can be obtained fairly easily without any credentials.
Apple has a list of 224 root certificates [6] that it trusts. As part of the attack, the anonymous researchers obtained a signature certificate from VeriSign for a company named Apple Computer. They backed the certificate up to disk, then used iPCU to create a mobilconfig file called "Security Update," and attributed it to Apple Computer. They then exported it to disk without a signature as an XML file. They then signed the file and its CA trust chain and uploaded it to a Web server.
iPhone Config File
Opening the file with Safari on an iPhone results in the phone trusting the configuration file.
"To be successful, profile installation needs to be validated by the end-user. Unless they know about this flaw it is quite likely that a default end-user would trust an update that claims to be issued by Apple and indicated as trusted by the device. A bit of social engineering is needed to both get the user to click on the link and accept the profile installation," the researchers wrote.
The mobileconfig file has the authority to change a number of things on the iPhone, including the default HTTP proxy and the root certificate. Miller was unable to verify that the file could change the iPhone's proxy settings.
A real-world attack might involve the attacker enticing the user into clicking on a malicious URL either in an email or on a site, leading them to the site to download the configuration file. The user would see a dialogue box asking him whether he's sure he wants to install the file. If he accepts, the file downloads and takes whatever action is contained in the configuration profile.
The attacker would not have the ability to run code on the iPhone, but he could take any number of other actions, Miller said.
"You can make any part of the phone not work. You definitely don't get to run code, but there's lots of nasty things you can do. You can make applications not work, make it so that you can't remove this config file," Miller said. "At the very least, you can make someone's day miserable."
Commenting on this Article is closed.
