CourseMonster

Android apps with millions of installs are vulnerable to high-severity issues - Course Monster Blog

Written by Marbenz Antonio | 20/06/2022 6:38:11 AM

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.

Uncovering the vulnerabilities

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.

Analyzing apps that use the MCE framework

App manifest and permissions

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:

  • Permissions (for example, camera access, internet access, and others)
  • Activities and how they respond to Intents sent to them
  • Content providers
  • Receivers and the kind of content they expect to receive
  • Services

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:

  • Networking: access the internet, change the Wi-Fi status, network state, NFC, and Bluetooth settings
  • File access: write to and read from external storage
  • Peripherals: access the camera, capture audio, obtain fingerprint information, and determine the physical position of the device
  • Private information: phone numbers, account details, and contact information
  • Management: install apps and modify device settings

With access to these important resources, an attacker may use the software to install a permanent backdoor on the device.

BROWSABLE activities

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).

Going deeper: Examining the core features of the mce framework

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.

AppActivity

Here’s a brief description of AppActivity:

  1. AppActivity contains a “webView” attribute with the type “JarvisWebView,” which is a customized class that extends WebView.
  2. When an AppActivity is created, it contains some optional display options from the Intent (if they exist) and then loads a predetermined web page into the WebView. That preconfigured page can obtain arbitrary query parameters from the Intent’s data; that is, anything after a “\? ” will be included on the website.

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:

  • config.js: a nonexistent file
  • bundle.js: contains much of the app’s logic

We examined both bundle.js (JarvisJSInterface) and the WebView (JarvisWebView) to better understand their interactions.

JarvisWebView and JarvisJSInterface

The following are the main characteristics of the WebView, JarvisWebView class:

  • JavaScript is supported (with setJavaScriptEnabled)
  • It enables for purposeful cross-scripting (with setAllowUniversalAccessFromFileURLs)
  • It offers a JavascriptInterface named JarvisJSInterface (through addJavascriptInterface).

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:

  • init(String): accepts a string to be used as a JavaScript callback method; in our case, this will always be window.AndroidCallback.
  • windowClose(): executes a callback defined by the Android app.
  • request(String): sends a service request to the server from the JavaScript client (Android app)

By far the most intriguing technique is the request method, which does the following:

  1. The provided string is interpreted as a JSON object.
  2. The following elements are extracted from the JSON object:
    • Context: a client-generated random GUID used to connect requests and answers.
    • Service: the service to which we are about to make a request.
    • Command: an integer
    • Data: are optional parameters that are submitted to the service call.
  3. Calls the method serviceCall, which locates the registered service, retrieves the method based on the command number, and then invokes that method using Java reflection.

The serviceCall function is extremely useful since it allows the WebView to freely invoke “services.” But what exactly are these services?

Services offered by the mce framework

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:

  • Audio: access and modify volume levels, as well as play a tone with a specified length and frequency
  • Camera: take a silent snapshot
  • Connectivity: NFC, Wi-Fi, and Bluetooth can be used to control and acquire crucial information.
  • Device: features many device control techniques such as battery drain, factory reset, and accessing the information on applications, locations, sensor data, and much more
  • Discovery: set the device to discoverable
  • Location: get the location in multiple modes and change the location state
  • Package manager: obtain package information and secretly install a new app
  • Power: obtain charging state
  • Sensor: collect sensor data such as barometer readings, light readings, proximity readings, and if fingerprinting is working
  • Storage: get material like papers, media, photos, and videos

These services derive from the “Service” basic class and implement two methods:

  • setServiceName: for service identification purposes
  • setServiceMethodMapfor establishing the relationship between the command integer and the method name, parameter names, and argument types

Here’s how the Camera service configures its methods:

  • Method 0 is “getCameraList” and expects no arguments.
  • Method 1 is “captureStillImageNoPreview” and expects one String argument.

Vulnerability findings

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.

Outdated command-injection vulnerability (CVE-2021-42599)

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.

Exploitation by JavaScript injection with PiTM in certain apps

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:

  1. Change the behavior of the JavaScript client by passing particular GET parameters from the BROWSABLE Intent.
  2. Trigger an app with the BROWSABLE Intent to transform into a person-in-the-middle (PiTM) and observe all of the device’s communications. If the client attempts to fetch external material and interpret it as a script or HTML, inject JavaScript code.

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:

  1. PiTM the target device and trick the user into visiting a link with the “mcesystems:/” schema.
  2. Inject the following JavaScript into one of the plaintext page responses:
    • Call init with our callback function to hijack the JavaScript interface.
    • To obtain service, use the JavaScript interface request method.
    • Using XHR, send the data to our server for information collection (XMLHttpRequest)
  • Call init with our callback function to hijack the JavaScript interface.
  • To obtain service, use the JavaScript interface request method.
  • Using XHR, send the data to our server for information collection (XMLHttpRequest)

Local elevation of privilege with deserialization followed by injection (CVE-2021-42601)

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.

Software design against JavaScript injection vulnerabilities

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:

  1. The JavaScript client calls the request function on the Android JavaScript Bridge, passing in the request as well as a request ID.
  2. The Java server processes the request and saves the outcome in a cache. The cache then associates request IDs with results.
  3. The Java server notifies the client by carefully injecting the JavaScript loadUrl(“javascript:window.onMceResult(<requestID>);”) into the WebView. The request ID is the only non-constant string, and it is readily sanitized. This technique “wakes the customer up.”
  4. The Android JavaScript Bridge is invoked by the JavaScript client implementation of onMceResult via the function String fetchResult (String requestId). It should be noted that this function returns a string (which contains the result).

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.

Improving overall security through threat intelligence sharing and research-driven defenses

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