WARNING: iPhone's Web Dialer a Security Risk

G4R2 · Jul 18, 2007

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.

Sobe · Jul 18, 2007

do people really use web dialers anyway?

Diode · Jul 18, 2007

Sobe said:
do people really use web dialers anyway?

The iphone does ...

However this issue was known when the iphone was released I think.

Sobe · Jul 18, 2007

could you explain how normal calling via the iPhone involves "web dialing"?

Thanks!

Diode · Jul 18, 2007

Sobe said:
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.

flipperanubi · Jul 18, 2007

Sobe · Jul 18, 2007

Diode said:
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 · Jul 18, 2007

I would be curious as to how web dialing would be looped in a manner that just leaving Safari would not end.

G4R2 · Jul 18, 2007

marksman said:
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 · Jul 18, 2007

flipperanubi said:
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 · Jul 18, 2007

Thank you

FreeState said:
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 · Jul 18, 2007

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?

flipperanubi · Jul 18, 2007

FreeState · Jul 18, 2007

flipperanubi said:
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 · Jul 18, 2007

Sobe said:
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.

G4R2 · Jul 18, 2007

This issue ended up on a blog over at CNet, which I am hesitant to post due to their increasing credibility problems:

http://news.com.com/8301-10784_3-9745885-7.html?tag=cnetfd.mt

Sobe · Jul 18, 2007

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.

Cleverboy · Jul 18, 2007

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

Cleverboy · Jul 18, 2007

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 · Jul 18, 2007

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

Djmx · Jul 19, 2007

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...?

pr5owner · Jul 19, 2007

Djmx said:
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...?

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 · Jul 19, 2007

Cleverboy said:
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.

Cleverboy · Jul 19, 2007

diamond.g said:
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.

diamond.g said:
But you are right it does dial the other number.

Of course I am.

diamond.g said:
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.

diamond.g said:
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!

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.

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

Cleverboy · Jul 19, 2007

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

WARNING: iPhone's Web Dialer a Security Risk

macrumors 6502a

macrumors 68000

macrumors 68020

macrumors 68000

macrumors 68020

macrumors member

macrumors 68000

macrumors 603

macrumors 6502a

macrumors 68000

macrumors 68000

macrumors member

macrumors member

macrumors 68000

macrumors 68000

macrumors 6502a

macrumors 68000

macrumors 65816

macrumors 65816

macrumors 68040

macrumors 6502

macrumors 65816

macrumors G4

macrumors 65816

macrumors 65816

Our Staff