Mobile Pwn2Own 2017 Results and the Economics of Mobile Exploits
We can learn a lot from the latest Mobile Pwn2own competition. The economics of exploit development from (partially) public competitions such as mobile pwn2own and public bugs. By analyzing Mobile Pwn2Own’s results and the (limited) information disclosed we can learn what it means for mobile phone vendors, as well as us, phone owners. The information is based on ZDI’s twitter feed and two blog posts and a video summarizing the results, as well as with my own analysis and knowledge based on things I see in the wild.
The lack of trust of population against targeted / advanced attacks is demonstrated well in the following picture:
ERC’s lack of trust in smartphones is not a pure paranoia. It is could be well explained even by following well publicized events such as Mobile Pwn2Own or the monthly updates release notes. The time it takes to develop an exploit by a very skilled exploit developer can vary between days to months. Let’s look at the numbers and the attack vectors used in this year’s Mobile Pwn2Own:
Summary of results per device:
iPhone (iOS 11.1): 2 Wifi exploit chains (including one collision), 2 Safari exploits
Samsung Galaxy S8: 1 baseband exploit (writing a file to the device as payload), 2 browser exploits.
Huawei: 1 baseband (change IMEI as payload), 1 browser exploit
iPhones (with the latest iOS 11.1): 4 successful attempts out of 4 attempts:
First exploit: Keen team used WIFI exploit. The trigger to this attack is interesting: simply by connecting to the WiFi. In total, they used four bugs exploit chain to achieve persistence and install an unsigned app.
Chain: Connect to Wifi -> Privilege Escalation -> Payload (app installed in this case) + persistence (survive reboot).
Second exploit: By 360: WiFi exploit — three bugs in total. Interesting fact: One of the bugs (the initial RCE?) was exactly the same vulnerability used by Keen team!
Third exploit: Safari RCE + Sandbox escape.
Forth exploit: Safari RCE + System service exploit
Samsung Galaxy S8: 3 success, 1 failure, 1 submissions withdrawn
First exploit: Samsung Internet Browser : failed attack (keen)
Second exploit: by 360: Samsung browser followed by local privilege escalation in a system app to achieve persistence.
Third exploit: MWR Labs exploited Samsung Browser ==> Chrome => Samsung apps => Installed an app. Used total of 11 different bugs.
Forth exploit: Acez exploited a Stack Overflow in the baseband processor to achieve the ability to “write persistent data on the target handset”. By looking at the day2 summary video, Acez wrote a file to the SD card.
Huawei Mate Pro 9:
2 successful attempts, 1 failed attempt (NFC, Keen).
First exploit: Baseband attack — RCE Stack Overflow in Baseband Processor and modified IMEI as payload.
Second exploit: MWR Labs: Browser Exploit (five logical bugs)
Summary and analysis of this year’s result
According to @alexjplaskett: It only took five man-weeks to complete the Huawei browser exploit with 5 bugs.
EDIT: Changed from Huawei to Samsung following Alex’s note.
EDIT2: Changed back from Samsung to Huawei following Alex’s DM
Threat landscape, TL;DR: sophisticated baseband/WiFi attacks are becoming more common. After initial information became public, it’s not surprising that researchers like to poke in these areas — especially since these threats may require to bypass less security mitigations. Both Baseband attacks were stack-overflows!
Remote browser attacks are continuing to be popular. Baseband, NFC, WiFi as attack vectors weren’t unknown before, but multiple submissions in Baseband and Wifi (as well as one NFC submission) should raise a big red flag for vendors.
The threat landscape didn’t only evolve in theory. Practical examples of baseband attacks demonstrate an increasing sophistication.
Two interesting payloads during this year’s contest:
1 payload to change IMEI — this payload could create real-world monetary implications for phone vendors and carriers. Many of the stolen phones today are blocked using shared IMEI blacklists. Avoiding such detection, changes the equation for organized crime. For example, the gang that stole $300,000 worth of iPhone X on Friday, will find it challenging to sell them without access to a bug that allows to change IMEI.
1 payload to write to device storage — Assuming this capability is not limited only to the internal storage as demonstrated in the Mobile Pwn2Own Video, this payload prove that it is possible to infect the device host OS directly from the baseband. As far as I’m aware it is the first public demonstration of a real-world, public, capability to jump from the baseband to the host.
Lack of mitigations in baseband / WiFi chip code: both exploits on baseband (Samsung and Huawei) were stack-overflows. While the host operating system had evolved significantly in terms of mitigations, it is not the same for the baseband codebase. In the host OS, exploitable stack-overflows are quite rare nowadays, and require some sophistication (e.g. bypass Stack cookie and ASLR) hence not trivially exploitable.
There was no information hinting that infoleak was part of the exploit chain. It could mean that this step wasn’t even necessary to achieve remote code execution on the baseband. As the information of baseband hacking is becoming more and more common knowledge, this attack vector is becoming dangerous for the entire mobile eco system.
WiFi Attacks: Two different chains except for one collision. It is unclear wether the initial RCE was the collisions bug or one of the bugs used in the chain. Interesting payload: WiFi attacks led to full persistence on host, and exfiltration of data. Full RCE simply by connecting to a network on iOS. Interesting fact: both WiFi exploits were on iOS.
Browser exploits: Browser exploits were used to access all three phones. It shouldn’t be a surprise anymore that browser are one of the most preferred method for exploit writers.
Bug collisions in this competition we had one bug collision in the WiFi attack on iOS. This bug allowed for Keen to achieve full control over the device and install an app, and for 360 to leak sensitive data from a system app. The chains were different, but we can only wonder, how many other researchers stumbled into exactly the same bug (and already used it in the wild?).
Failed exploit chains
The official contest day began with our random drawing for order, which put Tencent Keen Security Lab (@keen_lab) targeting the Samsung Internet Browser on the Samsung Galaxy S8 up first. Unfortunately, the attempt failed as they could not get their exploit chain to work within the allotted time.
Getting so many different exploits, tested and fully functional prior to pwn2own competition is tough. Some vendors release an update a day or two prior to the competition (in many cases in-order to mess with the offsets of the exploits?!). Keen failed with the NFC exploit on Huawei and the browser exploit on Samsung. There is no reason to believe that they do not have the full exploit, or at least most components of the chain fully working.
EDIT: It appears that the exploit does work — just didn’t work for them during Mobile Pwn2OWN. Keen team’s NFC exploit demonstration on latest Huawei:
Mitigations — More damage than helpful from detection POV ?
What does it mean for vendors: From privacy POV Sandboxing may help, but from a security POV: Sandboxing seems to help the attackers more than the users. It’s time to adapt vendor’s security strategy and philosophy. It’s time for better partnerships, collaborations, and allowing users who want to protect themselves, to have full access to the device that they purchased. No, having the ability to flash a new kernel is not a good enough step. It should be part of the OS, built in. Something like Windows UAC for smartphones.
Attackers having more privileges than the owner of the phone is unacceptable and mustn’t be accepted as a status quo. “Widespread Targeted Attacks” is already a thing (but more on that, and persistence in future posts).
What all of this mean to users: the enormous amount of exploits, and attack vectors that were not previously relevant to PCs (baseband, NFC, and partially WiFi) — are posing a serious risk to data safety. Prepare accordingly. Mobile Threat Defense [my personal favorite  ;)] can definitely help. At the same time, users should pressure vendors to add UAC-like capability to smartphones.
It’s time to shift the control back to the phone owners. Vendors cannot handle all of the security on their own. As soon as smartphone vendors understand that, the better it will be for phone owners.
What does it mean for threat actors: The economics of exploit development are quite simple: it cost slightly more to develop a generic exploit for iOS, than a targeted (one vendor, one version) Android exploit, but the TAM for iOS is around 1+ billion devices. Android’s fragmentation comes to the rescue, and from exploit development POV, exploits are dependent on the OS version, build, chipsets. Some Android vendors have tens of thousands of builds. Writing a generic exploit is almost impossible.
Summary: iOS exploits are most cost effective from attackers POV.
*Thoughts are my own and does not represent any of the companies I’m associated with.