ISE security researchers successfully discovered a vulnerability in the iPhone, developed a toolchain for working with the iPhone's architecture (which also includes some tools from the #iphone-dev community), and created a proof-of-concept exploit capable of delivering files from the user's iPhone to a remote attacker.
UPDATE: Apple has patched the vulnerabilities we reported.
UPDATE: Dr. Charlie Miller presented the details of the exploit at BlackHat in Las Vegas on August 2 at 4:45. The slides from this talk are also available.
UPDATE: A preliminary version of the paper describing the attack is available. The full version with details of the vulnerability and exploit will be available in the evening on August 2nd.
UPDATE: A story in the New York Times about this work is available here.
Shortly after the iPhone was released, a group of security researchers at Independent Security Evaluators decided to investigate how hard it would be for a remote adversary to compromise the private information stored on the device. Within two weeks of part time work, we had successfully discovered a vulnerability, developed a toolchain for working with the iPhone's architecture (which also includes some tools from the #iphone-dev community), and created a proof-of-concept exploit capable of delivering files from the user's iPhone to a remote attacker. We notified Apple of the vulnerability and proposed a patch. Apple subsequently resolved the issue.
A member of our team, Dr. Charlie Miller, presented the full details of discovering the vulnerability and creating the exploit at BlackHat on August 2nd, 2007.
How the exploit works
The exploit is delivered via a malicious web page opened in the Safari browser on the iPhone. 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.
An h.264 encoded video showing the exploit is also available.
We've notified Apple of the vulnerability and proposed a fix. Hopefully they will include a patch in a future iPhone update. To protect yourself from this and similar future vulnerabilities, there are a few best practices that can be followed (both on an iPhone and on other devices):
- Only visit sites you trust. If you don't visit attackers' sites, you give them one less attack vector.
- Only use WiFi networks you trust. If attackers have control of your Internet connection, they have the ability to insert exploits into any website you visit.
- Don't open web links from emails. Many current viruses send links to malicious sites in emails that look like they are from trusted contacts.
We can be reached by phone at 443-270-2296.
When the iPhone's version of Safari opens the malicious web page, arbitrary code embedded in the exploit is run with administrative privileges. In our proof of concept, this 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. However, 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.