Baden-Baden, 22. Januar 2020

Ende letzten Jahres haben einige unserer Benutzer eine Änderung in der Systemdatei /system/lib/libc.so mithilfe der Änderungserkennungsfunktion im Systembereich bemerkt. Hierbei handelt es sich um eine der Hauptbibliotheken von Linux-basierten Betriebssystemen, die für Systemaufrufe und Grundfunktionen verantwortlich ist. Eine detaillierte Untersuchung ermöglichte es, neue Muster der Trojaner-Familie Android.Xiny zu erkennen, die uns seit 2015 bekannt ist. Die Vertreter der Familie waren die ersten, die das Attribut „nicht änderbar“ hatten, welches das Entfernen dieser Trojaner von Geräten erheblich erschwerte. Dies sah komisch aus. Das genannte Attribut wurde für die apk-Datei der installierten Anwendung gesetzt. Der Versuch, diese Anwendung zu löschen, schien zunächst erfolgreich: Die Daten wurden gelöscht, die apk-Datei selbst blieb jedoch erhalten. Nach dem Neustart des Geräts tauchte die Anwendung erneut auf. Von einem solcher Trojaner haben wir 2016 berichtet. Um derartige Bedrohungen neutralisieren zu können, haben wir unseren Antivirus mit einer Reset-Funktion für Dateiattribute ausgestattet. Um die Funktion zu aktivieren, sollte der Benutzer dem Antivirus Root-Berechtigungen erteilen.

Betrachten wir eine interessante Selbstschutzmethode, die in den neuen Versionen von Android.Xiny verwendet wird, genauer.

Android 5.1 in 2019?

Der hier betrachtete Trojaner wird auf Android-Geräten bis einschließlich Version 5.1 ausgeführt. Es mag einem seltsam vorkommen, dass die Malware, die für so „alte“ Android-Versionen entwickelt wurde, immer noch aktiv ist (Version 5.1 wurde 2015 veröffentlicht). Alte Versionen werden jedoch immer noch verwendet. Nach Angaben von Google laufen 25,2 % der Geräte mit Android 5.1 oder niedriger (Stand: 7. Mai 2019). Betrachten wir nur unsere Nutzer, so sind es sogar rund 26 %. Dies bedeutet, dass etwa ein Viertel aller Android-Geräte zum Angriffsziel von Cyber-Kriminellen werden können. Und das ist bei weitem nicht wenig. Diese Geräte werden immer Sicherheitslücken aufweisen. Kein Wunder, dass die alten Versionen des Android-Betriebssystems für Virenschreiber immer noch von Interesse sind. Die Root-Rechte, auf die sie sich durch Ausnutzen der genannten Sicherheitslücken Zugriff verschaffen können, lassen den Virenschreibern nämlich freie Hand. Damit kann man alles auf dem Gerät tun, was man will. In den meisten Fällen geht es jedoch um die einfache Installation von Apps.

Hauptfunktionen des Trojaners

Ab den frühesten Versionen ist die Hauptfunktion des Trojaners Android.Xiny, beliebige Anwendungen ohne Genehmigung des Nutzers auf dem Gerät installieren zu können. So können Cyber-Kriminelle von der Teilnahme an Partnerprogrammen profitieren, indem sie Geld für die Installation von Anwendungen bekommen. Dies ist wohl eine der Haupteinnahmequellen für die Entwickler dieser Virenfamilie. Einige Vertreter der Familie können nach ihrem Start das Gerät in wenigen Minuten funktionsunfähig machen. Auf dem Gerät wird ein Haufen harmloser, aber unnötiger Benutzeranwendungen installiert und gestartet. Darüber hinaus können diese Trojaner auch andere Malware installieren – alles hängt von dem Befehl ab, den der Verwaltungsserver sendet.

Die neuen Versionen des Trojaners Android.Xiny zeichnen sich dadurch aus, dass sie über einen Schutzmechanismus gegen ihr Entfernen verfügen. Dafür sind zwei Komponenten verantwortlich. Betrachten wir sie genauer.

Installationsprogramm

• sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
• detect: Android.Xiny.5261

Diese Komponente wird aktiv, sobald sie Root-Rechte erhält. Sie ersetzt die Systemdateien /system/bin/debuggerd und /system/bin/ddexe und speichert sie unter den Namen mit dem Suffix _server. Dabei agiert sie als ein klassischer Companion-Virus. Dadurch wird der automatische Start der Komponente gewährleistet. Darüber hinaus werden weitere ausführbare Dateien aus dem in den Befehlszeilenparametern angegebenen Ordner in die Systempartition kopiert. Außerdem kann der Trojaner die in der Systempartition installierten Komponenten aktualisieren, wenn man ihn mit den entsprechenden Parametern startet und den Ordner angibt, in dem sich die neuen Versionen befinden.

Android.Xiny.5261 enthält eine beeindruckende Liste der zu löschenden Dateien. In der Liste sind unter anderem Pfade angegeben, die in älteren Vertretern der Familie sowie in anderen Trojaner-Familien, die in der Systempartition installiert werden, verwendet werden, wie zum Beispiel Triada.

Außerdem löscht Android.Xiny.5261 einige vorinstallierte Anwendungen wahrscheinlich mit dem Ziel, Speicherplatz zu bereinigen. Schließlich werden die bekannten Anwendungen zur Steuerung der Root-Rechte wie SuperSU, KingRoot usw. gelöscht. Dadurch werden dem Benutzer die Root-Rechte und folglich die Möglichkeit genommen, die in der Systempartition installierten Trojaner-Komponenten zu löschen.

Geänderte Systembibliothek libc.so

• sha1: 171dba383d562bec235156f101879223bf7b32c7
• detect: Android.Xiny.5260

Diese Datei erschien uns besonders interessant, deshalb haben wir unsere Recherche damit begonnen. Bei einem kurzen Blick darauf in Hiew kann man einen ausführbaren Code am Ende des .data-Abschnitts erkennen, was sehr verdächtig ist.

Beim Öffnen der Datei in IDA können wir sehen,

dass die folgenden Funktionen in dieser Bibliothek geändert wurden: mount, execve, execv, execvp, execle, execl, execlp.

Der Code der geänderten mount-Funktion lautet:

int __fastcall mount(const char *source, const char *target, const char *filesystemtype, unsigned int mountflags, const void *data)
{
  unsigned __int8 systemPath[19]; // [sp+18h] [bp-1Ch]
  bool receivedMagicFlags; // [sp+2Bh] [bp-9h]
  int v13; // [sp+2Ch] [bp-8h]
  v13 = MAGIC_MOUNTFLAGS; // 0x7A3DC594
  receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS;
  if ( mountflags == MAGIC_MOUNTFLAGS )
    mountflags = 0x20;                          // MS_REMOUNT
  if ( receivedMagicFlags )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( mountflags & 1 )                         // MS_RDONLY
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( getuid_() )                              // not root
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  memCopy(systemPath, (unsigned __int8 *)off_73210 + 471424, 8);// /system
  decrypt(systemPath, 8);
  if ( memCompare((unsigned __int8 *)target, systemPath, 8) || !isBootCompete() )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  *(_DWORD *)errno_() = 13;
  return -1;
}

Hier wird der Parameter mountflags zunächst auf das Vorhandensein des „magischen“ Werts 0x7A3DC594 geprüft. Hat die Funktion diesen Wert, erhält die echte mount-Funktion sofort die Steuerung. Weiter wird geprüft, ob es einen Versuch gibt, die Partition /system auf Schreiben umzustellen, und ob der Start des Betriebssystems abgeschlossen ist. Sind diese Bedingungen erfüllt, wird die echte mount-Funktion nicht aufgerufen und ein Fehler wird zurückgegeben. Auf diese Weise hindert die vom Trojaner geänderte mount-Funktion alle daran, die Systempartition auf Schreiben umzustellen. Die Ausnahme ist der Trojaner selbst, der diese Funktion mithilfe des „magischen“ Parameters aufruft.

