The Intent-filter element in the manifest dictates how the Activity can be triggered. In the app’s case, the Activity could

be triggered by simply clicking a link with the “mcedigital://” scheme. This would start the com.mce.sdk.AppActivity Activity with an Intent with arbitrary data (besides the scheme).

Digging deeper: Reviewing the mce framework’s main functionality

We reviewed the effects of triggering the com.mce.sdk.AppActivity. Also known as appActivity, this Activity refers to the different functionalities provided by the app. AppActivity extends Activity and therefore has an onCreate method, which traditionally handles the creating Intent.

AppActivity

Here’s a brief description of AppActivity:

1. AppActivity has a member called “webView” and type “JarvisWebView,” a specialized class that extends WebView.
2. Upon creation, AppActivity has some optional display choices from the Intent (if they exist) and then loads a predefined web page to the WebView. That predefined page can get arbitrary query parameters from the Intent’s data; that is, everything after a “\?” will be added to the web page.

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 app’s index.html web page (which is an asset built into the Android app) loads two JavaScript files:

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

Since we wanted to understand the interplay between bundle.js (JarvisJSInterface) and the WebView (JarvisWebView), we analyzed both.

JarvisWebView and JarvisJSInterface

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

• It allows JavaScript (with setJavaScriptEnabled)
• It allows cross-scripting deliberately (with setAllowUniversalAccessFromFileURLs)
• It exposes a JavascriptInterface (with addJavascriptInterface) called JarvisJSInterface

A JavaScript Interface is a conspicuous target to look for security issues, as it uses a JavaScript Bridge to allow invoking specific methods inside an Android app. In the case of JarvisJSInterface, three methods are exported:

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

The request method is by far the most interesting, as it performs the following:

1. Interprets the given string as a JSON object
2. Extracts the following pieces from the JSON object:
   • Context: a random GUID generated by the client, used to link requests and responses
   • Service: the service we are about to call to
   • Command: an integer
   • Data: optional parameters sent to the service call
3. Invokes the method serviceCall, which finds the registered service, gets the method based on the command number, and eventually invokes that method using Java reflection

 

The serviceCall is a powerful method, as it allows the WebView to invoke “services” freely. But what are these services, exactly?

Services offered by the mce framework

After we examined the services offered by this framework per the app manifest, we then obtained a list of services that practically give the WebView complete control over the device. The most notable services include:

• Audio: access and manipulate volume levels, as well as play a tone with a given duration and frequency
• Camera: take a silent snapshot
• Connectivity: control and obtain valuable information from NFC, Wi-Fi, and Bluetooth
• Device: includes various device controlling mechanisms like battery drainage, performing a factory reset, and obtaining information on apps, addresses, sensor data, and much more
• Discovery: set the device to discoverable
• Location: obtain the location in various modes and set the location state
• PackageManager: acquire package info and silently install a new app
• Power: obtain charging state
• Sensor: acquire sensor data such as barometer data, light data, proximity data, and whether fingerprinting is working
• Storage: obtain content such as documents, media, images, and videos

These services inherit from a base class named “Service” and implement two methods:

• setServiceName: for service identification purposes
• setServiceMethodMap: for setting up the mapping between the command integer and the method name, argument names, and argument types

For example, here is the Camera service setting its methods:

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

 

Figure 3: The Camera service setting its methods

Vulnerability findings

Based on our analysis of the mce framework, we discovered several vulnerabilities. It should be noted that while mobile service providers can customize their apps respective to mce framework so as not to be identical, the vulnerabilities we discovered can all be exploited in the same manner—by injecting code into the web view. Nonetheless, as their apps and framework customization use different configurations and versions, not all providers are necessarily vulnerable to all the discovered vulnerabilities.

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

We found a command-injection vulnerability, tracked as CVE-2021-42599, in the Device service mentioned in the previous section. This service offers rich functionality, including the capability to stop activities of a given package. The client fully controls the argument “value,” and simply runs the following command:

am force-stop "value"

Since the argument is not sanitized, an attacker could add backticks or quotation marks to run arbitrary code, like the following:

am force-stop "a"; command-to-run; echo "a"

 

According to mce Systems, they have since removed the functionality behind this vulnerability and it is no longer present in more advanced framework versions.

Exploitation by JavaScript injection with PiTM in certain apps

The services offered by the mce framework further indicated that the following vulnerability resided in the logic of the JavaScript client for apps that are configured to enable plaintext communications such as the app that we initially analyzed. Interestingly, the code for the client is a heavily-obfuscated dynamic JavaScript code that is implemented over several files, mainly bundle.js. Due to the blind trust between the JavaScript client and the JarvisJSInterface server, an attacker who could inject JavaScript contents into the WebView would inherit the permissions that the app already has.

We conceived two injection strategies most likely to be leveraged by attackers:

