...stuff I do and things I like...

Tuesday, November 08 2016

iOS WebView auto dialer bug

TL;DR: iOS WebViews can be used to automatically call an attacker controlled phone number. The attack can block the phone's UI for a short amount of time and therefore prevent the victim from canceling the call. The bug is an application bug that likely is due to bad OS/framework defaults. One major issue with this vulnerability is that it is really easy to exploit. App developers have to fix their code as soon as possible. The Twitter and LinkedIn iOS apps are vulnerable (other apps might be vulnerable too). Demo videos here: Twitter and LinkedIn (embedded videos are below on this page).

About a week ago (on a Friday) I read an news post [1,2] about a guy who got arrested for accidentally DoSing 911 by creating a web page that automatically dialed 911 when visited it from an iPhone. This was most likely due to a bug with the handling of TEL URI [4,5]. I immediately thought about a bug I reported to Apple in late October 2008 [3]. I couldn't believe this bug has resurfaced so I investigated. The article said something about posting links on Twitter.
    If you think automatically dialing a phone number after clicking a link in an app is not a big issue think again. DoSing 911 is pretty terrible but there are other examples such as expensive 900 numbers where the attacker can actually make money. A stalker can make his victim dial his phone number so he gets his victim's number. Altogether things you don't want to happen.
Anyway ... I went and looked at the iOS Twitter app. I got a very simple auto phone dialer working in a very short time. I was happy and also devastated that it was that easy. I first thought I reproduced the exact bug but later after re-reading the articles [1,2] more carefully I determined that it is likely a different bug or at least a different trigger. The article reported heavy use of JavaScript and pop-ups being shown and such. My original trigger was one line of HTML (a meta-refresh tag that points to a TEL URL) due to this I decided to report the bug to Twitter via their Bug Bounty program on HackerOne. I never reported to a bug bounty program before so I was happy to gain some experience (I normally report via security@), but it is 2016 and companies pay for bugs so here we go. Twitter acknowledged that it looks like a problem within a few days.
    On Nov. 6th I updated the bug report to Twitter to add the UI blocking issue (continue reading) and uploaded a video. Today Twitter simply closes the bug as a duplicate without any comment. While this might be a simple duplicate they should have an interest in playing nice and being thankful to those who report bugs they find in their spare time. Because of this action I decided to post the full details of the issue today.

During the weekend I took some time to further investigate the issue. I determined that this might be a general issue with iOS apps the use WebViews to display content. I tested a few popular apps I had installed. Vulnerable apps need a way for users to post web links that will be opened in a WebView inside the app itself. Apps that open links in mobile Safari or Chrome would not be vulnerable (I tested this). One app I tested fairly early was the LinkedIn app since LinkedIn basically is social media for the business context. People can send messages and post updates. Updates usually are text and link. I posted a link and clicked it and yes it dialed my other phone (demo video below).

I wanted to submit the bug to LinkedIn and found that they have a bug bounty program. Unfortunately it was a private bounty and you would only be added if you previously submitted bugs. I tried to get around it but it didn't work. After some thinking I decided to not report it to LinkedIn privately but openly (parallel to this blog post). It is 2016 after all and if they don't want to add me to their program that is their choice. In general I will likely not report bugs outside of a bug bounty program if a private bug bounty program exists.

Another weekend comes I have some time and started playing with the bug again. Actually I started looking at my PoC from 2008 while trying to figure out if I report the bug to LinkedIn or not. After playing around for a bit I more or less get my old PoC working with the Twitter and LinkedIn apps. WOW!

Taking one step backwards. The original bug I reported to Twitter was triggering a phone call by visiting a website that redirect to a TEL URL. One could do this with various techniques such as: http-meta refresh, iframe, setting document.location, window.location, or an HTTP redirect (Location header). This would simply dial a number. The victim would see the dialer and the target number on the screen and of course could just cancel the call by pressing the big red button. Just causing the call is already bad since an unobservant person will be baffled (why is my phone dialing some number).

