SourMint: iOS remote code execution, Android findings, and community response

The Snyk research team is committed to helping secure developer ecosystems by researching and disclosing potential security exposures that would impact application developers. As part of this ongoing effort, Snyk has leveraged new information to conduct additional research into the Mintegral SDK. As a result of this research, additional findings have been uncovered.

The newest findings include the capability for Mintegral to execute code remotely via the SDK. Additionally, we’ve worked with developers to assist in their responses to our disclosures and there have been notable reactions from both Mintegral and the mobile advertising community that are worth highlighting as well. This is an update on the events that have occurred since our initial disclosure of the potential security and privacy issues we identified in the Mintegral advertising SDK.

At a glance:

• Snyk identified a potential backdoor functionality for Remote Code Execution via Ads presented by the SDK.

• We identified a hidden “download tracking” functionality in the Android version of the SDK reporting back to Mintegral any downloads made from Google domain, including Applications (APK), Google Documents and other resources.

• Mintegral has taken numerous actions to respond to the concerns highlighted in our initial disclosures.

• Response from the mobile advertising community has been swift including multiple players removing Mintegral from their platforms.

Summary

On August 24, 2020, Snyk announced the discovery of suspicious behaviors in the iOS version of a popular advertising SDK known as Mintegral. At that time, we had confirmed with partners in the advertising attribution space that at minimum, Mintegral appeared to be using this functionality to gather large amounts of data and commit ad attribution fraud. Our research showed that Mintegral was using code obfuscation and method swizzling to modify the functionality of base iOS SDK methods without the application owner’s knowledge. Further, our research proved that Mintegral was logging all HTTP requests including its headers which could even contain authorization tokens or other sensitive data.

Our discovery was widely reported across various press outlets and social media. As part of our research, we contacted the maintainers of some of the most popular apps that were affected by this SDK to inform them of our findings. We worked with a number of developers who asked for additional information and assistance in understanding the potential threats to their apps.

Since that time Mintegral announced that they were opening the source of their SDK to the market. While the SDK can (as of this writing) only be downloaded by registered partners, a major game publisher shared the source code with us for further analysis. We’ve also continued our research by digging deeper into the Android versions of the SDK in which we hadn’t found similar behaviors at the time of our initial disclosure.

This has resulted in some significant discoveries that necessitate an update to our previous disclosure. Additionally, Mintegral and the community at large have responded to the situation, and we felt a summary of the events was a good way to finalize our research into this SDK.

New iOS findings

Remote Code Execution (RCE)

After Mintegral announced they were making their SDK open source, we analyzed the changes they made between the previous version that we had analyzed and the new version they released as open source. Through this comparison, we found significant changes that removed dangerous functionality that had existed in the previous versions. Most notably, we discovered a backdoor which previously allowed Mintegral to invoke any native static method within the application, but could also lead Mintegral to remotely execute code on any device displaying an ad through their SDK.

Not surprisingly, our analysis found that Mintegral removed the anti-debug and proxy detection that we had identified and published in our previous disclosure. However, through additional analysis we discovered they also removed six other classes that we hadn’t previously identified:

• MTGCommandDispatcher

• MTGComponentCommands

• MTGRemoteCommand

• MTGRemoteCommandParameterModel

• MTGRemoteCommandParser

• MTGInvocationBoxing

We found that MTGBaseBridgeWebView, which is used extensively in the SDK to communicate with JavaScript, introduces the ability to execute arbitrary functions and native application code. We were able to build a proof of concept that showed how the backdoor makes it possible for Mintegral to invoke any function and execute arbitrary code via the SDK. This is a significant compromise of device security model, and user’s privacy and stands in direct violation of Apple’s policy.

For all the details, please see the technical research writeup.

We disclosed our new findings to Apple on October, 2nd and one day later, on October 3rd Apple sent out a notification to affected app developers sharing that their app is exposed to remote code execution through Mintegral’s SDK class. The notification asked app developers to fix the issue and publish a new version within a week for expedited review.

Hello,

We are writing to let you know about new information regarding your app.

Upon re-evaluation, we found that your app is not in compliance with the App Store Review Guidelines. Specifically, we found your app is in violation of the following:

Guideline 2.5.2 - Performance - Software RequirementsYour app includes the MTGInvocationBoxing class, which allows for remote code execution.

Next Steps

Please revise your app to remove use of the MTGInvocationBoxing class from your app and submit a new version for review.

To ensure there is no interruption of the availability of your app on the App Store, please submit an update within one week of the date of this message.

If we do not receive an update compliant with the App Store Review Guidelines within one week, your app will be removed from sale.

Please note, if your app is found to be out of compliance for any reason and rejected after the time period provided has elapsed, your app will be removed from sale until a compliant update is submitted, approved and released to the App Store.

Future submissions of this app may require a longer review time, and this app will not be eligible for an expedited review.

If you have any questions about this information, please reply to this message to let us know.

Best regards, App Store Review

HTTP request and OpenURL tracking

After our previous disclosure, Mintegral had disabled the data collection methods via their remote configuration functionality. However, in our subsequent research we found they’ve re-enabled that suspicious functionality a few weeks later. We observed this through several popular apps we initially sampled, but also confirmed this on a broader range of apps with the help of NowSecure.

The configuration served to the SDK during the initialization had all the 3 flags enabled:

• cudl - HTTP request tracking

• cud - OpenURL tracking

• cspn - StoreKit methods tracking

This means that for all apps with SDK older than 6.6.0.0, the extensive data collection and logging to Mintegral was active again. In many cases, this may happen without the developer’s consent, since this functionality of the SDK was always enabled, even if the developer or the mediation platform did not enable it.