1. Affect the JavaScript client behavior by supplying specific GET parameters from the BROWSABLE Intent.
2. Trigger an app with the BROWSABLE Intent to become a person-in-the-middle (PiTM) and view the device’s entire traffic. Inject JavaScript code if the client ever tries to fetch external content and interpret it as a script or HTML.

Once we reverse-engineered the client’s obfuscated code, we discovered that it could not inject JavaScript from the GET parameters. The only capability permitted was to affect some of the client’s self-tests upon initialization, such as a battery-draining test or a Wi-Fi connectivity test. However, the WebView-fetched plaintext pages that we discovered could be injected into with a PiTM attack.

Our proof-of-concept (POC) exploit code was therefore:

1. Perform a PiTM for the target device and lure the user into clicking a link with the “mcesystems://” schema.
2. Inject JavaScript into one of the plaintext page responses that does the following:
   • Hijack the JavaScript interface by calling init with our callback method
   • Use the JavaScript interface request method to get servicing
   • Send the data to our server for information gathering using XHR (XMLHttpRequest)

 

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

Some of the apps we analyzed did not pull plaintext pages. Thus, we looked for a local elevation of privilege vulnerability, allowing a malicious app to gain the system apps’ privileges, tracked as CVE-2021-42601.

In the apps mentioned above, we discovered that the main Activity attempted to handle a deep link (a link that launches an app instead of a browser on click) with Google Firebase. Interestingly, this deep-link handling tried to deserialize a structure called PendingDynamicLinkData (representing a link) from an Intent Extra byte array with the key com.google.firebase.dynamiclinks.DYNAMIC_LINK_DATA. This structure was used later by the mce framework to generate various JSON Objects that might contain data from a categoryId query parameter in the original link, and eventually ended up in the member mFlowSDKInput to be injected into the JarvisWebView instance in an unsafe way:

 

Since the categoryId query parameter might contain apostrophes, one could inject arbitrary JavaScript code into the WebView. We decided to inject a code that would reach out to a server and load a second-stage code, which was the exact one we used for our PiTM scenario.

 

Software design against JavaScript injection vulnerabilities

We worked closely with the mce Systems engineering team and discovered that the reason for unsafe loadUrl invocations with JavaScript injections was that the framework used an asynchronous model of operation. When the JavaScript client performs a request, it expects to be notified later when there are results. Since Android JavaScript Bridge only allows primitive types to be sent (for example, Strings), the mce framework notified the JavaScript client by injecting JavaScript with potentially unsafe arguments (the results themselves).

We offered mce Systems a slightly different software design that prevents unsafe JavaScript injection. The description of the flow of information in our proposal is as follows:

1. The JavaScript client invokes the request method on the Android JavaScript Bridge, supplying the request itself along with a request ID.
2. The Java server performs the request and stores the result in a cache. The said cache then maps request IDs to results.
3. The Java server notifies the client by carefully injecting the JavaScript loadUrl(“javascript:window.onMceResult(<requestID>);”) into the WebView. Note that the only non-constant string is the request ID, which can easily be sanitized. This method “wakes the client up”
4. The JavaScript client implementation of onMceResult invokes the Android JavaScript Bridge with the method String fetchResult(String requestId). Note that this method returns a string (which contains the result).

This way, the JavaScript client does not need to poll for asynchronous results while data is safely transferred between the client and the server.

Interestingly, Google AndroidX offers a very similar API: webMessageListener. While the said API works quite similarly to our suggestion, it only supports Android versions greater than Lollipop. Thus, the new mce framework now checks the Android version and uses this new Google API if supported or our offered solution for older devices.

The above is just one example of our collaboration to help secure our cross-platform ecosystem. According to mce Systems, all of our reported vulnerabilities were addressed.

Improving security for all through threat intelligence sharing and research-driven protections

Microsoft strives to continuously improve security by collaborating with customers, partners, and industry experts. Responding to the evolving threat landscape requires us to expand our capabilities into other devices and non-Windows platforms in addition to further coordinating research and threat intelligence sharing among the larger security community. This case highlighted the need for expert, cross-industry collaboration to effectively mitigate issues.

Moreover, collaborative research such as this informs our seamless protection capabilities across platforms. For example, intelligence from this analysis helped us ensure that Microsoft Defender Vulnerability Management can identify and remediate devices that have these vulnerabilities, providing security operations teams with comprehensive visibility into their organizational exposure and enabling them to reduce the attack surface. In addition, while we’re not aware of any active exploitation of these mobile vulnerabilities in the wild, Microsoft Defender for Endpoint’s mobile threat defense capabilities significantly improve security on mobile devices by detecting potential exploits, malware, and post-exploitation activity.

We will continue to work with the security community to share intelligence about threats and build better protection for all. Microsoft security researchers continually work to discover new vulnerabilities and threats, turning a variety of wide-reaching issues into tangible results and improved solutions that protect users and organizations across platforms every single day. Similarly inquisitive individuals are encouraged to check opportunities to join the Microsoft research team here: https://careers.microsoft.com/.