WARNING: iPhone's Web Dialer a Security Risk

G4R2

macrumors 6502a
Original poster
Nov 29, 2006
546
2
According to information posted on Looprumors, security firm SPI has determined that the the iPhones web dialer is a potential security risk that can be used to perform several attacks including the following:


"-Redirecting phone calls placed by the user to different phone numbers of the attacker's choosing

-Tracking phone calls placed by the user

-Manipulating the phone to place a call without the user accepting the confirmation dialog

-Placing the phone into an infinite loop of attempting calls, through which the only escape is to turn off the phone

-Preventing the phone from dialing"

http://looprumors.com/article.php?security-firm-dont-use-iphones-web-dialer,2319496541

The web dialer is the software that allows the iPhone to dial a phone number directly from a web page.
 

Diode

macrumors 68020
Apr 15, 2004
2,373
42
Washington DC
could you explain how normal calling via the iPhone involves "web dialing"?

Thanks!
I think your confused. What this refers to is the iphones ability to dial numbers from safari (you go to a website and click a numer and it dials it).

People have found out they can make malicous websites that will dial numbers automatically without your consent or knowledge. These can be 900 numbers which costs the dialer money to make.
 

Sobe

macrumors 68000
Jul 6, 2007
1,791
0
Wash DC suburbs
I think your confused. What this refers to is the iphones ability to dial numbers from safari (you go to a website and click a numer and it dials it).

People have found out they can make malicous websites that will dial numbers automatically without your consent or knowledge. These can be 900 numbers which costs the dialer money to make.
no I'm not confused, I just asked a leading question because the response to me made it sound like web dialing is the normal way to use the phone.
 

marksman

macrumors 603
Jun 4, 2007
5,764
5
I would be curious as to how web dialing would be looped in a manner that just leaving Safari would not end.
 

G4R2

macrumors 6502a
Original poster
Nov 29, 2006
546
2
I would be curious as to how web dialing would be looped in a manner that just leaving Safari would not end.
I'm curious too, but not curious enough to actually have it happen on my iPhone.
 

FreeState

macrumors 68000
Jun 24, 2004
1,728
110
San Diego, CA
The problem is pretty simple. The design of the system is that a webpage could say:

Like this item? Click here to call and order!

That would be a link to
Code:
tel://555-1212
or whatever their ordering phone number was. When you tap on that, the iPhone will say something to the effect of, "Do you want to call 555-1212?" and then place the call.

The security hole is that a malicious webpage could offer up a link reading:

Click here for pr0n!

And that actually forms a link to
Code:
tel://911
Apparently, there is a bug in this that allows the web page to bypass the iPhone's warning screen, and leaves you with a lot of explaining to do.

100% BS FUD

I just modified a link on my website to dial a different number than was displayed and the iPhone asked me if I wanted to call the number that was hidden - i.e. it would "Do you want to call 911?" even though the link said a different number or text. It ask if you want to call the number it is calling, not the number or text on the webpage.
 

vansouza

macrumors 68000
Mar 28, 2006
1,736
3
West Plains, MO USA Earth
Thank you

100% BS FUD

I just modified a link on my website to dial a different number than was displayed and the iPhone asked me if I wanted to call the number that was hidden - i.e. it would "Do you want to call 911?" even though the link said a different number or text. It ask if you want to call the number it is calling, not the number or text on the webpage.
Thank you for doing that for us...
 

pixelshaders

macrumors member
Jul 6, 2007
82
11
So the better way is the web dialer don't actually place call, but just bring up the dial screen and enter the number for user, then wait for the user tap CALL to confirm it?
 

FreeState

macrumors 68000
Jun 24, 2004
1,728
110
San Diego, CA
I did just try with a meta refresh tag, and that still gave me a prompt from the phone. However, as with trying to find any bug, one must do the unexpected.
I tried it with meta and a javascript window location script based on the browser and a php script. All resulted in the expected prompt to dial the specified number.
 

D1G1T4L

macrumors 68000
Jun 26, 2007
1,707
78
Savannah, GA
do people really use web dialers anyway?
I have for years. They are a nice when looking up places on the web and just being to point and dial. Quick and easy.


Now my only question is this a problem with Safari on the iPhone or all web dialers on portable devices.
 

Sobe

macrumors 68000
Jul 6, 2007
1,791
0
Wash DC suburbs
maybe it's to avoid copy cats, but I haven't seen one report on this issue that actually states that they can duplicate the security breach they are commenting on.

