Log4j-Alarm: das empfehlen IT-Security-Experten 

IT-Security-Experten äußern sich zur log4j-Sicherheitslücke für die das BSI die Warnstufe Rot ausgerufen hat. Experten von Barracuda Networks,  Radar Cyber Security und ForeNova geben eine Einschätzung der Lage.

Jonathan Tanner, Senior Security Researcher bei Barracuda Networks

Jonathan Tanner, Senior Security Researcher bei Barracuda Networks: „Da diese Sicherheitslücke die Ausführung von Remotecode ermöglicht, sind die Risiken ziemlich hoch.“ (Bild: Barracuda Networks).

Wie können Unternehmen diese Schwachstelle in ihrer Technologie erkennen, und welche Risiken drohen, wenn sie nicht behoben wird?

„Zuerst sollten sie prüfen, ob eine Version von log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten. Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools – bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken. So lässt sich feststellen, ob eine verwundbare Version von log4j verwendet wird oder nicht. Auch mit Version 2.15.0 oder höher sollte man sicherstellen, dass die Systemeigenschaft formatMsgNoLookups nicht auf ‚true‘ gesetzt ist.

Denn diese Version ist nur deshalb nicht verwundbar, weil sie den Standardwert von true auf false gesetzt hat. In einigen Versionen von log4j lässt sich diese Eigenschaft einfach manuell auf “false” setzen, um die Sicherheitslücke zu entschärfen. Wenn die Anwendung LDAP nicht als Teil ihrer legitimen Nutzung benötigt wird, ist es auch möglich, den gesamten LDAP-Verkehr mit einer Firewall oder einem Web Application Filter zu blockieren, um zu verhindern, dass Remote-Code erreicht wird, falls die Schwachstelle ausgenutzt wird.

Diese prüfen jedoch nur, ob log4j in der Lage ist, diese RCE-Schwachstelle auszunutzen oder nicht. Ob ein System wirklich anfällig für einen Angriff ist oder nicht, ist eine viel kompliziertere Angelegenheit ohne einen einzigen Test, wie ihn Schwachstellen wie HeartBleed hatten. Um diese Schwachstelle auszunutzen, müsste ein Angreifer einen Log-Injection-Angriff durchführen. Diese zu finden ist ein sehr viel komplexerer Prozess, aber im Grunde genommen kann jeder Ort, an dem Eingaben eines Benutzers (oder eines potenziellen Angreifers) protokolliert werden, für diesen Angriff anfällig sein.

Um einen tatsächlichen RCE zu testen, müsste man also versuchen, einen Weg zu finden, eine JNDI-LDAP-Anfrage innerhalb der Protokolle aus dem Benutzerkontext selbst zu stellen (z. B. über die Website oder die API, wenn die potenziell betroffene Anwendung eine Webanwendung ist). Da diese Sicherheitslücke die Ausführung von Remotecode ermöglicht, sind die Risiken ziemlich hoch. Ein Angreifer könnte möglicherweise in das Netzwerk eindringen und von dort aus versuchen, auf wichtige Ressourcen und Daten zuzugreifen.“

Welche Rolle spielte Open Source bei dieser Sicherheitslücke, und was sind die wichtigsten Sicherheitsüberlegungen für Unternehmen, die Tools wie log4j verwenden?

„Da es sich bei log4j um eine sehr beliebte Open-Source-Bibliothek handelt, war die Zahl der verwundbaren Anwendungen sicherlich höher. Generell kann jede Software anfällig für Angriffe sein, und bei populärer Open-Source-Software gibt es oft ein großes Ökosystem, das nach Sicherheitsbedrohungen sucht und diese behebt. Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist (und in der Tat ist sie wahrscheinlich viel sicherer als proprietärer Code oder weniger populäre Bibliotheken). Die weite Verbreitung erhöht lediglich die Wahrscheinlichkeit, dass Schwachstellen gefunden werden, nicht unbedingt die Wahrscheinlichkeit, dass sie existieren.

Bei der Suche nach Open-Source-Bibliotheken sollten Unternehmen aus den oben genannten Gründen große, seriöse und gut gewartete Projekte wie log4j wählen. Natürlich kann es immer noch Schwachstellen geben, aber es ist wahrscheinlicher, dass die Community diese Schwachstellen findet und ausbessert und auch überprüft, dass der Code frei von Fehlern ist, die überhaupt erst Schwachstellen verursachen könnten, als bei kleineren Projekten.

