Sophos Cloud Optix
Web pages are all about hyperlinks.
Usually, these link to other web pages, by specifying a URL such as:
http://example.com/newpage
But there are other sorts of URL, such as mailto: (opens your email client), file: (opens a local file, if security settings permit it), and tel: (opens your phone app, if you have one).
For example, a URL such as tel:+44.1235.559933 is a hyperlink to the main Sophos UK switchboard.
If you click on a link like that in Safari on iOS, it pops up a dialog to say, “Do you want to call Sophos UK?” (It doesn’t say exactly that, of course, but it does ask you for confirmation before placing a call.)
But if you are a third party app developer who is using the iOS-provided web rendering engine known as WebView, you don’t have to wait for the user to confirm before dialling.
If you really want to, you can code your app so that it does prompt for tel: URLs, but two researchers have recently noticed that a number of popular mobile apps don’t bother.
→ Guillaume K. Ross presented his work at BSides Las Vegas 2014; Andrei Neculaesei wrote his findings up on his blog.
Indeed, Apple’s iOS developer guidelines make it clear that not prompting on phone links can be considered normal behaviour, except for Safari:
The 'tel' URL scheme is used to launch the Phone app on iOS devices and initiate dialing of the specified phone number [...] When a user opens a URL with the 'tel' scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user. However, a native app can be configured to display its own alert.
Not prompting before placing a call sounds like a small problem, except that if you do click a tel: link outside Safari, and the app doesn’t pop up a warning, you’ll dial out pretty much without realising.
There are two obvious problems with this that don’t apply to other sorts of URL:
- Your call might be to an expensive premium rate line.
- You might reveal your phone number to a crook.
By the time you notice a rogue call, Calling Line Identification (CLI or CallerID) may already have given away your telephonic identity, and any premium line flagfall charge will probably have kicked in.
Worse still, as Neculaesei found, you can bundle up a tel: link with some JavaScript that essentially clicks the link for you when WebView loads the page, putting you one click closer to trouble.
This isn’t really a bug, or even a security hole, because the behaviour of WebView is documented by Apple, as shown above, so Neculaesei’s headline calling it an “0day” is perhaps a little bit over the top.
But it is an example of how mobile apps seem frequently to fall short of the security behaviour we expect in our browsers.
What to do?
If you’re an iOS coder, why not make your app behave the same as Safari when processing phone-number URLs in WebView?
If you’re an iOS user, don’t rush to install a new app for everything: if you’d access a service via a browser on your desktop or laptop, why not try using the browser on your phone or tablet?
If you’re Apple, why not give WebView similar default security settings to Safari, or at least keep the former no less strict than the latter?
Thinking about the automatic dialing, this can be a serious problem if the crook knows the target better. For example, in some networks, you can pass prepaid credits from victim’s account to other account by dialing a number. With clever use of star and pound signs, one could trick to divert calls, etc as well.
Thinking about this, one could trick someone to divert calls (*62…# syntax), transfer prepaid mobile credits, etc with a small click. Facebook app’s implementation seems to confirm phone calls. So does Chrome. Not sure about other apps.