Cyberbedrohungen
Missbrauch nativer Linux-Tools in Angriffen
Wir führen vor, wie native Linux-Tools in Angriffen missbraucht wurden. Auch zeigen wir, wie sich die Auswirkungen dieser Attacken durch die Verwendung von Distroless-Images in Containern und präventiver Kontrollen mindern lassen.
Save to Folio
Mit Hilfe unseres Netzwerks von Honeypots und ausführlicher Telemetrie konnten wir einige interessante Merkmale für die meisten erfolgreichen Exploit-Versuche beobachten, insbesondere die Art und Weise, wie Angreifer native Linux-Tools in ihren Routinen verwenden.
Missbrauch nativer Linux-Tools in Angriffen
Die Nutzung von Containern hat sich durchgesetzt und steigt weltweit. In einer Umfrage der CNCF gaben 93 % der Befragten an, derzeit Container in ihrer Produktion zu verwenden oder deren Einsatz zu planen. Container-Orchestrierungsprojekte wie Kubernetes und andere in der Cloud und im Internet verfügbare Tools haben zu einer Veränderung in der Arbeitsweise von Unternehmen geführt, von monolithischen Architekturen hin zur Schaffung verteilter Systeme, die aus Microservices bestehen.
Doch damit geht auch eine Ausweitung der Angriffsfläche einher, insbesondere infolge von Fehlkonfigurationen oder Schwachstellen, die bei der Bereitstellung entstanden sind. Die Gewährleistung von Sicherheit in der Cloud wird zusätzlich dadurch erschwert, dass die Patch-Verwaltung für Unternehmen oft einen enormen Aufwand bedeutet, was dazu führt, dass Updates nicht immer rechtzeitig implementiert werden.
Bei öffentlich zugänglichen Webanwendungen entdeckten wir kritische Schwachstellen aus einer Vielzahl von Quellen, von anfälligen Open-Source-Bibliotheken (Log4Shell und Spring4Shell) über Frameworks (Apache Struts und Drupal) bis hin zu Anwendungen wie Atlassian Confluence, Oracle WebLogic Server und Apache HTTP Server. Sobald Proof-of-Concepts (POCs) für Schwachstellen öffentlich werden, können Angreifer diese ausnutzen, um bösartige Aufgaben auszuführen, vom Mining von Kryptowährungen bis hin zum Einsatz von Ransomware.
Aus der Sicht eines Verteidigers wäre es ideal, den Angreifer daran zu hindern, auch nur ansatzweise Fuß zu fassen. Gelingt es einem Angreifer dennoch, in das System einzudringen, so muss den Angreifern die erfolgreiche Durchführung ihrer Routinen zu erschwert werden. Dies kann mithilfe von Strategien für die Defense-in-Depth geschehen.
Mit Hilfe unseres Netzwerks von Honeypots und ausführlicher Telemetrie konnten wir einige interessante Merkmale für die meisten erfolgreichen Exploit-Versuche beobachten, insbesondere die Art und Weise, wie Angreifer native Linux-Tools in ihren Routinen verwenden.
Untersuchung von Angriffen
Ein Angriff auf ein Linux-basiertes System folgt in der Regel einer Standard-Infektionskette. Erst nutzt ein Angreifer eine Schwachstelle (oder eine Kette von Schwachstellen) aus, um sich zunächst Zugang zu der Umgebung zu verschaffen (die wir nun als kompromittiert betrachten können). Von dort aus kann er verschiedene Wege einschlagen, um weiter in die kompromittierte Umgebung vorzudringen:
- Erkundung des Kontexts der aktuellen Umgebung (Discovery)
- Exfiltrierung sensibler Daten aus der Umgebung (Exfiltration, Auswirkungen)
- Durchführen eines Denial-of-Service-Angriffs durch Entfernen der Anwendung (Auswirkung)
- Mining von Kryptowährungen durch Herunterladen von Minern (Impact)
- Der Versuch anderer Techniken (Privilege Escalation, Lateral Movement, Persistence oder Credential Access)
Die realen Angriffen und unseren Honeypots zeigten, dass böswillige Akteure eine Vielzahl von aktivierten Tools verwenden, die mit Linux-Distributionen gebündelt werden, wie z. B. curl, wget, chmod, chattr, ssh, base64, chroot, crontab, ps und pkill. Daher sollten Sicherheitsteams gut überlegen, welche dieser Hilfsprogramme, insbesondere in Container-Umgebungen, vorhanden sein sollten/müssen, da sie zusätzliche Möglichkeiten für Angreifer bieten.
Wir haben einige reale Angriffe und Exploits untersucht, die wir über Trend Micro Cloud One™ und Vision One beobachteten. Das base64-Tool ist eine Linux-Utility, die im base64-Format codierte Zeichenketten dekodiert. Angreifer verschleiern ihre Payloads und Befehle häufig mit base64-Codierung, um der Erkennung zu entgehen (T1027). Eine ausführliche Beschreibung liefert der Artikel Die Entwicklung bösartiger Shell-Skripte.
Die .bash-History-Datei, die im Home-Verzeichnis des Benutzers gespeichert wird, protokolliert die Befehle, die von den Benutzern in ihrer Bash-Shell ausgeführt werden. Angreifer sind dafür bekannt, Informationen aus diesen Dateien zu extrahieren, um den Kontext der aktuellen Umgebung zu verstehen. (siehe auch Falsch konfigurierte Docker-Daemon-API-Ports werden für die Kinsing-Malware-Kampagne angegriffen).
Als Teil der Erkundung greift der Angreifer auf die Datei /etc/passwd zu, die eine Liste der registrierten Benutzer innerhalb der Umgebung enthält und anzeigt, ob ein bestimmter Benutzer eine mit seinem Login verbundene Shell hat. Diese Informationen helfen ihm, die Umgebung zu verstehen und wichtige Benutzer ausfindig zu machen. (T1003.008)
Chattr wiederum wird dazu verwendet, um Datei- und Ordnerattribute zu ändern, um plötzliche Vorgänge wie das Löschen und Ändern von Dateien unter Kontrolle zu haben. Zum Beispiel hat TeamTNT die Utility missbraucht, wie in unserem Whitepaper "Tracking the Activities of TeamTNT" beschrieben.
Ein Cron-Job wird für die Planung von Aufgaben (oder Jobs) eingesetzt. Angreifer missbrauchen Cron-Jobs und modifizieren „crontab“, um Ausführungs-, Persistenz- und manchmal auch Techniken zur Erweiterung von Privilegien durchzuführen (T1053.003). Das Beispiel in Bild 2 zeigt die Entfernung von bestehenden Cron-Jobs. Dies kommt häufig vor, wenn Kryptowährungs Miner-miteinander konkurrieren. Unser Blogeintrag „Kampf der Linux-Kryptowährungs-Miner um Ressourcen“War of Linux Cryptocurrency Miners: A Battle for Resources (Kampf um Ressourcen) geht ausführlich auf diese Aktivitäten ein.
Curl oder cURL wird zur Übertragung von Daten über verschiedene Protokolle wie HTTP, HTTPS und File Transfer Protocol (FTP) verwendet. Darüber können etwa Systeminformationen wie die Betriebssystemversion und die Release-Version als POST-Anfrage an die Infrastruktur des Angreifers gesendet werden.
Im Bild ist beachten, dass chroot verwendet wird, um das Root-Verzeichnis in das angegebene Verzeichnis (in diesem Fall /host) zu ändern, in dem das Dateisystem des zugrunde liegenden Hosts innerhalb des Containers eingehängt ist. Die Schwachstelle, die diese Funktion darstellt, haben wir ausführlich dargestellt: Warum ein privilegierter Container in Docker eine schlechte Idee ist.
Viele weitere Utilities und deren Nutzung bietet der Originalbeitrag.
Best Practices zum Schutz von Linux-Systemen
Verwendung von Distroless Images
Damit die erörterten Techniken mit Tools, die mit einem vollständigen Betriebssystem gebündelt werden, unterbunden werden, ist es sicherer, Container-Images einzusetzen, die nur die Tools enthalten, die benötigt werden. Dieser Sicherheitsansatz kann dazu beitragen, das Risiko in hohem Maße zu mindern, selbst bei kritischen Sicherheitslücken wie Log4Shell. Die Verringerung der Anzahl der Tools, die für die Ausführung von Anwendungen erforderlich sind, verringert auch die Angriffsfläche, die durch die Abhängigkeitsschwachstellen in Open-Source-Bibliotheken und -Tools entsteht. Hier kommt das Konzept der „Distroless Images“ ins Spiel. Sie enthalten nur die Anwendung und ihre Laufzeitabhängigkeiten und verzichten auf die Programme, die man in einer typischen Linux-Distribution erwarten würde, wie Paketmanager und Shells.
Cloud One Workload Security - Anwendungskontrolle
Aus der Sicht der Verteidiger sollte der Schwerpunkt darauf liegen, Angreifer mit Hilfe von Strategien der Defense-in-Depth auszuschalten. Während Änderungen am System zur Minimierung oder sogar Verhinderung von Missbrauch hilfreich sind, würde ein mehrschichtiger Ansatz, der mehrere Sicherheitsmaßnahmen umfasst, das höchste Maß an Sicherheit bieten, idealerweise durch die Kombination von Best Practices mit wirksamen Verteidigungstechnologien.
Für nicht Container-basierte Umgebungen bietet Cloud One Workload Security das Modul Application Control, das Softwareänderungen überwacht und sie auf der Grundlage der festgelegten Konfiguration zulässt oder blockiert. Es erstellt eine Baseline der vorhandenen Anwendungen und wendet die Regeln auf neue Anwendungen an, die heruntergeladen und installiert werden. Es arbeitet auf der Grundlage des SHA256-Hashes für eine Binärdatei.
Das Modul bietet Anwendern folgende Möglichkeiten:
- Nicht erkannte Software blockieren, bis sie ausdrücklich zugelassen wird
- Nicht erkannte Software zulassen, bis sie explizit blockiert wird
Fazit
Da Angreifer legitime Tools und Dienstprogramme nutzen, die in das Betriebssystem integriert sind, müssen Verteidiger Prioritäten setzen, wie sie in den verschiedenen Phasen eines Angriffs Kontrollen einrichten können. Die Minimierung der Angriffsfläche durch die Verwendung von Distroless-Images in Containern und die Anwendung präventiver Kontrollen wie die Application Control von Cloud One Workload Security tragen wesentlich dazu bei, Angreifer, die auf Cloud-Umgebungen abzielen, zu bremsen. In Fällen, in denen Unternehmen keine Distroless-Implementierung verwenden können, lassen sich auch „abgespeckte“ Versionen derselben Images einsetzen, um die Angriffsfläche zu verringern und die Sicherheit von Cloud-Implementierungen zu erhöhen.