Ein Fehler wie bei Log4J kann verheerende Spätfolgen haben: Ein Sicherheitsexperte erklärt, wie Angreifer sogar die Lücke schließen und erst später nutzen.
- Lieferketten- oder Supply-Chain-Angriffe wie Log4J zielen darauf ab, ein Software-Element zu manipulieren, das in weitverbreiteter Software zum Einsatz kommt.
- Diese Eingriffe sind sehr schwer zu entdecken und bleiben daher lange unentdeckt. Außerdem wissen viele Unternehmen gar nicht, dass sie betroffen sind.
- Verzeichnisse von Zulieferern und verwendeten Software-Elementen können das Sicherheitsniveau erhöhen, sind jedoch nur in wenigen Unternehmen vorhanden.
Angreifer wählen nicht immer den direkten Weg. Zunehmend greifen sie Unternehmen indirekt über deren Zulieferer an. Kaseya und SolarWinds sind berühmt gewordene Beispiele für diese sogenannten Supply-Chain- oder Lieferketten-Attacken. Mit Log4J liegt ein weiterer Supply-Chain-Angriff vor. Dabei enthielt ein zentrales Element zahlreicher Webserver eine Sicherheitslücke. Sicherheitsexperte Cristian Avram vom Security-Unternehmen Bitdefender hat sich ausgiebig mit dieser Lücke beschäftigt. Im folgenden Interview erläutert er Zusammenhänge und Hintergründe.
Zuvor hatte er im Rahmen eines it-sa insights Vortrags technische Details erläutert. Für registrierte Nutzer ist der Vortrag „Sicherheitslücke Log4Shell – Das Worst-Case-Szenario“ als Mitschnitt verfügbar.
Herr Avram, sie arbeiten als Solution Architect bei Bitdefender.In dieser Funktion entwickeln sie Sicherheitskonzepte für größere Unternehmen. Lieferkettenangriffen sind ein aktuell großes Thema, nicht zuletzt aufgrund Log4Shell. Was kennzeichnet diese Angriffsform aus?
Angriffe auf eine Supply-Chain-Kette sind meistens schwer zu erkennen. Angreifer benutzen dazu Software-Bestandteile oder Bibliotheken, die von Dritten entwickelt wurden und vom Unternehmen in das eigene Produkt integriert werden. Man müsste daher die integrierte Software zusätzlich explizit überprüfen. Das ist schwierig und wird in der Regel nicht gemacht. Überprüfungen beschränken sich meist auf die eigene Software, etwa ob Performance-Probleme oder Abstürze auftreten. Aber was sich in externen Modulen verbirgt, ist nicht leicht zu entdecken. Hinzu kommt, wenn darin ein Problem entdeckt wird, muss man warten, bis es von den Programmierern des Zulieferers gelöst wird, denn man kann es nicht selber lösen. Die Aktualisierung der eigenen Software ist damit abhängig von der Aktualisierung von Subkomponenten.
Was macht Lieferkettenangriffe so gefährlich?
Angriffe sind bei solchen Lücken häufig langfristig möglich, weil es durch die Abhängigkeiten von Dritten länger dauert, ehe jede Software gepatched ist. Das Zeitfenster für Angriffe ist dadurch sehr groß. Ein Beispiel: Jemand entwickelt eine Software, die Log4J benutzt und eine dritte Firma benutzt wiederum diese Software für ihre Lösung und verwendet ihrerseits darin auch die Log4J-Bibliothek. Jetzt wird darin ein Problem entdeckt und ein Update wird verfügbar. Die Firma weiß aber nur, dass ihre Software Log4J verwendet, nicht aber, dass das integrierte Modul ebenfalls Log4J verwendet. Von daher kümmert sich die Firma auch nur um ihre Software, aber die Schwachstelle im Modul bleibt offen, bis der Zulieferer seinerseits irgendwann ein Update liefert.
Wie nutzen Hacker diese spezielle Problematik aus?
Sie stellen sich darauf ein: Weil das Zeitfenster sehr groß ist, kann es sein, dass Angreifer schnell eine Backdoor installieren und anschließend die Sicherheitslücke sogar patchen, um unerkannt zu bleiben. Wenn das Unternehmen seine Software überprüft, wird es denken, es sei sicher, weil die Lücke schon gepatched wurde, die Backdoor dahinter bleibt aber unentdeckt. Wir hatten unlängst einen solchen Fall bei einem unserer Kunden. Es wurde eine Log4J-Aktualisierung gefunden, aber die Admins behaupteten, sie hätten noch kein Update installiert. Bei genauerer Betrachtung fanden wir dann eine Backdoor, sodass die Vermutung nahe liegt, dass die Lücke von Angreifern geschlossen wurde, nachdem sie ihre Backdoor eingerichtet hatten.
Welche verschiedenen Varianten von Supply-Chain-Attacken existieren bisher?
Bei Log4J waren es nicht Angreifer, die die Schwachstelle eingebaut haben, sondern die Entwickler haben diese Lücke in ihrer eigenen Software übersehen. In anderen Fällen haben Angreifer Malware in vom betroffenen Unternehmen zugekauften Komponenten installiert. Bei Log4J steckte keine bösartige Absicht dahinter, das Problem ließ sich aber für Angriffe verwenden. Ein anderer Weg besteht darin, dass Angreifer gezielt nach Zulieferern suchen, deren Komponenten in größere Software-Lösungen integriert werden, um diese zu identifizieren. Der Trick bei Supply-Chain-Angriffen liegt darin, dass diese einmal installierte Malware über den Anbieter der großen Software-Lösung an viele Kunden verteilt wird und Angreifer dadurch viele Opfer finden. Von daher stehen besonders Software-Anbieter im Fokus, die eine weitverbreitete Software entwickeln.
Sie haben sich intensiv mit dem Log4J-Angriff beschäftigt. Welche Besonderheiten konnten Sie dabei feststellen?
Log4J ist eine weitverbreitete Open-Source-Lösung. Open Source hat den Vorteil, dass der Quellcode offen zugänglich ist und viele Programmierer daran mitwirken. Dadurch werden Fehler besser entdeckt. Viele Anwendungen benutzen heute Open-Source-Software. Deshalb wird Log4J auf allen möglichen Plattformen und in verschiedensten Produkten eingesetzt. Sogar Navigationssysteme in Autos, Parkuhren, Router, Webcams verwenden dieses Modul. Es sind Millionen von Anwendungen und wahrscheinlich Hunderte von Millionen von Geräten, die damit versehen sind. Deshalb sind längst noch nicht alle verwundbaren Systeme gefunden. Das Problem bleibt uns sicherlich noch eine Weile erhalten.
Sie berichten im Video-Vortrag vom Muhstik-Botnet, das Log4J-Angriffe ausübt – ist es noch aktiv und weiß man, wer dahinter steckt? Gibt es weitere Gruppen, die diesen Angriff verwenden?
Wer dahinter steckt, weiß man noch nicht, aber wir suchen danach. Muhstik lässt sich gut an der speziellen Payload erkennen und an der Log4J-Ausnutzung. Die Schad-Software lädt weitere Scripte nach, die etwa den infizierten Server in einen Bot eines Botnet verwandelt oder für Crypto-Mining nutzt. Eine weitere Gruppe ist die Konsary-Gruppe.
Zum Videomitschnitt: LOG4SHELL – DAS WORST-CASE-SZENARIO IST EINGETRETEN
Im Video demonstrieren Sie, wie ein Angriff abläuft. Wie aufwendig ist der Aufbau dieser Demo-Umgebung?
Es ist nicht sonderlich aufwendig, wenn man schon ein paar Maschinen zur Verfügung hat, zum Beispiel ein installiertes Kali-Linux und eine Windows-10 Maschine. Bei Github gibt es Container mit präpariertem Log4J-Webserver, darauf gehe ich auch in meinem Action-Beitrag ein. Im Anschluss muss man aber meist nach etwas testen, bis alles passend funktioniert.
Welche Schutzmaßnahmen würden Sie empfehlen, um sich als Unternehmen gegen Lieferkettenangriffen zu wappnen? Welche Sicherheitskomponenten sind dafür wichtig?
Ein Unternehmen sollte wissen, welch Software es einsetzt und auch deren Komponenten kennen. Dazu sind Software-Audits notwendig. Um Software-Bestandteile identifizieren zu können, bieten sich „Bills of Materials“ (BOM) an. Das sind Verzeichnisse, die als Software-Stückliste gesehen werden können. Darin werden verwendete Komponenten festgehalten und auch deren Herkunft. Wenn eine Sicherheitslücke bekannt wird, lässt sich damit sehr leicht prüfen, welche Systeme betroffen sind.
Als Sicherheitsstrategie für Unternehmen ist ein „Defense in Depth“ genannter Ansatz zu empfehlen. „Defense in Depth“ ist eine mehrschichtige Sicherheitsstrategie, die zumindest aus einer Firewall-Lösung, Endpoint-Protection und Netztraffic-Analyse für die Erkennung lateraler Bewegungen besteht. Damit werden Dinge sichtbar, die vielleicht auf den Endpoints nicht aufgefallen sind. Der Kerngedanke besteht darin, wenn eine Vulnerabilität nicht sofort entdeckt wurde, sollte eine Malware spätestens dann entdeckt werden, wenn sie versucht, Schaden anzurichten.
Eine Software wie Bitdefender macht auf jedem System eine Prozessanalyse und entdeckt Anomalien. Dadurch kann ich mir ein Bild vom Ablauf eines Angriffs machen. Dadurch lässt sich erkennen, wo und wann etwa eine Malware heruntergeladen wurde, wo Scripte nachgeladen wurden und welche weiteren Schritte auftreten.
Live-Action am 16. März: LOG4J UND NOPAC-VON EXTERNEM ANGREIFER ZU DOMAIN ADMIN IN 10 MINUTEN