The beauty of my 2008 bug was that I could block the phone's UI for a few seconds and therefore prevent the user from canceling the call. I managed to abuse exactly the same trick to block the UI that I used in 2008. The trick is to cause the OS to open a second application while the phone is dialing the given number. Opening applications is pretty straight forward, you open a URL that causes the OS to spawn another application. This can be anything from the messages app (via the SMS: URL) or iTunes (via the itms-apps: URL). You can pretty much get any application to launch that has a URI binding. In 2008 I used a SMS URL with a really really long phone number to block the UI thread. My best guess on how this works is that the IPC subsystem actually has difficulties to move several kilobytes of URL data through the various layers into the app and the target app might also not be super happy about really large URLs. I ended-up with the code below. The code uses the combination of meta-refresh tag and window.location to execute the attack. The codes delays setting the window.location by 1.3 seconds to guarantee that the dialer is executed first. The delay cannot be too long otherwise the WebView will not execute the URL handler for launching the messages app. Basically you have to get the timing just right.


The PoC to trigger this bug.

Below two video demonstrations of this attack. You can clearly see that the UI is not responsive for a short amount of time. The time is long enough to make somebody pickup on the other side (especially service hot lines automatically pickup).






Normal good app behavior:
Apps should normally check the URL schema before executing it and show the user a pop-up dialog before executing an app on the device. Some examples are shown below:


Mobile Safari asking before calling the Apple Support number. This is how good apps should behave!


Dropbox showing a warning but not showing the target number. Ok but could be better.


The Yelp app normally behaves like Safari but if you hit it with an HTTP redirect it does not show the target number. I just included this for the fun of it.

App developers should review their use of WebViews to determine if they are vulnerable to this attack. Vulnerable apps need to be fixed. Service providers like Twitter and LinkedIn can inspect links posted to their sites for containing malicious code and prevent those links from being posted to their service.

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. I reported this issue to Apple.

References:

Friday, November 04 2016

Using Google Fi on an iPhone

TL;DR: Google Fi on an iPhone is iMessage plus Google Wifi calling with awesome international coverage.

Google Project Fi is super interesting as it provides an actual low cost alternative to other carriers especially if you travel. The free data-only SIM is also a nice add-on.

Project Fi is exclusively targeting users of Google Nexus Android devices and you actually need one of the supported phones to activate the SIM which can be ordered on the Fi website.

I currently use an iPhone SE (mainly due to the device's tech specs and form-factor - I can't stand phablets!) so I was curious if I can just buy a Google Fi SIM and use it in an iPhone or any other phone actually. Of course I'm not the first person to think about this, but the only decent article on this topic is this one. Sadly most articles that are returned for a search on iPhone Google Fi are just totally useless. Even this article is not good.

I decided to just order Google Fi and a data-only SIM and give it a try. I used a Nexus 5x that I have access to for activating the SIM card. The activation process is really simple. Basically you need to put the SIM card into a compatible phone and install the Google Fi app. Done.

The activated SIM card can be put into any other phone, I tried an iPhone 5c and it just works. You automatically get the APN settings (the mobile data settings) pushed to your phone. Cellular data immediately works! Voice calls work too.

Wifi calling also works, although it (obviously) only works via the Hangout app but it does work. I put my phone into airplane mode and called the number from another phone and yea it rings.

The only service that is a bit unsatisfying is SMS (text messaging). The default option for Google Fi is to send and receive SMS via Google Hangout. Google Hangout exists for iOS and if you login with your Google Account that is associated with your Google Fi service you just install Hangouts and everything just works! If you actually want to use the iOS Messages app you can deactivate SMS via Hangout in the Hangout app on your phone. This will allow you to send and receive SMS via Messages. The only issue here is that incoming SMS messages get some Google specific data attached, as shown below. This is a little annoying but is only on incoming messages (you don't look like an idiot when sending messages to other people). Most of my contacts are on iMessage anyway these days so this is a non issue. Also I'm ok with using Hangouts for SMS since yea iMessage and other messaging apps.


The switch to change between native SMS and Hangout SMS the switch above it does the same for voice calls (to enable Wifi calling).


The broken* incoming SMS, the ~Dgr... is added by Google Fi, this does not show up in Hangouts. Other people have reported that this just went away after short time.

Things that don't work? switching between T-Mobile, Sprint, and US Cellular since this is done via the Google Fi app on Android devices (I actually don't have any idea about this yet).

