Xiaomi the Money: Pwn2Own 2023 Exploit Chain
This talk details a multi-stage exploit chain against the Xiaomi 13 Pro, leveraging vulnerabilities in the 'GetApps' application store to achieve remote code execution. The researchers demonstrate how to bypass security filters by manipulating the application's WebView and JavaScript interface to force the installation of a malicious application. The presentation highlights the challenges of zero-day research in a competitive environment, including the impact of rapid vendor patching and regional firmware variations. The researchers successfully demonstrate the full exploit chain, resulting in a shell on the target device.
Exploiting the Xiaomi GetApps Store: A Masterclass in Chained Vulnerabilities
TLDR: Researchers at NCC Group demonstrated a multi-stage exploit chain against the Xiaomi 13 Pro that achieved remote code execution via the pre-installed GetApps store. By manipulating a WebView and bypassing JavaScript interface filters, they forced the silent installation of a malicious application. This research underscores the critical risk of pre-installed vendor software and the necessity of rigorous input validation in hybrid native-web application components.
Mobile security research often focuses on the OS kernel or high-profile messaging apps, but the real attack surface for many users lies in the "value-add" software pre-installed by device manufacturers. The research presented at DEF CON 2024 regarding the Xiaomi 13 Pro is a perfect case study in why these applications are often the weakest link. By chaining together a series of flaws in the GetApps store, the researchers moved from a simple browser-based trigger to full remote code execution, proving that even "secure" vendor apps can be turned into powerful delivery vehicles for malware.
The Anatomy of the Chain
The attack centers on the GetApps application, specifically its handling of deep links and its internal WebView implementation. The researchers identified three distinct ways to force the installation of applications from the store without user interaction. The core of the exploit relies on the fact that the GetApps store exposes a JavaScript interface to its WebView, which is intended to facilitate store operations but lacks sufficient access control.
To trigger the chain, an attacker needs a user to click a malicious hyperlink in a web browser. This link leverages a "Browsable Intent," a standard Android mechanism that allows web pages to launch specific application activities. In this case, the intent targets the JoinActivity within the GetApps store. By passing a crafted URL as a parameter, the attacker can force the store to load a local file from its private directory.
The researchers discovered that they could inject custom JavaScript into this WebView. Once they achieved this, they could call the exposed JavaScript interface functions, specifically install(String) and openApp(String). The install function, when called, would silently pull and install any application available on the store. The openApp function would then launch that newly installed application. By hosting a malicious APK—which they dubbed "Sunfish"—on the store, they could ensure that the victim’s device would not only install the payload but also execute it immediately.
Bypassing the Filters
Xiaomi attempted to secure this interface with a series of filters, but their implementation was flawed. The WebView was designed to only load "valid" URLs, which were defined as either HTTPS links from a whitelisted domain or local files within the data/data/com.xiaomi.mipicks/ directory.
The researchers bypassed these restrictions by performing a source code review of the JavaScript files bundled within the application. They found that while most files had robust sanitization to prevent cross-site scripting (XSS), one file—integral-dialog-page.html—failed to properly sanitize user input. By encoding their XSS payloads to bypass the built-in Java-based filters, they were able to execute arbitrary JavaScript within the context of the privileged WebView.
The filter was looking for specific string patterns, such as <script>. By using alternative HTML elements like <svg> with an onload event and encoding the payload, they successfully bypassed the filter. This is a classic example of why blacklisting input is rarely effective; if you don't account for every possible encoding or alternative tag, the filter will eventually fail. You can review the OWASP XSS Prevention Cheat Sheet for a better understanding of why these filters are so fragile.
Real-World Implications for Pentesters
For those conducting mobile application security assessments, this research highlights the importance of auditing the JavaScript-to-Native bridge. When an application uses a WebView and exposes native methods via addJavascriptInterface, it effectively expands the attack surface to the web. If those native methods perform sensitive actions—like installing apps or accessing the file system—they must be protected by strict authentication and authorization checks.
During an engagement, you should prioritize identifying these bridges. Use tools like drozer to enumerate exported activities and inspect the WebView configuration. If you find an exposed interface, treat it as a high-severity finding. The impact is not just limited to the application itself; as shown here, it can lead to full device compromise.
The Patching Paradox
The most frustrating aspect of this research was the vendor's response. Xiaomi’s patching cycle is rapid, but it is also reactive and often incomplete. When the researchers reported the issues, Xiaomi pushed updates that removed the vulnerable files but failed to account for the fact that these files might already exist on the user's device. This left a window of opportunity for attackers who knew how to leverage the existing, albeit "removed," code.
Furthermore, the regional variations in firmware meant that the exploit behavior was inconsistent. The researchers had to navigate different regional configurations, which is a common hurdle in mobile research. This highlights the need for defenders to ensure that security patches are not just applied to the build process, but are also verified on the device itself to ensure that old, vulnerable components are actually purged.
The vulnerability was eventually assigned CVE-2024-2624. While the researchers were eventually acknowledged, the process was far from smooth. For those interested in the full technical breakdown, the official documentation for the tools used remains the best starting point for reproducing these types of attacks in a controlled environment.
Security is a moving target, and as this research proves, the most effective exploits are often the ones that chain together seemingly minor flaws into a devastating, high-impact attack. Keep digging into those pre-installed apps; they are rarely as secure as the vendor claims.
CVEs
Vulnerability Classes
Target Technologies
Attack Techniques
OWASP Categories
Up Next From This Conference

Breaking Secure Web Gateways for Fun and Profit

Listen to the Whispers: Web Timing Attacks That Actually Work

Abusing Windows Hello Without a Severed Hand
Similar Talks

Inside the FBI's Secret Encrypted Phone Company 'Anom'

Kill List: Hacking an Assassination Site on the Dark Web