Maybe it's there and I missed it, but something like "we reproduced this in house and can verify that it might be an issue for some people" would be nice.
 
Sorry to be the bearer of bad news.

I've reproduced the problem, and its pretty much EVERYTHING they said.

Apple needs to fix this.

FreeState, you're not thinking outside the box.

I set up a link that asks me if I want to call my home phone number, and then it proceeds to call Moviefone. NO WARNING. Just calls Moviefone.

~ CB
 
Here is a demonstration of the bug:
http://www.figma.com/dialerbug/

It is an iPhone friendly page, and should present itself clearly on your Safari browser.
The page is NON-MALICIOUS, and represents a simple "SPOOF" link, that pretends to be something its not. Instead of calling Goog 411, it calls Tell Me. You can cancel the call before it connects, although both numbers are TOLL-FREE.

Here's how to protect yourself. As far as I can tell, the bug manifests itself by sending two "tel" navigation requests right after the other. Because you said "YES" to the first one, the iPhone assumes the one coming after has the same priviledges, and proceeds to accept the change in orders. This is kind of dumb.

Protecting yourself MAY BE (no guarantee) as simple as taking one simple precaution when proceeding with a phone link. TEST IT FIRST. After clicking on it, and having it ask if you wish to follow it. CANCEL by saying "NO". If another request comes right after it, then you know the page is NOT to the trusted.

ALSO, if you are given a series of pleading requests to follow Tel links... you MAY be able to stop them by FORCE QUITING Safari. Hold down your HOME BUTTON, until Safari quits out (usually 4 seconds or so). Javascript "loops" are generally only allows 10 seconds of execution time before Safari will try to stop them, but a "loop" may be executing multiple times after each time you try to close the request.

Look out for yourselves, its a jungle out there.

~ CB
 

DiamondMac

macrumors 68040
Aug 11, 2006
3,299
16
Washington, D.C.
As long as a hacker can't use my phone from their place, they can hack away if they want.

Nothing except work stuff that I am not sure the hacker would find quite boring :D
 

Djmx

macrumors 6502
Jun 29, 2007
287
0
i don't get it.. how can they hack it if it shows the fone that's dialing it and not what the page is displaying.. it's making no sense...? :rolleyes:
 

pr5owner

macrumors 65816
Jun 10, 2007
1,016
0
i don't get it.. how can they hack it if it shows the fone that's dialing it and not what the page is displaying.. it's making no sense...? :rolleyes:

read closer, instead of dialing a local or free 800 number the phone will show you the friendly number and actually dial a (most likley) high charge 900 number

some 900 numbers bill you hundreds of dollars per min

do not belive apple products are invincible (virus/bug free) once everyone has an iphone, hackers will enjoy targeting and exploiting you like windows
 

diamond.g

macrumors 603
Mar 20, 2007
6,361
317
Virginia
Here is a demonstration of the bug:
http://www.figma.com/dialerbug/

It is an iPhone friendly page, and should present itself clearly on your Safari browser.
The page is NON-MALICIOUS, and represents a simple "SPOOF" link, that pretends to be something its not. Instead of calling Goog 411, it calls Tell Me. You can cancel the call before it connects, although both numbers are TOLL-FREE.

Here's how to protect yourself. As far as I can tell, the bug manifests itself by sending two "tel" navigation requests right after the other. Because you said "YES" to the first one, the iPhone assumes the one coming after has the same priviledges, and proceeds to accept the change in orders. This is kind of dumb.

Protecting yourself MAY BE (no guarantee) as simple as taking one simple precaution when proceeding with a phone link. TEST IT FIRST. After clicking on it, and having it ask if you wish to follow it. CANCEL by saying "NO". If another request comes right after it, then you know the page is NOT to the trusted.

ALSO, if you are given a series of pleading requests to follow Tel links... you MAY be able to stop them by FORCE QUITING Safari. Hold down your HOME BUTTON, until Safari quits out (usually 4 seconds or so). Javascript "loops" are generally only allows 10 seconds of execution time before Safari will try to stop them, but a "loop" may be executing multiple times after each time you try to close the request.

Look out for yourselves, its a jungle out there.

~ CB
Well that isn't very sophisticated. I was expecting more hoops to have been jumped through. But you are right it does dial the other number. Upon looking at your source code, I would venture to say it wont ask for the other number because you are actually replacing it with the new number (in a round about way). I dunno if I would call that a bug per se, as you could use that trick for website redirection as well.
 
