Vulnerability in iOS apps can allow attackers to initiate calls from your iPhone

A new vulnerability was discovered in Apple’s iOS recently by a developer that allows expensive phone calls to be made from your iPhone without your permission. This 0-day vulnerability can be easily practiced as you can see below, but the good side is that just a little bit of attention can save you from the worse.

Details of the vulnerability

First of all you should know what RFC is. RFC (which stands for “Request for Comments”) is a publication of the Internet Engineering Task Force (IETF for short) and the Internet Society, the principal technical development and standards-setting bodies for the Internet. In other words, RFC documents contain notes and descriptions for internet standards and protocols.

So, the developer that discovered the vulnerability was basically testing out the tel URI scheme RFC in iPhone devices. URI stands for “Uniform Resource Identifier” and is a string of characters that identifies a name of a resource (or you could say, identifies the name and location of a file or resource in a uniform format). Anyways, tel URIs allow users to call phones from their devices using whatever software is responsible for handling them.

Everything was normal when the developer was clicking on tel URIs in Safari, since a warning message would appear and ask for user confirmation before dialing the number. This was because Safari was reading HTML pages that were using the standard URI for tel. But cunny as he was, he did look up in Apple’s documents in order to see if Apple itself was using its own version of the tel URI. And guess what; he was right. Apple devices do not use the standard tel URI in their native apps. Instead, they use a modified version. Normally there wouldn’t be a problem with that, but in this case the vulnerability created has a high risk of affecting a user. Read the first paragraph of their instructions for it to get an idea of the problem:

“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 taps a telephone link in a webpage, iOS displays an alert asking if the user really wants to dial the phone number and initiates dialing if the user accepts. 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.”

So, opening a tel link from a native app’s webView (i.e. applications’ way of viewing web content without leaving the app) in iOS will not ask for confirmation will dial the number right away. How can this be exploited? Easily, in two ways: either the user himself clicks a tel link by mistake (an innocent mistake) or a script is implemented in the web page, which automatically clicks the tel link once the user visits the page. The developer was kind enough to provide examples of the vulnerability in various apps:

Facebook Messenger:

Gmail:

Google+:

An example of this attack would be if you were redirected to a web page of this kind, and as soon as the call started, another script of mine (or even myself) would immediately pick up the phone you were calling to and charge you before you get the chance to hang up. In the worst case scenario, I’d just redirect the call to my phone and find out your phone number- I don’t think that’s to be taken lightly either, even though you wouldn’t be charged.

Similar Vulnerability in Facetime (Codename: “Hello Pretty!”)

This kind of vulnerability works in Facetime as well, since the app has a URL scheme very similar to tel, which initiates calls between two users. The documentation for Facetime links state:

“The facetime URL scheme is used to launch the FaceTime app and initiate a call to the specified user. You can use the phone number or email address of a user to initiate the call. When a user taps a FaceTime link in a webpage, iOS confirms that the user really wants to initiate a FaceTime call before proceeding. When an app opens a URL with the facetime scheme, iOS opens the FaceTime app and initiate the call without prompting the user.”

Facetime link example:

facetime://14085551234

facetime://user@example.com

Therefore, an attacker could force someone to visit open a Facetime link from a native app using the same way as before, which would then initiate a call; to make the attack more effective, the attacker could have installed a script that would pick up the call instantly, and save all frames until the victim ends the call. As long as the connection is established quickly (before the victim takes action and ends the call), it’s not a matter of extreme hacking skills or effort. Just a little bit of dedication and testing will do the trick.

Whose Fault Is This Vulnerability?

As the developer correctly said, you can’t blame Apple for the way they have implemented the protocols in iOS. In fact, regarding tel links, the documentation clearly states “a native app can be configured to display its own alert.” Therefore it’s up to the application’s developer to configure their app and protect their users from being victimized.

Devices running iOS versions below 7 used to have a bigger problem which was fixed with the release of iOS 7. When a user would open a Facetime URL but did not have Facetime installed on the device, the Phone app would handle the Facetime call immediately (and thus let the attack begin as we described above). iOS 7 devices on the other hand, will show the user a warning message instead.

What Can Be Done About This?

Users should keep doing what they always should do: always be careful of the links they open and the stuff they are sent by strangers (and not only). For the time being, only being aware of the risks you take when opening an unknown link will protect you here; plus it will also keep you safe from other dangerous online attack schemes, such as phishing and installation of malicious scripts on your device.

Developers however are obligated to fix those security holes in their apps as soon as possible. You would expect applications from tech giants like Facebook and Google not to fall into traps like these and risk having their users’ privacy invaded (by others than the services themselves, at least, to word it better).

Click here if you’re interested in reading the original story from the developer’s blog. For those who want to dig deeper into the matter, visit this link.

Let us know what you think in the comments below.