Preliminary Conclusions
    Altogether Google Fi looks pretty cool and works with an iPhone (besides the hick-up with SMS). iMessage works (it is just an Internet service after all). Wifi calling via Hangouts is nice.

    If you are a hardcore iOS/Mac user Google Fi is too much Google for you. I'm a Linux user with an iPhone so Google Fi makes a lot of sense. Desktop calls and SMS via Hangouts is a nice thing to have in addition to iMessage.


Google Fi on an oooold phone (Android 4.0). Hangouts seem to work fine too.

*The data is a BASE64 encoded blob, no obvious data after looking at a bunch of them of an hour or less.

Tuesday, October 18 2016

Mobile Security News Update October 2016

Conferences
    PacSec October, Tokyo. Demystifying the Secure Enclave Processor by Mathew Solnik. Finding Vulnerabilities in Firefox for iOS by Muneaki Nishimura.

    ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM) October, Vienna Austria. All talks are related to mobile security.

    O'Reilly Security Conference October, NYC. Securing 85% of the world's smartphones by Adrian Ludwig. How Plantronics honed its headsets to create secure wearables by Erik Perotti.

    SyScan360 November, Shanghai. Browser Bug Hunting and Mobile by Francisco Alonso and Jaime Penalba. Demystifying the Secure Enclave Processor by Mathew Solnik. Running Code in the TrustZone Land by Edgar Barbosa. Analysis of iOS 9.3.3 Jailbreak & Security Enhancements of iOS 10 by Team Pangu. Security Vulnerabilities on Online Payment: Summary and Detection by Zhang Qing and Bai Guangdong.

    KiwiCon November Wellington, NZ. Let's do the Timewarp Again by Karit.


I'm going to be at the O'Reilly Security Conference on Monday the 31st (maybe also the other days). I super excited to speak at KiwiCon this year!

I'm interested in Google's Project Fi does anybody have insights into using it with non Android phones? I've found several posts on this topic but nothing convincing yet. Posts also seem conflicting.


Best of mobile security in pictures:

source ThreatPost

I've seen this warning a lot in the last couple of weeks while traveling:
This is the real reason for the Galaxy Note 7 recall

While searching for the link to the recall:


Links

Tuesday, September 20 2016

Mobile Security News Update September 2016

Conferences
    Black Hat EU November, London UK. ARMAGEDDON: HOW YOUR SMARTPHONE CPU BREAKS SOFTWARE-LEVEL SECURITY AND PRIVACY Speaker: Clementine Maurice, Moritz Lipp. DETACH ME NOT - DOS ATTACKS AGAINST 4G CELLULAR USERS WORLDWIDE FROM YOUR DESK Speaker: Bhanu Kotte, Dr. Silke Holtmanns, Siddharth Rao. MOBILE ESPIONAGE IN THE WILD: PEGASUS AND NATION-STATE LEVEL ATTACKS Speaker: Max Bazaliy, Seth Hardy. POCKET-SIZED BADNESS: WHY RANSOMWARE COMES AS A PLOT TWIST IN THE CAT-MOUSE GAME Speaker: Federico Maggi, Stefano Zanero. ROOTING EVERY ANDROID: FROM EXTENSION TO EXPLOITATION Speaker: Di Shen, Jiahong (James) Fang. SIGNING INTO ONE BILLION MOBILE APP ACCOUNTS EFFORTLESSLY WITH OAUTH2.0 Speaker: Ronghai Yang, Wing Cheong Lau. STUMPING THE MOBILE CHIPSET Speaker: Adam Donenfeld. WIFI-BASED IMSI CATCHER Speaker: Piers O'Hanlon, Ravishankar Borgaonkar.

    PacSec Tokyo Japan, October. Demystifying the Secure Enclave Processor by Mathew Solnik.
