New iPhone Attack Kills Apps, Reroutes Web Traffic

Trailrunner7 sends in a threatpost.com article on exploiting flaws in the way the iPhone handles digital certificates. "[Several flaws] could lead to an attacker being able to create his own trusted certificate and entice users into downloading malicious files onto their iPhones. The result of the attack is that a remote hacker is able to change some settings on the iPhone and force all of the user's Web traffic to run through any server he chooses, and also to change the root certificate on the phone, enabling him to man-in-the-middle SSL traffic from that phone. ... 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.'"

Re:IMPOSSIBLE

[Anonymous Coward]

Except this isn't a self-replicating binary, so no, it's not a virus. /pedant

Re:Heh

[kybur]

Certain settings can be changed on an iPhone just based on links/downloads clicked on from within Safari (on the device). That is how iphone os 3.0.x users could enable tethering without jailbreaking their phones. It was just a settings file that could be downloaded. I believe it was unsigned, but now, apparently it would be easy to make it look like an apple signed file.

Re:No danger...

[dgatwood]

I don't think there's really any security check that Apple could have performed on an over-the-air configuration profile that would not defeat the purpose of having such a profile. The idea is to make it as painless as possible for users to sign up for custom settings specific to a company where they work or whatever (e.g. adding corporate firewall keys, that sort of thing). As soon as you limit who can sign the profiles, they become useless, and if Apple required everyone to sign up for a signing cert through them, everyone would be jumping up and down screaming that Apple is being too controlling. It's truly a no-win.

Even if they added an extra check to make sure the signing cert doesn't have /^\s*Apple\s*$/i or /^\s*Apple\s*Computer\s*$/i as the company name, that still doesn't fully solve the problem. Many users would just as quickly tap "OK" for an update that claimed to be from any company they trust---their bank, Google, Yahoo, PayPal, AT&T, etc. And making the warning sterner only helps if people read it and understand it. I'm just not convinced that this problem has a solution short of not trusting incompetent cert providers with a history of issuing certs in the name of other companies.

The real security flaw here, IMHO, is that Verisign issued this company a signing certificate with the name Apple Computer. And this isn't the first time Verisign has done something stupid like that [amug.org]. They've repeatedly shown themselves completely incapable of doing even basic sanity checking before handing out signing certificates, SSL certificates, etc. Thus, IMHO, their code signing certs are inherently no more trustworthy than a self-signed cert or someone typing the name of a company into a field in a plist file. As far as I'm concerned, they should be dropped from the list of trusted roots. If Safari and Firefox both did this, they would eventually shrivel up and die like the inept hack of a company they are.

Wrong title?

[jma05]

This is a vulnerability, not an attack that has happened. Vulnerabilities can *potentially* lead to attacks. The title implies that it had already happened. AFAIK, testing vulnerabilities is not termed an attack; only when they are exploited by a malicious third party.