Credit is owed to David Kaplan for this research.

The IBM X-Force Application Security Research Team has discovered a remote code execution (RCE) vulnerability in MIUI, which we privately disclosed to Xiaomi in January.

A New Flaw for Xiaomi

MIUI is the flavor of Android (currently based on Android 6.0) developed by Xiaomi. While developed primarily for use on Xiaomi’s own devices, MIUI builds are freely available for numerous devices from other vendors.

Xiaomi is currently the third-largest smartphone manufacturer in the world, behind Samsung and Apple, in terms of devices shipped. More than 70 million devices were delivered in 2015, and many millions of these may be impacted by this vulnerability.

The vulnerability we discovered allows for a man-in-the-middle (MitM) attacker to execute arbitrary code as the highly privileged Android system user. It has been remediated by Xiaomi from MIUI Global Stable version 7.2, and IBM strongly recommended that users update their firmware as soon as possible to ensure they are not vulnerable.

We would also like to commend Xiaomi’s security team for excellent incident response. Within days of disclosure, the vulnerability was confirmed and classified, and we were provided with details of when a fix would be delivered.

Inside the Remote Code Execution Process

IBM found a vulnerability that allowed an attacker to execute code on a target device via a MitM attack. This attack also involved code injection inside of the update framework. These attack vectors are not new and have been previously disclosed in other platforms.

The vulnerability resides in the analytics package, which is present in various applications that come with MIUI. All applications with the analytics package are vulnerable to remote code execution via MitM. We identified at least four vulnerable applications in the MIUI developer Rom version 6.1.8, including the built-in browser app. These had differing sets of privileges and capabilities.

An RCE vulnerability in any of these applications allows attacker-supplied code to run with the privileges of its host app. If a vulnerable application was found to be running as the system user, a good portion of the Android’s user space would be compromised. IBM identified such an app running as the system user and being vulnerable to code injection, which we then managed to successfully exploit in our lab.

Vulnerability Details

The vulnerability itself is conceptually straightforward. The analytics package polls a RESTful web service periodically to determine whether there is an update available. The server responds with the following short JSON response:

“force”: 0,

“md5”: “3238b0f5af9931fc73a43eb02a2ee528”,

“url”: “http://update.address/update.apk”,

“v”: “1.8.0”

The response is parsed to determine whether the current version is less than the version advertised in the update response. If so, the Android application package (APK) referred to by the URL key is downloaded and extracted to the file system within the local application sandbox context. This code is then loaded by the host application and executed.

The update transaction is performed over an insecure transport link such as HTTP. A MitM attack would allow a malicious user to inject a JSON response to force an update by replacing the URL and MD5 hash with those of a malicious APK containing arbitrary code. Since there is no cryptographic verification of the update code itself, the analytics package will replace itself with the attacker-supplied version via Android’s DexClassLoader mechanism.

Mitigating the Vulnerability

This class of vulnerability seems to be a recurring theme in the security community. To mitigate such vulnerabilities, developers should take care to only transact code-related data over a verified, secure transport with certificate pinning such as TLS. Additionally, the code itself should be cryptographically signed and properly verified by the host application prior to execution.

Furthermore, we believe that a discussion should take place as to whether any application should have the ability to execute unsigned code via DexClassLoader, dynamic library injection or any other method on the Android platform. The recurring incidents of what are essentially identical bugs might indicate that the platform should consider exerting a great level of control over such activities and change the default policy to block these actions.

More from Software Vulnerabilities

Analysis of a Remote Code Execution (RCE) Vulnerability in Cobalt Strike 4.7.1

Command & Control (C2) frameworks are a very sensitive component of Red Team operations. Often, a Red Team will be in a highly privileged position on a target’s network, and a compromise of the C2 framework could lead to a compromise of both the red team operator’s system and control over beacons established on a target’s systems. As such, vulnerabilities in C2 frameworks are high priority targets for threat actors and Counterintelligence (CI) operations. On September 20, 2022, HelpSystems published…

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory. SCM systems are used in the majority of organizations to manage source code and integrate with other systems within the…

X-Force Research Update: Top 10 Cybersecurity Vulnerabilities of 2021

From 2020 to 2021, there was a 33% increase in the number of reported incidents caused by vulnerability exploitation, according to the 2022 X-Force Threat Intelligence Index. A large percentage of these exploited vulnerabilities were newly discovered; in fact, four out of the top five vulnerabilities in 2021 were newer vulnerabilities. Vulnerability exploitation was the second most common initial infection vector observed by IBM Security X-Force in 2021, falling closely behind phishing. Cybercriminals are finding new ways of bypassing security…

How Log4j Vulnerability Could Impact You

MITIGATION UPDATE: New vulnerability in 2.17 — CVE-2021-44832 Upgrade to 2.17.1 to mitigate this vulnerability Do NOT enable JNDI in any versions Follow: https://logging.apache.org/log4j/2.x/security.html If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers.…