Selbst für diejenigen, deren Anwendungen nicht für CVE-2021-44228 anfällig sind oder die log4j gar nicht für die Protokollierung verwenden, ist diese Schwachstelle definitiv ein Weckruf, dahingehend, dass Log-Injection eine potenzielle Methode ist, die Angreifer nutzen könnten. Es lohnt sich, zu überprüfen, ob alle Benutzereingaben, die protokolliert werden, in jeder Anwendung ordnungsgemäß bereinigt werden, unabhängig davon, welches Protokollierungssystem oder sogar welche Programmiersprache verwendet wird. Auch wenn andere Formen der Injektion weitaus verbreiteter sind und im Mittelpunkt des Interesses stehen, handelt es sich bei der Log-Injection immer noch um eine Form des Injektionsangriffs und fällt daher unter die OWASP Top 10 Schwachstellen.“

Wie können Unternehmen diese Schwachstelle in ihrer Technologie erkennen, und welche Risiken drohen, wenn sie nicht behoben wird?

„Zuerst müssen sie prüfen, ob eine Version von log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten. Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools – bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken. So lässt sich feststellen, ob eine verwundbare Version von log4j verwendet wird oder nicht. Auch mit Version 2.15.0 oder höher sollte man sicherstellen, dass die Systemeigenschaft formatMsgNoLookups nicht auf ‚true‘ gesetzt ist. Denn diese Version ist nur deshalb nicht verwundbar, weil sie den Standardwert von true auf false gesetzt hat.

In einigen Versionen von log4j lässt sich diese Eigenschaft einfach manuell auf “false” setzen, um die Sicherheitslücke zu entschärfen. Wenn die Anwendung LDAP nicht als Teil ihrer legitimen Nutzung benötigt wird, ist es auch möglich, den gesamten LDAP-Verkehr mit einer Firewall oder einem Web Application Filter zu blockieren, um zu verhindern, dass Remote-Code erreicht wird, falls die Schwachstelle ausgenutzt wird. Diese prüfen jedoch nur, ob log4j in der Lage ist, diese RCE-Schwachstelle auszunutzen oder nicht. Ob ein System wirklich anfällig für einen Angriff ist oder nicht, ist eine viel kompliziertere Angelegenheit ohne einen einzigen Test, wie ihn Schwachstellen wie HeartBleed hatten.

Um diese Schwachstelle auszunutzen, müsste ein Angreifer einen Log-Injection-Angriff durchführen. Diese zu finden ist ein sehr viel komplexerer Prozess, aber im Grunde genommen kann jeder Ort, an dem Eingaben eines Benutzers (oder eines potenziellen Angreifers) protokolliert werden, für diesen Angriff anfällig sein. Um einen tatsächlichen RCE zu testen, müsste man also versuchen, einen Weg zu finden, eine JNDI-LDAP-Anfrage innerhalb der Protokolle aus dem Benutzerkontext selbst zu stellen (z. B. über die Website oder die API, wenn die potenziell betroffene Anwendung eine Webanwendung ist).

Da diese Sicherheitslücke die Ausführung von Remotecode ermöglicht, sind die Risiken im Falle einer Sicherheitslücke ziemlich hoch. Ein Angreifer könnte möglicherweise in das Netzwerk eindringen und von dort aus versuchen, auf wichtige Ressourcen und Daten zuzugreifen.“

Lothar Hänsler, COO bei Radar Cyber Security

Lothar Hänsler, COO bei Radar Cyber Security: „Die Schwachstelle lässt sich verhältnismäßig einfach auszunutzen, Angriffe können leicht verschleiert werden.“ (Bild: Radar Cyber Security).

Was ist überhaupt passiert?

„Vergangenes Wochenende wurde eine Schwachstelle im log4j2-Modul von Apache.org erkannt und diese sehr schnell mit einem CVSS Score von 10, der höchsten Kritikalitätsstufe, versehen. Auch Behörden, wie das Bundesamt für Sicherheit in der Informationstechnik (BSI) haben ihre Risikoeinschätzung, die anfangs noch auf Orange stand, zügig auf Rot angehoben.“

