An investigation carried out by researchers from the cybersecurity company Snyk has recently been made public, in which it has been discovered that an advertising framework includes malicious functionality among its code.
Mintegral SDK is a popular SDK for including advertising in applications that use it. Around 1,200 apps in the Apple App Store use it to show advertising to users, in an attempt by its developers to earn revenue from their applications.
It is estimated that these applications accumulate a total of 300 million downloads per month.
The SDK is available for iOS and Android, and although the investigation has focused on the iOS version, the possibility of Android presenting the same fraudulent functionality as the iOS version can't be ruled out, although the researchers claim that they have found no trace of it on Android. The version the investigation looked into is the 184.108.40.206, released on July 16th of this year.
The malicious code contained in the SDK allows its developers to spy on end users who install the application, in addition to producing ad click attribution fraud, which means that they can listen to the clicks on the ad and attribute those clicks to other advertising campaigns belonging to the developers.
Apparently, their main objective isn't really to spy on users, instead this is just collateral damage that occurs due to how ad fraud is carried out. The main objective seems to be to carry out the fraud so that the SDK developers can make money from the fake clicks.
The implementation of its fraudulent functionality is carried out through what's called method swizzling. This technique consists of replacing the implementation of an Objective-C function (Apple's language for app development) with a new one, in which malicious code is introduced.
Code that replaces the implementation of [UIApplication openURL:]
The Mintegral SDK developers use this technique to replace the implementation of the iOS API functions: UIApplication openURL and SKStoreProductViewController loadProductWithParameters, in addition to registering a custom class of the NSURLProtocol class.
With these three elements under its power, the SDK is capable of intercepting any request made from the application, thus being able to spy on the user's activity, and having access to all the data sent and received in the application.
Specifically, it is capable of intercepting HTTP requests, URLs opened from the app and links from the App Store that are opened in the application. It's clear that thanks to the ability to intercept HTTP requests, the malicious SDK is capable of spying on the user.
By taking advantage of other advertising platforms that the developers have included in their application and reporting the legitimate clicks as if they were clicks on the attackers' ads.
Mobile application developers often use more than one advertising platform to try to maximize the profit generated. Taking advantage of this, the developers of the fraudulent SDK intercept clicks on advertising that is not part of their platform and send the information related to said click to the log server.
Once the click information is sent, the way the attribution mode operates is used to replicate the same request, but it replaces the campaign with its own. This way, the attribution server finally logs the fraudulent click generated by the SDK developers' server.
This fraud is used in cases where the advertising campaign tries to get the user to download the advertised application.
When the user downloads such an application, the attribution server attributes the click and the download to the attackers' campaign instead of the legitimate campaign and click. This means that the money generated by this advertising goes into the attackers' pocket rather than to the developers of the legitimate application.
To replace the implementation of the methods required by the malware, the malware needs to receive a series of parameters from the server with specific values. If these parameters are not received in one of its requests, the fraudulent functionality and the anti-bugging techniques that it incorporates will not be activated.
It's likely that both the anti-debugging techniques and the activation parameters have been used in order to help the malware go unnoticed during the review period of the applications that are published in the Apple store.
Anti-debugging code and Jailbreak detection
It's not common to find malware in applications for iOS devices, however, as we've seen, it's still possible to find it in applications that have been accepted in the App Store. In this case, not even the developers themselves were aware of the malicious activity carried out by the SDK in their application.
This malware is just one more example of what attackers are after today, which is nothing more than financial gain. In recent years, malware developers have sought to maximize the profits obtained from their creations, and we can see this reflected in the evolution of malware.
We've found that one of the most popular threats today is ransomware, due to the potential benefit for the attacker if the victim needs to recover their data.
In the case of iOS, due to the restrictions of the operating system and the review of applications to be published in the App Store, the development and distribution of malware becomes really complicated.
However, as we've seen, there are new formulas that allow for the development and distribution of malware on iOS. In this case, an advertising SDK that injects code into certain functions of the iOS API to intercept requests made by the application.
Furthermore, malicious functionality remains hidden until the control server provides it with parameters to activate it. This allows this suspicious behavior to remain undetected while the application is under review.
Fortunately, banks don't include advertising in their applications, however, they do include SDKs or frameworks that facilitate the work of developers, which is something that could pose a risk if they were trojanized as is the case with this SDK.