Angedockt und abgeschürft : LibMiner: Containerbasierte Kryptowährungs-Malware missbraucht ungeschützte Redis-Server

Von Tejas Girme, Pune (IN/MH)

Anfang 2020 hat eine Qualys-Analyse Docker-Instanzen gefunden, die eine als „LibMiner“ bezeichnete Malware ausführen, die in der Lage ist, Cryptominer zu installieren und auszuführen. Auffällig ist dabei die einzigartige verwendete Technik für die Bewegung quer durch Container und Linux-Systeme, auf denen ungeschützte Redis-Server ausgeführt werden. Die Malware hat die Fähigkeit, sich vor ihrem Shutdown zu schützen, sodass es unmöglich ist, die Kontrolle über sie zu erlangen.

Abbildung 1 zeigt den vollständigen Ausführungsablauf von LibMiner. Die verschiedenen Komponenten der Malware werden dazu auf öffentlich zugänglichen Servern gehostet – zu ihren Bestandteilen gehören Bash-Shell- (SH) und Python-Skripte (PY) sowie ausführbare Linux-Dateien im „Executable and Linking Format“ (ELF) und eine Konfigurationsdatei.

Der Angriff funktioniert in zwei Stufen: In der ersten Stufe wird LibMiner über das Bash-Shell-Skript „lib_tmp“ installiert, das dann die nächste Stufe initiiert und die Kryptomining-Komponente startet, die Monero-Kryptowährung berechnet. LibMiner startet zudem verschiedene andere Komponenten (u. a. lib_config_t, sider_t, lib_rook_t).

Obwohl der anfängliche Infektionsmechanismus unbekannt ist, wurden einige Container identifiziert, die einen Einstiegspunkt für ein Bash-Shell-Skript besitzen. Dieser Docker-Abschnitt (Entrypoint-Section) dient als initialer Ausgangspunkt für Container während der Laufzeit. Über das gefundene Skript wird ein Cronjob eingerichtet, der in einem bestimmten Zeitintervall bestimmte Kommandos ausführt: So werden Inhalte der Host-Datei (/etc/hosts) zurückgesetzt, um den Zugriff auf den Server des Angreifers zu gewährleisten.

Infektionsablauf

Außerdem nutzt das Skript Drittprogramme wie cURL oder wget, um die „lib_tmp“-Datei vom Server des Angreifers herunterzuladen. Diese Datei prüft das Vorhandensein von Sicherheitswerkzeugen wie Tencents Cloud Aegis und Alibabas Server Guard, beendet diese Prozesse und entfernt die zugehörigen Dateien. Dann aktualisiert sie die Nameserver auf Googles Public DNS, beendet die Prozesse, die mit ihr selbst verbunden sind, und lädt die neueste „lib“-Binärdatei vom Server des Angreifers herunter. Dabei handelt es sich um die eigentliche LibMiner-Malware, die mit einem vier Zeichen langen, zufälligen Namen im Verzeichnis /var/lib gespeichert wird.

LibMiner ist eine ELF-Malware-Komponente, die den UPX-Packer nutzt. Die Routinen in der Binärdatei werden in einer Endlosschleife ausgeführt und holen mehrere Dateien vom Server des Angreifers ab (vgl. Abb. 1). Die Nicht-ELF-Komponenten enthalten dabei einen (schwach) verschlüsselten Inhalt, dessen Klartextform durch Anwendung einer Caesar-Chiffre (Verschiebung von Buchstaben) und anschließender Base64-Dekodierung verfügbar wird.

LibMiner-Komponenten

lib_rook_t oder lib_kill_t bezeichnen das Aufräummodul für LibMiner: Die Ausführung des Schädlings wird durch Abrufen, Dekodieren und Ausführen eines dieser Bash-Shell-Skripte eingeleitet – sie sind dafür verantwortlich, alle früheren Spuren der Ausführung der Malware zu bereinigen:

• Ermitteln der Prozessnamen und Beenden der mit dem Miner verbundenen Prozesse
• Abbruch der Netzwerkverbindungen für eine vordefinierte Liste von IP-Adressen und Ports

Die Boot_Monitor()-Routine im LibMiner lädt die Komponente lib_boot_t herunter. Ihre dekodierten Daten sind ein Shell-Skript, das dafür verantwortlich ist, eine aktuelle Kopie der LibMiner-Datei herunterzuladen, sie unter einem zufälligen Namen im /tmp-Ordner zu speichern und dann auszuführen. Die Down_Miner()-Routine im LibMiner lädt die beiden Komponenten lib_config_t und glib herunter – die eigentliche Payload in Form des XMRIG Miners und seiner Konfigurationsdatei. glib ist die XMRIG-Binärdatei, die verwendet wird, um die Monero-Kryptowährung auf dem infizierten System „abzubauen“. Die dekodierten Daten der lib_config_t Komponente enthalten die MiningPool-Domäne und Wallet-Adresse dafür.

Ausbreitung durch Redis