Android SDK findings

After completing our research and disclosure of the iOS SDK, our research team turned its attention to the Android versions. While initially we had seen indications that the Android version contained similar functionality, armed with this new information, a deeper inspection of the code resulted in new findings.  For all the technical details, please see the technical research write up of the Android version of the SDK.

First and foremost, the Snyk Research team found that various elements of the SDK code are being obfuscated using the same type of proprietary encoding mechanism that was used to obfuscate code in the iOS version of the SDK. Once again, while it looks similar to standard Base64 encoding, there are subtle differences that prevent using a typical Base64 encoder/decoder to decode the strings.

After using the SDK’s own internal utility to decode obfuscated strings and data, our researchers uncovered a number of methods that employ checks to determine if a debugger is running or if any type of intercepting proxy is running to capture network communications. As with the iOS version of the SDK, the logging behaviors of the Android SDK are switched off if either a debugger or network proxy is found. The same website the research team identified as the target for the logging of this data was also referenced in the Android SDK.

As the research team continued their investigation they were able to locate the implementation of a broadcast handler which listens for two intents. The first handler is part of the previously mentioned debug detection scheme. The second, ACTION_PACKAGE_ADDED, is fired when a new app is installed on the device. The code in the Mintegral SDK that runs as a result of this intent checks to see if a package was added. Ultimately, this allows the SDK to receive data on every application that gets installed on the device through the play store.

Code of the onReceive() method in the mIntegral sdk

However, the SDK goes further and is also able to gather information on other downloads that happen outside of the play store. The AlphabObserver class, which extends the ContentObserver class, contains a method that captures URIs that are opened on the device. The method parses the URI to ensure that it is a download request and then if it is not already in the SDK’s app database, it adds it.

Ultimately, the behaviors are similar to what was seen in the iOS version of the SDK. However, the key difference is that because the SDK listens for a broadcast intent, it is able to receive data for app installations that were not initiated through the parent app in which the SDK was included. Essentially, if even one app on a user’s device leverages the Mintegral SDK, that instance of the SDK has visibility into every app install or downloads that occur on the device. The following video shows how a URL of a Google doc opened on the device is sent back to Mintegral.

Snyk has reported the details of our findings in the Mintegral SDK to Google who took the matter seriously and are continuing with their investigation. Google has confirmed that the technical analysis of the code that Snyk has provided is accurate. However, Google has not yet made any statement indicating if and how they intend to respond to the situation.

Community response

Since our initial disclosure at the end of August, there has been considerable response from the ecosystem and the community. Mintregral, for their part, denied any wrongdoing. In a subsequent blog post, Mintegral indicated that the unusual level of data collection they perform was intended to help their SDK better tailor ads to the user. On or around August 26, 2020, Mintegral made a considerable number of changes to their privacy policy. In a later announcement, Mintegral shared that they were opening the source of their SDK to the market.

AppsFlyer and Singular, two major Mobile Measurement Providers (MMPs) responded with their own analysis and implemented improvements to their anti-fraud product offerings to catch and prevent install hijacking attacks. Singular, released a blog post titled “SourMint? Protecting yourself from click hijacking fraud on iOS”. In their post, they analyzed and found evidence of click hijacking activity in some SDK-based networks, and compared the rate of suspicious activity before and after our publication.

What they found was that before our disclosure, those apps showed a significant level of suspected hijacked clicks. However, after our disclosure was made public, they observed a dramatic decrease in fake clicks that happened within less than 24 hours from the publication time.

A dramatic decrease in fake clicks after mintregral publication time

According to a notice on their website on September 3, 2020, Twitter’s mobile publishing and monetization platform MoPub removed mention of Mintegral as a network partner from their announcement originally published February 26, 2020. Additionally, in their mediation documentation, MoPub now lists Mintegral as a deprecated network with the indication that it should be “removed from all inventory segments and line items”.

IronSource mediation platform also responded to the news of the SourMint disclosure. They stated:

Recent reports raised serious allegations regarding Mintegral. ironSource conducted its own review, and, based on our findings, the ironSource mediation platform terminated all services and product support related to Mintegral.

IronSource mediation platform

Conclusions

Ultimately the situation with SourMint is very clear. It is undeniable that the Mintegral SDK uses various techniques to disguise the behavior of their SDK from developers, AppStore review, and independent security review. The hidden behaviors use techniques that allow the SDK to execute arbitrary code on iOS devices, and to access far greater data on user activity that would be necessary for ad attribution, exposing potentially private information to Mintegral. This data is accessed outside of the SDK itself making its collection very suspicious.

Throughout the years, the Snyk Security Research team has identified and responsibly disclosed thousands of vulnerabilities in open source packages, flagged the malicious backdoor in the very popular event-stream npm package, and covered several other cases of malicious components. Concluding the SourMint research, we’re happy to see the impact of our work, including the functionality we identified and disclosed being removed from the SDK, click hijacking and attribution fraud stopping, and the SDK getting open-sourced. Finally, we’re happy to see the increased awareness of the issue in the mobile development community, including companies in the mobile advertising world acting quickly to protect their users

For application developers, this highlights a need to ensure the trustworthiness of the monetization platforms they choose to use. Even with detailed code-level analysis, it can be very difficult to spot malicious or unanticipated behaviors. Responsibility for user notification of data collection ultimately falls on the application developer, so unknowingly including SDKs that access significant amounts of data such as this can cause the application owner to run afoul of app store policies. We hope that this disclosure has helped shed light on the bigger picture and that application developers have now greater awareness of the necessary steps to protect the private data of their users.

Timeline