X
Business

Code execution exploit dings iPhone

Researchers at Security Evaluators have found what is believed to be the first remote code execution flaw affecting the device -- a bug that can be used to take full control of an iPhone surfing to a rigged Web site.
Written by Ryan Naraine, Contributor

Apple's iPhone has failed the security smell test.

Researchers at Security Evaluators have found what is believed to be the first remote code execution flaw affecting the device -- a bug that can be used to take full control of an iPhone surfing to a rigged Web site.

Dr Charlie Miller, a well-known hacker and former NSA employee, has published basic details on the vulnerability and says full disclosure will come at this year's Black Hat Briefings in Las Vegas.

A special Web site (http://www.exploitingiphone.com) has been created to demo the bug, which is exploited when an iPhone user used the embedded Safari browser. A preliminary paper with some technical details is available here (.pdf).

[We] created an exploit for the Safari browser on the iPhone. We used an unmodified iPhone to surf to a malicious HTML document that we created. When this page was viewed, the payload of the exploit forced the iPhone to make an outbound connection to a server we controlled. The compromised iPhone then sent personal data including SMS text messages, contact information, call history, and voice mail information over this connection. All of this data was collected automatically and surreptitiously. After examination of the filesystem, it is clear that other personal data such as passwords, emails, and browsing history could be obtained from the device. We only retrieved some of the personal data but could just as easily have retrieved any information off the device.

Miller says there are several delivery vectors that an attacker might utilize to get a victim to open such a web page. For example:

  • An attacker controlled wireless access point: Because the iPhone learns access points by name (SSID), if a user ever gets near an attacker-controlled access point with the same name (and encryption type) as an access point previously trusted by the user, the iPhone will automatically use the malicious access point. This allows the attacker to add the exploit to any web page browsed by the user by replacing the requested page with a page containing the exploit.
  • A misconfigured forum website: If a web forum's software is not configured to prevent users from including potentially dangerous data in their posts, an attacker could cause the exploit to run in any iPhone browser that viewed the thread. (This would require some slight changes in our proof of concept exploit, however.)
  • A link delivered via e-mail or SMS: If an attacker can trick a user into opening a website that the attacker controls, the attacker can easily embed the exploit into the main page of the website.

When the iPhone's version of Safari opens the malicious web page, arbitrary code embedded in the exploit is run with administrative privileges.

In Miller's proof-of-concept, the exploit code reads the log of SMS messages, the address book, the call history, and the voicemail data. It then transmits all this information to the attacker.

He warns that this code could be replaced with code that does anything that the iPhone can do. It could send the user's mail passwords to the attacker, send text messages that sign the user up for pay services, or record audio that could be relayed to the attacker.

Apple has been notified and is researching a fix.

See more at New York Times. Techmeme discussion.

Editorial standards