Die Redis()-Routine im LibMiner downloaded die Komponente sider_t. Bei deren dekodierten Daten handelt es sich um ein Python-Skript, das dafür verantwortlich ist, ungeschützte Redis-Container zu finden und mit LibMiner zu infizieren. Das Skript verwendet ifconfig, um die IP-Adresse des aktuellen Containers zu erhalten und bereitet eine Ziel-IP-Liste vor, in der die letzten beiden IP-Abschnitte von 0 bis 255 iteriert werden. Für jede dieser IP-Adressen wird versucht, einen Remote-Zugriff auf Port 6379 aufzubauen – dem Standardport von Redis-Servern, einer Open-Source-in-Memory-Datenbank.

Nach einem erfolgreichen Verbindungsaufbau führt die Komponente Code aus, der den Inhalt eines Bash-Shell-Skripts als Wert eines key-value-Eintrags in Redis speichert. Die Redis-API speichert diesen Inhalt im „dbfilename-Root“ unter dem Pfad /var/spool/cron – auf ähnliche Weise werden zwei weitere Dateien als /var/spool/crontabs/root und /etc/cron.d/root erzeugt.

Bemerkenswert ist, dass die Inhalte, die über Redis an den genannten Dateipfaden abgelegt werden, die gleichen sind, welche die Analyse für diese Docker-Bedrohung ursprünglich veranlasst hatten. Auf diese Weise beabsichtigt LibMiner also offenbar, sich lateral zu verbreiten und Kryptowährung abzubauen, um maximalen Gewinn zu erzielen. Allerdings scheiterte im Qualys-Labor die intendierte Ausführung dieser Cron-Inhalte auf Remote-Systemen aufgrund zusätzlicher Bytes, welche die Redis-Datenbank mit abgelegt hatte.

Ausweichmanöver

Die ChangeName() und ChangePid() Routinen in „lib“ sind für die Tarnung des Kryptominers verantwortlich (Evasive Execution) – LibMiner verwendet also keine spezielle Komponente, um seine Ausführung zu verschleiern. ChangePid spaltet einen neuen Child-Process ab, beendet den Parent-Process und setzt die Ausführung mit einer neuen PID fort. Der abgezweigte Prozess wird dabei unter einem neuen Namen ausgeführt, der zufällig aus einer vordefinierten Liste von Dateipfaden ausgewählt wird, die entweder auf Whitelists stehen oder tatsächliche Anwendungen darstellen.

Diese Umgehungstechniken werden von einigen wenigen Anti-Analyse-Techniken begleitet, die im Zusammenspiel die manuelle Identifizierung und Beendigung von LibMiner erschweren – unter anderem die folgenden:

• Setzen des „immutable“ Dateiattributs, um Änderungen oder Umbenennen von Dateien zu verhindern
• sehr geringer Timeout für die Root-Konsole
• auf der Konsole eingegebene Befehle sind nicht sichtbar

Fazit

Die Analyse lässt vermuten, dass die hier beobachteten Malwareautoren bislang keine großartigen Erfahrungen mit Containern besitzen und gerade im Begriff sind, ihre Schadsoftware neu „aufzumunitionieren“ und zu „containerisieren“ – hier zeigt sich eine neue Stoßrichtung.

Kryptominer zu verbreiten, bleibt vermutlich noch lange eine bevorzugte Einnahmequelle für Angreifer. Manche legen ihren Fokus offenbar nun auf falsch konfigurierte und ungeschützte Dockercontainer und installieren dort Miner, um ein Maximum an Gewinn zu erzielen. Es ist zu erwarten, dass solche Angriffe künftig in größerem Umfang erfolgen.

Erkennung und Behebung

Die folgenden Maßnahmen können gegen LibMiner und ähnliche Container-Angriffe helfen:

• Aktualisieren Sie redis-Serverpakete – und natürlich auch andere Systeme – auf die neueste Version, sobald Schwachstellen für die installierte Version bekannt werden (etwa via „Common Vulnerabilities and Exposures“ – CVE – auf https://cve.mitre.org).
• Verwenden Sie RedisDB im geschützten Modus – setzen Sie „Protected-Modus ja“, um den Zugriff vom Internet aus einzuschränken und aktivieren Sie die RedisServer-Authentifizierung.
• Vermeiden Sie die Verwendung von DockerBefehlen mit Root-Privilegien.
• Prüfen Sie, ob bei Ihnen eingesetzte Sicherheitssysteme (IDS/IPS, AV, SIEM etc.) in der Lage sind, entsprechende Malware oder deren Aktivitäten zu erkennen oder hierfür gegebenenfalls gesondert konfiguriert werden müssen.
• Verwenden Sie generell aktuelle Pakete und Anwendungen auf Ihren Hosts – regelmäßige Betriebssystem- und Anwendungs-Updates sollten planmäßig und möglichst flächendeckend erfolgen.

Tejas Girme ist Senior Malware Researcher bei Qualys.