Was macht diese Schwachstelle so besonders?

„Die Schwachställe lässt sich verhältnismäßig einfach auszunutzen, Angriffe können leicht verschleiert werden (Obfuscation). Zudem sind Verteidigungsmaßnahmen nicht einfach umzusetzen. Dies liegt unter anderem daran, dass alle Mitigationsstrategien Risiken und Nebenwirkungen auf die Applikationen haben können, die von der Schwachstelle betroffen sind. Die Einschätzungen in den Expertenkreisen stellen sich allerdings sehr dynamisch dar. Dadurch liegen auch unterschiedliche Sichtweisen zu den Mitigationsstrategien vor.“

Was hat Radar Cyber Security konkret unternommen?

„Wir haben am Wochenende zunächst die Datenlage mit einem Incident Response analysiert, den Impact abgeschätzt, diverse Informationsquellen von internationalen Plattformen, wie Computer Emergency Response Teams (CERTs), herangezogen und eine Strategie für den Umgang mit dieser Bedrohung entworfen. Montagfrüh haben wir schließlich ein Security Advisory an all unsere Kunden verschickt. Unser Cyber Defense Center (CDC) wurde auf den High-AlertModus gesetzt.

Es richtet nun ein besonderes Augenmerk auf das Auftreten der Schwachstelle im log4j2-Modul, ohne dabei die Gesamtsicherheitslage zu vernachlässigen. Dafür haben wir die Erkennungsmodule aktualisiert, um die Ausnutzung dieser Schwachstelle verifizieren und an unsere Kunden melden zu können. Dies reicht vom Schwachstellenmanagement über klassische SIEM-Dienste bis zu den einzelnen Netzwerkanalyse-Tools. Parallel dazu haben wir eine Analyse unserer eigenen Systeme gestartet. Nach dem ersten Scan bei einem ersten Kunden, wurden innerhalb kürzester Zeit zwei kritische Vorkommnisse erkannt. Weitere Sonderservices analysieren, ob Kunden konkret von dieser Schwachstelle betroffen sind. In Extremfällen kann ein Abschalten von Systemen erforderlich sein.“

Paul Smit, Director Professional Services bei ForeNova

Paul Smit, Director Professional Services bei ForeNova: „Die Zero-Day-Lücke in log4j ist hochgefährlich, da sie ohne explizites Nachladen von Schadcode direkt ausnutzbar ist.“ (Bild: ForeNova).

„Die Zero-Day-Lücke in der weit verbreiteten Java-Bibliothek log4j ist hochgefährlich, weil die Schwachstelle auch ohne explizites Nachladen von Schadcode direkt ausnutzbar ist. Ob dies allerdings sofort erfolgt oder nicht, lässt sich erst sehen, wenn es zu spät ist. Ein Endpunkt mag kompromittiert sein, aber noch nicht im Blickfeld der Hacker. Gerade jetzt zeigt sich auch für kleine und mittlere Unternehmen die Notwendigkeit, Network Detection and Response und Endpoint Detection and Response gemeinsam als umfassende Abwehrstrategie zu denken. EDR sieht, ob die Malware installiert wurde und organisiert die Abwehr auf dem Endpunkt.

Mit NDR die Vergangenheit sehen

Mit NDR kann man in Logging-Daten auch rückwirkend sehen, auf welche Systeme von außen Hacker zuzugreifen versuchten. NDR sieht auch typischen Datenverkehr, der aus einem solchen Zugriffsversuch resultiert, wie etwa die Kommunikation mit den C2C-Servern, Port Scanning und spezifischer Datenverkehr. NDR erlaubt auch das Blocken und Segmentieren von Netzwerken oder die Quarantäne von Systemen – eine im Zweifelsfall unbedingt zu treffende Maßnahme. Eine NDR-Lösung wie NovaComand analysiert auch Telemetriedaten von Endpunkten. NovaCommand hat einen Patch veröffentlicht und die Regeln zur Erkennung einer solchen Attacke aktualisiert. NovaCommand triggert auch andere Lösungen von Drittanbietern an, betroffene Systeme und Netzwerkabschnitte zu blocken und zu segmentieren.“

Passende Artikel zum Thema