Paid iOS browsers, do come with a price …

Published in

Section 9 Lab

5 min readOct 13, 2014

Paid does not necessarily means better, faster or more secure. Exploiting URL handlers in alternative web-browsers to trigger FaceTime and Telephone Calls

Background

Continuing with the Web Browsers & url-handlers research that started with Google Chrome, we decided to expand it into other, not mainstream, web browsers (Atomic and Mercury) to check if they were susceptible to the same type of issues and then some more. Even though, these might not have the install base other popular browsers do, they still have thousands of downloads and recommendations which makes them an interesting jumping point to trigger attacks as we did with Chrome.

Exploitation

It is pointless to describe and cite of all of the previous research that went into this; but If you want that please refer to the link mentioned above. To make a story short, we had all of the research and scripts already built for chrome and 90% of it could be reused. We efectively had half of the work done, no need to create any exploitation web sites, all were ready for testing:

Tests 1: FaceTime calls http://evilrovot.com/test.html

Tests 2: FaceTime-Audio calls http://evilrovot.com/ft_audio.html

Test 3: Telephone Calls http://evilrovot.com/tel.html

Now, it was time to find out wether or not these applications were vulnerable to one of our attacks and if they were we needed to investigate if the web browsers in question had a url-handler themselves to be used as a jumping point from other applications. Nothing a quick Google search — if we are lucky ☺ — and/or the decrypted application could not tell us.

Mercury Web Browser

We started testing Mercury Browser, this is a know browser that apparently connects to many Social Networks for quick sharing —we did not tested those features but they do sound like an interesting attack vector. Anyhow back to what we were doing, We quickly found that Mercury was not vulnerable to FaceTime calls ☹ but it was vulnerable to both FaceTime audio and Telephone calls. w00t!

This time we got lucky and a simple google search allowed to find the Mercury url handler merc:// and a few click later we had a Proof of Concept attack http://evilrovot.com/mercury.html up and running to send as a test in Messages App.

❯❯❯ ./cartero IMessage -d messages_accounts.json -b malicious_message.imsg

In shorts, Mercury Browser was vulnerable to one of the worse type of url-handler vulnerabilities allowing arbitrary phone calls being initialized by an attacker. This could allow an attacker to force users to call pay lines and mine money in that way. In addition, it is worth noting that iphone supports entering options to phones by using +1234;7868 allowing to extend the attack possibly further. Last, but not least, the browser will automatically re-execute the last open page it was left on the browser, re-initializing the attack over an over every time the users re opens the browser until the user closes the vulnerable tab.

Atomic Web Browser

Atomic Web Browser was our second browser tested. We performed all of our tests using the lite version, although the browser comes in two flavors Lite and full.

As with our previous tests we started by performing the tests to quickly check wether or not the browser was vulnerable to any of our known attacks vectors and to our surprise. Atomic was vulnerable to ALL of them. ☹

An attacker will be able to trigger

When performing our tests we found that the applications had two different url handlers atomic:// and atomiclite:// by searching the web and later decrypting the application and finding the url-handler atomiclite:// on the free application which was not as public as the atomic:// one.

In order to test our Cartero phishing attack we created a new proof of concept attack http://evilrovot.com/atomic.html page which we once more sent it as an SMS message and it perfectly triggered the attack.

❯❯❯ ./cartero GoogleVoice -d messages_accounts.json -b malicious_message.imsg

Messages App → Atomic Web Browser Lite → Telephone App

Final thoughts

Once more, as we concluded with our previous report, we feel this is not a critical finding on itself, but it does raises a broader issue flowing around mobile platforms on how trust boundaries are important when it comes to IPC — url-handlers — between apps.

Having said that, for this two browsers we are dealing with Telephone calls being vulnerable, resulting into attackers possibly using this in paid phone calls mining phishing attacks by email, SMS, etc to steal money, or by using cartero, for example we could generate a changing payload that will pass a unique identifier to the phone system linked to a unique. (i.e. tel://+0000;UNIQUE_ID ) to send emails messages to obtain valid phone numbers for those victims rendering the site on an iOS device that has atomic or atomic lite installed.

Timeline

Sadly, even though both of the vendors were contacted and the vulnerabilities were correctly reported, we received no response from any of them. With Mercury we tried hard ☹, their Contact Us url does not work, we send them twitter messages and we ended up finding their main company website Contact Us, but no answer was provided either.

We are publishing this in hope that the vulnerabilities once they are made public they will be fixed, although we are not sure this will happen, so you might want to be careful if using these browsers. ☹

Mercury vulnerability CVE-2014–7305
Atomic Lite vulnerability CVE-2014–7306

Sympathy for evil, the nature of our game…