Der Code der geänderten execve-Funktion lautet (in den anderen exec*-Funktionen sieht alles ähnlich aus):

int __fastcall execve(const char *filename, char *const argv[], char *const envp[])
{
  int v3; // r3
  if ( targetInDataOrSdcard(filename) >= 0 )    // returns -1 if true
  {
    sub_7383C();
    v3 = call_real_execve(filename, argv, envp);
  }
  else
  {
    *(_DWORD *)errno_() = 13;
    v3 = -1;
  }
  return v3;
}

int __fastcall targetInDataOrSdcard(const char *path)
{
  char buf[516]; // [sp+8h] [bp-204h]
  if ( isDataOrSdcard(path) )
    return -1;
  if ( *path == '.' && getcwd_(buf, 0x200u) && isDataOrSdcard(buf) )
    return -1;
  return 0;
}

Hier wird geprüft, ob der Pfad zu der auszuführenden Datei mit „/ data /“ beginnt und ob er „/ sdcard“ enthält. Ist eine der Bedingungen erfüllt, wird der Start gesperrt. Hier möchten wir Sie darauf aufmerksam machen, dass der Pfad /data/data/ zu Verzeichnissen mit Anwendungen führt. Dies blockiert die Ausführung von ausführbaren Dateien aus allen Verzeichnissen, in denen eine normale Anwendung eine Datei erstellen kann.

Die Änderungen an der Systembibliothek libc.so stören den Betrieb der Anwendungen, die für den Erhalt der Root-Rechte verantwortlich sind. Wegen Änderungen an den exec*-Funktionen kann eine solche Anwendung keine Exploits starten, um die Berechtigungsstufe im System zu erhöhen, weil Exploits normalerweise ausführbare Dateien sind, die aus dem Netzwerk in das Verzeichnis mit der Anwendung heruntergeladen und ausgeführt werden. Ist es Ihnen trotzdem gelungen, die Berechtigungsstufe zu erhöhen, wird die geänderte mount-Funktion Sie daran hindern, die Systempartition auf Schreiben umzustellen und somit jegliche Änderungen daran vorzunehmen.

Der Selbstschutz des Trojaners setzt sich also aus zwei Komponenten zusammen: Sein Installationsprogramm löscht die Anwendungen zur Steuerung der Root-Rechte und die geänderte Systembibliothek libc.so verhindert, dass die gelöschten Anwendungen erneut installiert werden. Darüber hinaus wirkt dieser Schutz auch vor „Konkurrenten“ – anderen Trojanern, die Root-Rechte erhalten und in der Systempartition installiert werden, weil sie nach dem gleichen Prinzip wie „gutartige“ Anwendungen zum Erhalten der Root-Rechte funktionieren.

Wie kann man einen solchen Trojaner neutralisieren?

Um Android.Xiny.5260 loszuwerden, kann man das Gerät flashen lassen – vorausgesetzt, dass es eine öffentlich zugängliche Firmware dafür gibt. Gibt es eine andere Möglichkeit, die Malware zu entfernen? Ja, es gibt einige Möglichkeiten, doch diese sind mit Mühe verbunden. Um Root-Rechte zu erhalten, kann man Exploits in Form von so-Bibliotheken verwenden. Im Unterschied zu ausführbaren Dateien wird der Trojaner das Herunterladen dieser Exploits nicht sperren. Man kann außerdem diejenige Komponente des Trojaners verwenden, die Root-Rechte für seine anderen Teile bereitstellt. Sie empfängt Befehle über den Socket im Pfad /dev/socket/hs_linux_work201908091350 (je nach Version kann der Pfad unterschiedlich sein). Um die mount-Sperre zu umgehen, kann man den „magischen“ Wert des Parameters mountflags verwenden oder den entsprechenden Syscall direkt aufrufen.

Falls Ihr Gerät von einem solchen Trojaner befallen wird, empfehlen wir, die offizielle Firmware zum Flashen zu verwenden. Dabei werden jedoch alle Benutzerdateien und -programme gelöscht. Erstellen Sie daher vorab unbedingt ein Backup.