The most interesting read this week was The bumpy road towards iPhone 5c NAND mirroring a paper by Sergei Skorobogatov. In this paper he shows how to implement a NAND mirroring attack against an iPhone 5C. The basic idea behind this attack is erase the PIN failure counter between each set of tries to avoid the artificial brute force delay and to avoid data deletion after N failed PINs. The paper goes into great detail on various problems he encountered while implementing the attack. I highly recommend reading this paper. The picture below is taken from this paper.

Google's Project Zero now has an Android "Prize" for achieving RCE on a Nexus device with only knowing it's email address or phone number. Apparently you can't use a BTS (via @jduck) for this attack. Overall this looks interesting, I wonder if anybody is going to claim the money soon. Announcement: Project Zero Prize.

Links

Tuesday, August 30 2016

Mobile Security News Update August 2016

Conferences
    Black Hat EU November: ARMAGEDDON: HOW YOUR SMARTPHONE CPU BREAKS SOFTWARE-LEVEL SECURITY AND PRIVACY by Clementine Maurice and Moritz Lipp. DETACH ME NOT - DOS ATTACKS AGAINST 4G CELLULAR USERS WORLDWIDE FROM YOUR DESK by Bhanu Kotte, Siddharth Rao and Silke Dr Holtmanns. POCKET-SIZED BADNESS: WHY RANSOMWARE COMES AS A PLOT TWIST IN THE CAT-MOUSE GAME by Federico Maggi and Stefano Zanero. STUMPING THE MOBILE CHIPSET by Adam Donenfeld.

    DerbyCon September: Beyond The ?Cript: Practical iOS Reverse Engineering by Michael Allen. AWSh*t. Pay-as-you-go Mobile Penetration Testing by Nathan Clark. Breaking Android Apps for Fun and Profit by Bill Sempf.

    AppSec USA November: QARK: Android App Exploit and SCA Tool by Tushar Dalvi and Tony Trummer. SecureMe - Droid: Android Security Application by Vishal Asthana and Abhineet Jayaraj. OWASP Reverse Engineering and Code Modification Prevention Project (Mobile) by Dave Bott and Jonathan Carter. ShadowOS: Modifying the Android OS for Mobile Application Testing by Ray Kelly.

Apple now has a bug bounty program. Details were presented at Black Hat in Ivan Krstic's talk BEHIND THE SCENES OF IOS SECURITY. Also see Starting this fall, Apple will pay up to $200,000 for iOS and iCloud bugs (via Ars).

Motorola confirms that it will not commit to monthly security patches. This is pretty bad since I actually liked their Pure Edition devices (devices that basically are just AOSP).

Protecting Android with more Linux kernel defenses. They added some features from Grsecurity. This makes me happy.

Google's Android has gotten so out of control that $55 billion Salesforce had to take drastic measures, basically Salesforce in the close future will only support specific Samsung Galaxy and Nexus devices. This is an interesting way to deal with the very diverse Android ecosystem.

Pegasus Spyware / Trident for iOS was based on 3 vulnerabilities unsurprisingly a WebKit memory corruption, a Kernel info leak, and a kernel memory corruption. The spyware was capable of accessing text messages, iMessages, calls, emails, logs, and more from apps including Gmail, Facebook, Skype, WhatsApp, Viber, Facetime, Calendar, Line, Mail.Ru, WeChat, Surespot, Tango, Telegram, and others. (Source: Lookout Technical Report).

Oversec.io seems to implement our idea of mobile OTR on top of any messenger app. Oversec still looks very beta and I haven't tried it out. If anybody has tried it I would like to hear about it.

Pictures of the month:
(source: @raviborgaonkari)

(source: @marcwrogers)

Links

Tuesday, July 12 2016

Mobile Security News Update July 2016

