Abusing iOS url handlers on Apple’s Messages
Exploiting iOS Chrome and FaceTime url-handlers to automate attacks on FaceTime calls. How to create a Social Engineering attack using known iOS issues and cartero.
Work based on @neculaesei work on how to use iOS applications url handlers to make Phone calls on other applications, besides Messages. Update: Also apparently on some similar work presented by @gepeto42 on BSidesLV 2014.
Background
As part of developing new and interesting ways of social engineering people, at Section9Labs we introduced a new Framework called Cartero — a simple multi-platform CLI modular social engineering Framework — that allows people to perform several attacks. Our last addition to the list of attacks is the IMessage command that allows Security Researchers to send massive amounts customized “templated” messages through Apple’s Messages automatically.
In addition to the command, we wanted to look for ways to exploit url-handlers that have always been considered a weak point in iOS — Gracias Ariel for the idea ☺. We embarked on a quest to find an interesting attack vector as a proof of concept for our tool and to prove that weaponing Apple’s Messages was indeed useful not only to send spam.
Research work
The first url scheme tested was tel:// and quickly realized that things had been improved significantly lately on Messages and basic attacks were not working as expected. In addition, we found as part of our research an interesting post by @neculaesei pointing out a resent 0-day vulnerability on a big amount of applications,. We immediately saw an opportunity to use this as a proof of concept, but sadly the author claimed that the attack was not working on Messages. “que cagada” ☹
But hey, we are as we say “hard-headed” and given that he mentioned that he did not did extensive research into other apps, we said, why not, It is clearly that messages, will not work, but other apps most surely will have the vulnerability, so we raised the question: is there a way to link the two and display a link to a user that will trigger the exploit ?.
MESSAGES → handler:// → APP → handler:// EXPLOITED_APP
We began by sending test.html attachments with a known working payload but the Messages’ preview view will not render javascript correctly.After a few tries we decided to call it a FAILURE and tested our attack using a bridge or secondary app that will render and trigger the exploit.
Our first guess ended up being the correct one. What application is massively installed on iOS, renders websites very well and has a complete set of url-handlers. Google Chrome ☺
Google Chrome comes with an extensive list of url-handlers googlechrome:// , googlechromes:// , googlechrome-x-callback://, etc
The first thing we tested were things such as:
googlechrome://tel://1111
googlechrome://tel%3A%2F%2F+1111
googlechrome-x-callback://x-callback-url/open/?x-source=Phone&x-success=tel%3A%2F%2F%2B1111&url=http%3A%2F%2Fwww.google.com
but the all ended up in FAILURE ☹. Theywill be interpreted as tel//1111 and/or they will trigger a pop-up message that will require people to click and loose the purpose of an “automated” attack.
It also looked like we could launch attacks, by jumping through google-chrome and force other urls using x-success, but yet again, it required the user to click on a button, it could potentially work as a social engineering attack, but it involves more user interaction, in addition to a click.
Now, having family abroad, I actually use FaceTime more than the actual phone app itself, besides having grandfathered unlimited data plan on the phone, helps a LOT ☺ Anyhow, back to the point, We decided to test these attacks with facetime:// and facetime-audio:// and to my surprise they worked. “vamos carajo!!!”
This is not the greatest vulnerability given that there are not pay per use FaceTime numbers and criminals could not use this to steal money, but by all means it could be used to automatically launch video and audio to users with a single click and possible capture video and audio for a few seconds until users realize what has happened and prove a point and possibly automate screen captures on our end.
Proof of Concept attack:
Using the already documented attacks, we simply need a vulnerable site with a XSS or page construction capabilities, that would allow us to render the following code. Once a victim clicks on a link hxxp://evilrovot.com/hack.html the victim iOS device, will open safari because URLs automatically recognized by Safari and rendered, the site, will automatically click on a google chrome url handler.
step1.html
Once the code above renders, will redirect us to Chrome if we have it installed and it land on the second page, which will execute the vulnerability on Chrome and it will automatically dial facetime:// call without asking the user to confirm or deny.
step2.html
Proof of Concept video
The video below shows how a simple click on a message link will initialize the multiple jump attack and initialize a FaceTime call without any user interaction.
In addition, this or any other url-handler issue can easily be weaponized and sent to hundred, thousands or millions of accounts using custom scripts or our own project Cartero with the IMessage command as it is shown on the shell snippet below:
❯❯❯ ./cartero IMessage -d messages_accounts.json -b malicious_message.imsgNow, as we like to think, if we found these issues -yes, more are coming- and we can easily weaponize it to send it to that many people, most surely there has to be someone is already exploiting these bugs in the form of malware (Skype vulnerability a while back — http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/) to perform calls to pay lines, to control, change or overwrite files or events, exploiting possible actual vulnerabilities on the code (i.e. overflows), redirect attacks from safari to a vulnerable app, etc. We have only scratched the surface of the URL handlers and we are sure there are many more documented and undocumented handlers waiting to be exploited.
Final thoughts
Finally, we think 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. These should not trust input or external calls without due diligence and the necessary security checks. It also raises a lot of questions about how far can we take these types of attacks and what can we do using social engineering tools like Cartero and other url-handler issues out there yet to be found …
Update: As of 9/22 Google published a new version — Version: 37.0.2062.60— of Google Chrome for iOS that contains the fixes for these vulnerability above reported. Anything before that is vulnerable, so it is highly recommended to update.
Sympathy for evil, the nature of our game…
Timeline
8/24 — Issue was reported to Google
8/27 — Expanded bug to add facetime-audio as well
8/27 — Both issues were accepted and tracked.
9/10 — Status update communication with team.
9/12 — Migrated to Chromium project.
9/12 — Issue fixed on Chromium open source project.
9/22 — Google Chrome for iOS update available
9/23 — Section9Labs makes issue public.
10/7 — Google makes vulnerability public CVE-2014–3187
UPDATE: 10/7/1 http://googlechromereleases.blogspot.com/2014/10/chrome-for-ios-update.html
