Alex Plaskett & James Loureiro - The Mate Escape

### Overview In this talk, James Loureiro and Alex Plaskett from MWR InfoSecurity share their experience competing in Mobile Pwn2Own 2017. While other teams targeted the Samsung Galaxy S8, James and Alex focused on the Huawei Mate 9 Pro in the browser category. Given tight deadlines (two to three man-months) and increasing platform mitigations against memory corruption, they pursued an exploit chain based entirely on logic vulnerabilities. Their strategy allowed them to pivot out of Google Chrome and achieve full remote code execution without user interaction.

### Key Topics - **Target Selection & Attack Surface**: Modern Android devices ship with massive pre-installed bloatware—around 200 OEM apps on Samsung and Huawei devices. These proprietary applications offer a wide, poorly audited attack surface with elevated permissions. - **Logic Bugs vs. Memory Corruption**: While memory corruption requires defeating mitigations like ASLR, sandboxing, and lacks cross-device stability, logic bugs are architecture-agnostic, reliable, and harder to detect. However, logic chains often require many bugs, deep application context, and are harder to automate or fuzz. - **Automation & Tooling**: MWR used internal scripts to decompile APKs in bulk, grep for dangerous keywords (e.g., `install`, `update`, file I/O), and JEB for reverse engineering. They prototyped graph-theory tooling to trace reachability from exported intents to dangerous sinks (such as `DexClassLoader`). Dynamic tools like Frida and Xposed assisted in tracing behavior and prototyping.

### Technical Details The full exploit chain against the Huawei Mate 9 Pro relied on chaining several logic issues across multiple components:

1. **Browsing & Whitelist Bypass**: A victim visits a malicious link in Chrome, which invokes a browsable intent registered to the Huawei Marketplace application under the `hiapp://` protocol schema. Although Huawei enforced a domain whitelist (`hiapp.hicloud.com`, `vmall.com`, `huawei.com`), the check used a flawed regex (`.*`) and lacked HTTPS enforcement, allowing navigation to malicious content via HTTP/DNS spoofing. 2. **Intent Proxying via JavaScript Bridge**: The loaded webview exposed a native Java bridge object (`window.hispace` / `hiAppSpace`). An exposed method, `launchApp`, processed user-supplied URIs with `Intent.parseUri` and `setPackage`. By utilizing the `android-app://` URI schema with embedded intent extras, the researchers turned browsable intents into arbitrary exported intents across any application on the device. 3. **Pivot to Huawei Reader**: Using this intent proxy primitive, the exploit targeted the Huawei Reader app (`com.huawei.reader`). Although low-privileged, the app contained multiple unvetted interfaces, including a webview bridge with a `doCommand` function. 4. **Directory Traversal File Write**: Through the Reader's online download feature, an unvalidated JSON `fileName` parameter allowed path traversal (`../../`). This gave an arbitrary file write primitive anywhere writable by the app, though it could not overwrite existing files. 5. **Arbitrary File Deletion via MD5 Path Traversal**: To replace an existing binary, the researchers exploited a cache-cleaning deletion feature that checked for failed open attempts. The app constructed deletion targets using an MD5 hash of the filename appended to the failure path. By pre-calculating the MD5 hash of a path with traversal sequences (`../../plugin/dfservices/classes.jar`), they induced the deletion of an existing plugin JAR file. 6. **Arbitrary Code Execution via DexClassLoader**: Huawei Reader implemented plugin functionality that loaded JAR files from an SD card directory using `DexClassLoader`. After deleting the original JAR and writing a malicious `classes.jar` via path traversal, navigating to a `.txt` file triggered the plugin loading routine. The loaded payload executed a BusyBox binary to spawn a remote reverse shell.

### Takeaways - Chaining multiple low-severity logic flaws across OEM applications can defeat modern sandbox protections without relying on traditional memory corruption. - Pre-installed vendor apps remain a critical vulnerability vector due to inconsistent security audits and risky patterns like dynamic code loading (`DexClassLoader`) from shared or exposed directories. - Defending Android ecosystems requires strictly validating browsable intents, sanitizing inputs in JavaScript bridges, and eliminating insecure custom scheme parsers.