Conferences
    SummerCon July, Brooklyn, NY. THE FIREWALL ANDROID DESERVES: A CONTEXT-AWARE KERNEL MESSAGE FILTER AND MODIFIER by DAVID WU.

    Defcon August, Las Vegas. SITCH - Inexpensive, Coordinated GSM Anomaly Detection by ashmastaflash. A Journey Through Exploit Mitigation Techniques in iOS by Max Bazaliy. Stumping the Mobile Chipset by Adam Donenfeld. How to Do it Wrong: Smartphone Antivirus and Security Applications Under Fire by Stephan Huber and Siegfried Rasthofer. Discovering and Triangulating Rogue Cell Towers by JusticeBeaver (Eric Escobar). Samsung Pay: Tokenized Numbers, Flaws and Issues and Salvador Mendoza. Attacking BaseStations - an Odyssey through a Telco's Network by Henrik Schmidt and Brian Butterly. Forcing a Targeted LTE Cellphone into an Unsafe Network by Haoqi Shan and Wanqiao Zhang.

Another month has passed and I'm super late again on this blog post.

HushCon EAST badges were super awesome (picture below) did some hacking on them with Trammell Hudson: Hushcon 2016 pagers.


The wait is over, here is the final blog post including source code on Qualcomm's TrustZone: Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption Source extractKeyMaster

The Android Security Bulletin July 2016 fixes a really large number of bugs, including a Remote code execution vulnerability in Bluetooth and Remote code execution vulnerability in OpenSSL & BoringSSL. It is really good to see stuff being fixed and talked about in the open.

Summary on Pokemon GO's permission to your Google Account by the guys from Trail of Bits.

Funny picture of the month:


Links

Monday, June 06 2016

Mobile Security News Update June 2016

Conferences
    Black Hat USA August, Las Vegas. 1000 WAYS TO DIE IN MOBILE OAUTH by Eric Chen, Patrick Tague, Robert Kotcher, Shuo Chen, Yuan Tian, Yutong Pei. ADAPTIVE KERNEL LIVE PATCHING: AN OPEN COLLABORATIVE EFFORT TO AMELIORATE ANDROID N-DAY ROOT EXPLOITS by Tao Wei, Yulong Zhang. ATTACKING BLUETOOTH SMART DEVICES - INTRODUCING A NEW BLE PROXY TOOL by Slawomir Jasek. PANGU 9 INTERNALS by Hao Xu, Tielei Wang, Xiaobo Chen. SAMSUNG PAY: TOKENIZED NUMBERS, FLAWS AND ISSUES by Salvador Mendoza. CAN YOU TRUST ME NOW? AN EXPLORATION INTO THE MOBILE THREAT LANDSCAPE by Josh Thomas. DEMYSTIFYING THE SECURE ENCLAVE PROCESSOR by Mathew Solnik, Tarjei Mandt. BAD FOR ENTERPRISE: ATTACKING BYOD ENTERPRISE MOBILE SECURITY SOLUTIONS by Vincent Tan THE ART OF DEFENSE - HOW VULNERABILITIES HELP SHAPE SECURITY FEATURES AND MITIGATIONS IN ANDROID by Nick Kralevich.

    Shakacon July 13-14, Honolulu, HI. FRUIT VS ZOMBIE: DEFEAT NON-JAILBROKEN IOS MALWARE BY CLAUD XIAO. Bluetooth Low Energy...by SUMANTH NAROPANTH, CHANDRA PRAKASH GOPALAIAH & KAVYA RACHARLA
Defcon still doesn't have the agenda or accepted talks up.

The Qualcomm Mobile Security Summit was super awesome once again. Good talks, interesting hallway conversations and always good to see friends.


SektionEins (Stefan Esser) release a jailbreak and anomaly detection app for iOS and eventually got band from the AppStore by Apple. The speculation is that Apple wants to hide the fact that certain sandbox and security features don't work as advertised and thus his App got band. The app likely wasn't band just because it can detect a jailbreak since like every app does exactly this, including apps like WhatsApp. There are also several process list viewers for iOS.


I finally could checkout a Blackberry PRIV. The actual hardware looks pretty sweet. I got a quick demo of the security and privacy features added by RIM, specially DTEK. I really liked the device security/privacy status overview, every phone should have that.

Qualcomm KeyMaster keys etracted from TrustZone waiting for the writeup. The previous blog posts where super good already, but this one should be really interesting.

Links