Well that isn't very sophisticated. I was expecting more hoops to have been jumped through.
Exactly. Makes it a lot worse, doesn't it? As I noted, this is the most simplistic, and non-malicious form of what could be done with it. If such requests can be automatically and repeatedly fired at users, then other problems could begin to surface (possibly even more problematic). While its possible to lock-up the iPhone browser with any number of other Javascript functions, this method actually could result in a number being dialed, which has far more repercussions. Caller-ID alone (acquired from a number dialed accidentally) begins to expose a user's phone to subsequent malicious attacks over the cellular network.
But you are right it does dial the other number.
Of course I am.
Upon looking at your source code, I would venture to say it wont ask for the other number because you are actually replacing it with the new number (in a round about way).
I explained that in my post. Did you read it? I said: "As far as I can tell, the bug manifests itself by sending two "tel" navigation requests right after the other. Because you said "YES" to the first one, the iPhone assumes the one coming after has the same priviledges, and proceeds to accept the change in orders. This is kind of dumb." I take it you're agreeing.
I dunno if I would call that a bug per se, as you could use that trick for website redirection as well.
You AGREE to a request to dial ONE NUMBER and the phone dials a DIFFERENT number without another request? That's a bug in ANYONE's book! :rolleyes:

This is the stuff programmers WINCE at when QA comes back to them on it. Anyone in development knows the pain of having someone in QA that loves making you say the sentence, "But why would anyone do that???" Apple QA didn't catch this one though, and its abundantly clear WHY someone would do it. Not sure why you'd even question it as a malfunction. :confused: The proper behavior would be to ASK AGAIN (which only happens now, if you say "NO"). Right?

Again, the only thing that's happening in the source code, is that TWO requests are coming in. As I noted, the simplicity of executing the hack makes it worse.

According to the "approval" mechanism Apple instituted, ANY NEW request to dial a number should be validated by asking a user whether this is the number they wish to call (Or why even ask in the first place?) Downplaying a clear problem like this is a very odd attitude to take. It's ok to defend Apple, so long as you accept when they screw up.

I expect that this is really some form of "race condition". Interacting with the phone feature is a handshake between two different parts of the system. The security in this particular set-up was dependant on a certain order of events, and did not take other possible scenarios into account.

http://en.wikipedia.org/wiki/Race_condition

Such situations are pretty widely viewed as "flaws".

~ CB
 
I thought this was interesting. I was looking at the RFC for "URLs for telephone calls". The section of "security considerations" was especially relevant here:

5. Security Considerations

It should be noted that the local entity SHOULD NOT call out without the knowledge of the user because of associated risks, which include
  • call costs (including long calls, long distance calls,
    international calls and premium rate calls, or calls which do not
    terminate due to <post-dial> sequences that have been left out by
    the local entity)
  • wrong numbers inserted on web pages by malicious users, or sent via
    e-mail, perhaps in direct advertising
  • making the user's phone line unavailable (off-hook) for a malicious purpose
  • opening a data call to a remote host, thus possibly opening a back door to the user's computer
  • revealing the user's (possibly unlisted) phone number to the remote host in the caller identification data, and correlating the local entity's phone number with other information such as the e-mail or IP address
  • using the same local number in different contexts, in which the number may have a different meaning
All of these risks MUST be taken into consideration when designing the local entity.

Vaha-Sipila Standards Track [Page 19]
RFC 2806 URLs for Telephone Calls April 2000

The local entity SHOULD have some mechanism that the user can use to filter out unwanted numbers. The local entity SHOULD NOT use rapid redialing of the number if it is busy to avoid the congestion of the (signaling) network. Also, the local entity SHOULD detect if the number is unavailable or if the call is terminated before the dialing string has been completely processed (for example, the call is terminated while waiting for user input) and not try to call again, unless instructed by the user.
These points confirm most of my suspicions voiced and unvoiced in the previous post. The one I'm specifically looking at is this one: "revealing the user's (possibly unlisted) phone number to the remote host in the caller identification data, and correlating the local entity's phone number with other information such as the e-mail or IP address"

http://www.ietf.org/rfc/rfc2806.txt

It's not especially clear HOW much of the syntax Apple implemented, but there are a lot of interesting provisions in there.

tel:+358-555-1234567;postd=pp22

The above URL instructs the local entity to place a voice call to +358-555-1234567, then wait for an implementation-dependent time (for example, two seconds) and emit two DTMF dialing tones "2" on the line (for example, to choose a particular extension number, or to invoke a particular service).
~ CB