iPhones Vulnerable to New Remote Attack

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.

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 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 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 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.

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.”

Suggested articles

Discussion

  • Anonymous on

    Isn't the issue with Verisign issuing a certificate for "Apple Computer" to random people ?

    Maybe Apple should remove their trust in that particular verisign root certificate.

  • Anonymous on

    I think you're correct. How did the fraudulent "Apple Computer" certificate get issued from VeriSign? I wonder if this was an attack on Domain Validation or if this was a fully validated organization certificate that found it's way through a giant hole at Verisign.

    Also not clear, does this affect jailbroken phones, regular iPhones or BOTH?

  • Anonymous on

    What he said: "not clear, does this affect jailbroken phones, regular iPhones or BOTH?"

  • Anonymous on

    "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."

    What does this even mean? So you can just turn off wifi or what?

  • Jens Alfke on

    This is a pretty typical social-engineering attack on certificate validation. It's been done a number of times against Internet Explorer, using malicious ActiveX controls signed by a cert with a misleading common name like "Macrosoft" or "Official Security Update Provider". You just have to be able to trick a reputable certificate authority into issuing you a cert with a name like that. Once that's done, there's little the software can do to defend itself, if it really is designed to accept certificates from multiple providers and not just the vendor (Apple in this case.)

    As the other commenters point out, the actual security hole here appears to be in Verisign's approval process. They should never have issued a cert with that name, and for a business that's based entirely on trustworthiness, this sounds like a really embarrassing problem.

  • cryptopath on

    Nope. Verisign delivers these test certificates for a short (60 days) period of time for people to play with, essentially to test certificate-enabled software or for people who want to see how it works. The certificates are unverified and come with all bells and whistles to indicate they should not be trusted for anything.

    The security issue is the fact that an iPhone would accept such a certificate for something as important as over-the-air configuration. The question goes deeper: who should be trusted to update your phone configuration over the air?

  • Russ on

    "The question goes deeper: who should be trusted to update your phone configuration over the air?" - Surely in a closed ecosystem such as the iPhone only Apple (the real one in Cupertino) and a set of wireless providers. Could the iPhone not be hard coded to only accept a subset of certificates for such updates? In a closed system I don't see why the user would be prompted to trust a certificate for a sw or config update not coming from iTunes or the cell provider. The user doesn't need to be given the choice to trust in the iPhone world. Unless of course we are talking about jailbroken phones in which case you are own your own anyway.

     

    or am I missing something?

     

     


  • Abhi Beckert on

    "Surely in a closed ecosystem such as the iPhone only Apple (the real one in Cupertino) and a set of wireless providers."

    Perhaps the problem is that "a set of wireless providers" is actually "thousands of wireless providers". Americans are currently forced to purchase their phone from one provider, but that's not the case in the rest of the world.

    Just here in australia, you can buy an iPhone from at least 7 or 8 providers (that I know of), and you can also buy it off apple direct without any sim card, then insert a sim card from virtually any wireless provider in the world.

    Config settings might also come from your corporation.

  • Russ on

    Wireless providers could have their certs signed by the real Apple, even a large number, but you convinced me with:

    "Config settings might also come from your corporation" - I didn't know that was a possibility

    Thanks 


  • Anonymous on

    Apple Computer changed their name to Apple Inc over three years ago. 

  • Anonymous on

    But Does Apple Inc still have any legal control over the use of the name Apple Computer?

  • Joseph A'Deo @ VeriSign on

    Thanks for clarifying, cryptopath. The other salient point here is that  SSL at this level is more about data encryption than identity verification (the idea of trial certs is to allow websites to test the former), though obviously both are needed in order to enforce true safety. Hopefully this will also show folks how easy it is to obtain a trial SSL cert, and how not all "padlocked" identities can be trusted without additional technology implementation (ie EV SSL, etc). 

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.