Call me maybe: Exploiting iOS WebViews to force automatic FaceTime calls

An attacker can exploit iOS WebViews to make automatic calls to an attacker-controlled phone number OR FaceTime address. Our research has found that FaceTime URL (facetime://) handlers are frequently overlooked in iOS applications. The oversight allows an attacker to potentially capture a video or snapshot of the affected user by directing them to a webpage from within a vulnerable WebView.

Impacted apps include LinkedIn and Twitter (and likely many others) for the same reason as described in Collin Mulliner’s recent blog post “iOS WebView auto dialer bug“. The underlying weakness is due to a lack of confirmation before the FaceTime session initiates the video call, a requirement that iOS (up to iOS 10) as a rule places on the application.

For what it’s worth, Apple does provide a warning with this “feature” for TEL URLs. On the positive side, our testing showed that FaceTime stops sending video when it is moved to the background, thereby reducing the chance that an attacker obtains a clear view of his or her target.

Exploiting iOS WebViews

Collin Mulliner’s blog post explained a bug in the handling of TEL URLs (tel://) within iOS applications. Specifically, Collin discovered that both Twitter and LinkedIn (and likely many other apps) are vulnerable to an attack that abuses the handling of these URLs. Consequently, vulnerable iOS WebViews “can be used to automatically call an attacker controlled phone number.” Collin supplied proof of concept in the form of a webpage enabled with JavaScript that, when loaded from the WebView inside an iOS application, abuses the handling of this URL to place a call to an attacker-controlled phone number without any confirmation.

After a little bit of additional research I discovered that, in addition to TEL URLs, many apps incorrectly handle FaceTime URLs as well. This allows an attacker to phish a user into a page that forces that user to call them back via FaceTime and thereby potentially expose their image and audio to an attacker. Safari, however, properly requests confirmation from TEL URLs, as Collin’s research determined. Our research found this is also true for Safari’s handling of FaceTime URLs.

Surprise Chatroulette: Forced, automatic FaceTime calls proof-of-concept

Collin found that he could improve the likelihood of a successful attack: “The trick is to cause the OS to open a second application while the phone is dialing the given number.” This trick, however, does not work as well for FaceTime, as it places the SMS Application in the foreground, thereby relegating FaceTime to the background.

When this occurs, FaceTime automatically pauses the video stream being sent to the attacker. However, before the SMS application pops up, and potentially after typing the SMS is finished, there is sufficient opportunity for the phone to broadcast the user’s face as they try to understand what is going on. It’s sort of like a surprise Chatroulette.

To further optimize the attack, it’s possible to configure a Mac with FaceTime on the the receiving side of the session to automatically accept incoming video calls. This option can be set at the command line via `defaults write com.apple.FaceTime AutoAcceptInvites -bool true`.

Enabling the `AutoAcceptInvites` option improves the attacker’s chances of capturing the user off-guard by reducing the time before FaceTime begins broadcasting the video from the user. A simple piece of tape on the attacker system is enough to prevent the attacker’s image from being sent back to the impacted user.

Here’s a video illustrating the attack:

 

 

And here’s a step-by-step explanation of what’s happening in the video:

1. We show the camera the victim’s FaceTime ID. Whether the attacker will see the victim’s e-mail address or phone number on the other end depends on which default FaceTime user is set on the device. In this case, the attacker will see the reginald.odestin-at-gmail address.
2. The victim receives a direct message in Twitter including a specially crafted URL (the same method works with LinkedIn). In this case we use a shortened URL which redirects to the attacker’s page hosted locally on the network (10.0.1.8:8000).
3. The victim clicks the URL, which loads the attacker’s page including the attacker’s FaceTime address (cophragist-at-gmail). In the terminal window on the laptop, you can see the attacker’s server receiving the request from the WebView.
4. The URL loads and immediately calls the attacker (the attacker being cophragist).
5. The proof-of-concept includes a timer to immediately start a second FaceTime call if the victim tries to exit/drop the initial call.
6. A moment later the device’s GUI is unresponsive due to the launching of a second app (in this case, the SMS app with a very long message).
7. The victim cannot interact with the GUI and in general the device does not behave as expected.
8. The victim’s device broadcasts video when FaceTime is in foreground or when the home button is tapped twice to switch to another app.
9. In the end, we had to kill the FaceTime call from the attacker’s side because of the GUI’s unresponsiveness.

Mitigation

As Collin noted in his blog post, “Apple should change the default behavior of WebViews to exclude execution of TEL URIs and make it an explicit feature to avoid this kind of issues in the future.” We would like to add FaceTime URLs to that request. In the meantime, we recommend developers evaluate the URL handlers they use, and consider adding a confirmation prompt before placing a FaceTime video call.

While Collin’s proof-of-concept enables calling of premium numbers which can affect a victim’s pocket book, the potential for an attacker to obtain blackmail material via a well-timed FaceTime phish should not be underestimated.