Microsoft discovered high-severity vulnerabilities in MCE Systems’ mobile framework, which was utilized by numerous significant mobile service providers in pre-installed Android System applications, potentially exposing users to remote (although complicated) or local attacks. All companies concerned have corrected the vulnerabilities that affected applications with millions of installs. These vulnerabilities, when combined with the considerable system rights that pre-installed programs have, might have served as attack vectors for attackers to obtain system configuration and sensitive information.
As with many pre-installed or default programs that most Android devices now have, some of the impacted apps cannot be completely deleted or stopped without getting root access to the device. To fix these difficulties, we collaborated with MCE Systems, the framework’s creator, and the impacted mobile service providers. We applaud the swift and competent resolution of each of these issues by the MCE Systems technical teams, as well as the appropriate providers, ensuring that consumers may continue to utilize such an important framework.
Collaboration among security researchers, software providers, and the security community is important for continually improving the wider ecosystem’s defenses. As the threat and computing environment evolves, vulnerability discovery, coordinated response, and other kinds of threat information sharing are critical to protecting consumers from current and future attacks, regardless of the platform or device they use.
Our investigation into the framework flaws began with an attempt to better understand how a pre-installed System application may influence the overall security of mobile devices. We noticed that the framework, which is utilized by many apps, has a “BROWSABLE” service activity that an attacker could remotely activate to exploit many vulnerabilities that might allow adversaries to implant a permanent backdoor or gain significant control over the device.
The framework appeared to be built to provide self-diagnostic capabilities to find and repair faults affecting the Android device, implying that its permissions were naturally broad and provided access to significant resources. The framework, for example, was granted access to system resources and the ability to do system-related activities such as altering the device’s audio, camera, power, and storage settings. Also, we discovered that the framework was being utilized by default system programs to use its self-diagnostic capabilities, indicating that the associated apps also featured substantial device privileges that might be exploited through the vulnerable framework.
Our investigation also revealed that the apps were incorporated in the devices’ system image, implying that they were default programs deployed by phone service providers. All of the applications are accessible on the Google Play Store, where they are subjected to Google Play Protect’s automated security checks, which previously did not screen for these flaws. We shared our study with Google as part of our attempt to assist assure wide protection against these concerns, and Google Play Protect now detects these sorts of vulnerabilities.
Some mobile phone repair shops may also install the software com.mce.mceiotraceagent. Mobile users are encouraged to seek that app name and, if discovered, uninstall it from their phone.
The first thing that springs to mind when analyzing an Android application is inspecting its manifest, which is kept in the AndroidManifest.xml file. The manifest defines the application and its components, such as the ones listed below:
Checking the manifest of an app associated with the MCE Systems framework revealed some of its features and capabilities but did not instantly reveal any vulnerabilities or security risks. As a result, more investigation into the app’s operation was required through comprehending its permissions.
An examination of the app’s permissions on the mobile device found authorizations that might provide an attacker with strong access and capabilities. Control over the following was included under those permissions:
With access to these important resources, an attacker may use the software to install a permanent backdoor on the device.
The app’s manifest’s “Actions” section said that the Intent-filter element comprised activities with a “BROWSABLE” category. While the majority of Intents do not require a category, category strings specify which components should handle the Intent. The BROWSABLE category, in particular, enables the target Activity to be activated from a web browser to display data referenced by a link, such as an image. BROWSABLE actions are appealing to attackers because they may be attacked through malicious web pages and other Intent-based assaults.
The manifest’s intent-filter element specifies how the Activity can be activated. The Activity in the app’s case might be launched by just visiting a link with the “mcedigital:/” scheme. This would launch the com.mce.sdk.AppActivity Activity with an arbitrary Intent (besides the scheme).
We analyzed the consequences of activating the com.mce.sdk.AppActivity. This Activity, also known as appActivity, relates to the many features provided by the app. Because AppActivity extends Activity, it contains an onCreate method, which normally handles the creation of Intent.
Here’s a brief description of AppActivity:
Thus, if a user clicks this:
mcedigital://ignored\?arbitrary_params
The App’s WebView loads the following web page:
file:///android_asset/applications/user/reflow-container-bundled/index.html?arbitrary_params
The index.html web page (which is a built-in component of the Android app) fetches two JavaScript files:
We examined both bundle.js (JarvisJSInterface) and the WebView (JarvisWebView) to better understand their interactions.
The following are the main characteristics of the WebView, JarvisWebView class:
Because it employs a JavaScript Bridge to allow the execution of certain functions within an Android app, a JavaScript Interface is a visible target for security concerns. Three methods are exposed in the case of JarvisJSInterface:
By far the most intriguing technique is the request method, which does the following:
The serviceCall function is extremely useful since it allows the WebView to freely invoke “services.” But what exactly are these services?
We produced a list of services that provide the WebView entire access over the device after we analyzed the services given by this framework per the app manifest. Among the most noteworthy services are:
These services derive from the “Service” basic class and implement two methods:
Here’s how the Camera service configures its methods:
We discovered numerous vulnerabilities when analyzing the mce framework. While mobile service providers can adapt their applications according to the mce architecture so that they are not identical, the vulnerabilities we uncovered can all be exploited in the same way—by injecting code into the web view. However, since their apps and framework customization employ various settings and versions, not all providers are necessarily vulnerable to all disclosed vulnerabilities.
We discovered a command-injection vulnerability, CVE-2021-42599, in the Device service stated before. This service provides extensive capabilities, including the ability to halt the actions of a specific package. The client has complete control over the parameter “value,” and simply executes the following command:
am force-stop "value"
Because the argument is not sanitized, an attacker might use backticks or quote marks to execute arbitrary code, such as:
am force-stop "a"; command-to-run; echo "a"
According to mce Systems, the mechanism behind this vulnerability has subsequently been removed, and it is no longer included in more advanced framework versions.
The mce framework’s services also warned that the following vulnerability existed in the logic of the JavaScript client for apps that are set to allow unencrypted communications, such as the app we first examined. Interestingly, the client code is deeply obfuscated dynamic JavaScript code spread over numerous files, primarily bundle.js. Because of the implicit trust between the JavaScript client and the JarvisJSInterface server, an attacker who could inject JavaScript content into the WebView would inherit the app’s existing rights.
We identified two injection tactics that attackers are likely to employ:
We noticed that the client’s obfuscated code could not inject JavaScript from the GET parameters after reverse-engineering it. The sole capability allowed was to interfere with certain of the client’s self-tests at initialization, such as a battery-draining test or a Wi-Fi connection test. The WebView-fetched plaintext pages that we identified, on the other hand, may be injected into with a PiTM attack.
As a result, our proof-of-concept (POC) exploit code was:
Some of the applications we examined did not retrieve plaintext pages. As a result, we looked into CVE-2021-42601, a local elevation of privilege vulnerability that allows malicious software to get system app rights.
We observed that the main Activity in the applications described above attempted to handle a deep link (a link that starts an app rather than a browser on click) with Google Firebase. This deep-link handling, interestingly, attempted to deserialize a structure named PendingDynamicLinkData (representing a link) from an Intent Extra byte array with the key com.google.firebase.dynamiclinks.DYNAMIC-LINK DATA. This structure was then utilized by the mce framework to build multiple JSON Objects that may contain data from the original link’s categoryId query parameter, and finally ended up in the member mFlowSDKInput to be injected into the JarvisWebView instance in an unsafe manner:
Because the categoryId query parameter may contain apostrophes, arbitrary JavaScript code might be injected into the WebView. We chose to inject code that would connect to a server and load a second-stage code similar to the one utilized in our PiTM scenario.
We closely worked with the mce Systems engineering team and identified that the unsafe loadUrl invocations with JavaScript injections were caused by the framework’s asynchronous operation paradigm. When the JavaScript client makes a request, it expects to be alerted when the request is completed. Because the Android JavaScript Bridge only enables simple types (for example, Strings) to be delivered, the mce framework warned the JavaScript client by injecting JavaScript with potentially hazardous inputs (the results themselves).
We proposed to mce Systems a significantly modified software design that eliminates unsafe JavaScript injection. The following is a description of the information flow in our proposal:
This eliminates the requirement for the JavaScript client to poll for asynchronous results while data is safely transported between the client and the server.
Surprisingly, Google AndroidX has a comparable API: webMessageListener. While the aforementioned API functions similarly to our idea, it only supports Android versions higher than Lollipop. As a result, the new mce framework now checks the Android version and, if supported, employs this new Google API or our supplied solution for older devices.
This is just one example of how we work together to safeguard our cross-platform ecosystem. All of our disclosed vulnerabilities, according to mce Systems, have been fixed.
Microsoft works with customers, partners, and industry experts to constantly enhance security. Responding to the increasing threat landscape necessitates expanding our capabilities into new devices and non-Windows platforms, as well as further coordinating research and threat information sharing throughout the security industry. This instance demonstrated the need for professional, cross-industry collaboration in effectively mitigating difficulties.
Also, joint research like this enriches our platform-agnostic protection capabilities. For example, intelligence from this analysis assisted us in ensuring that Microsoft Defender Vulnerability Management can identify and remediate devices with these vulnerabilities, giving security operations teams comprehensive visibility into their organizational exposure and allowing them to reduce the attack surface. Furthermore, while we are unaware of any active exploitation of these mobile vulnerabilities in the field, Microsoft Defender for Endpoint’s mobile threat protection features dramatically improve mobile device security by identifying possible exploits, malware, and post-exploitation activity.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com