Elmar Geese

Erkennung der Log4j-Schwachstelle in Greenbone-Feeds verfügbar

Update vom 20.12.2021: Informationen über weitere Schwachstellen, die für Log4j gefunden wurden, finden Sie hier.

Update vom 15.12.2021: Die wichtigstens FAQ zur Erkennung der Log4j-Schwachstelle mit Greenbone finden Sie hier.

Eine kritische Sicherheitslücke (Log4Shell, CVE-2021-44228) in der weit verbreiteten Java-Bibliothek Log4j wurde entdeckt. Greenbone hat lokale Sicherheitstests und aktive Prüfungen über HTTP in seine Feeds integriert, die bei der Erkennung der Log4j-Schwachstelle helfen und herausfinden, ob und welche Systeme betroffen sein könnten. Zusätzlich ist eine spezielle Scan-Konfiguration, die genau auf diese Schwachstelle prüft, für schnelle Ergebnisse über die Feeds verfügbar.

log4j-Schwachstelle

Die Sicherheitslücke führt laut dem Bundesamt für Sicherheit in der Informationstechnik (BSI) zu einer äußerst kritischen Bedrohungslage. Aus diesem Grund hat das BSI eine Warnung der höchsten Stufe zu diesem Thema veröffentlicht. Die Sicherheitslücke ist trivial ausnutzbar und kann eine vollständige Übernahme der betroffenen Systeme ermöglichen.

Es handelt sich um ein kritisches Risiko, da Angreifende über verschiedene Wege Codeschnipsel in das Log4j-Modul einschleusen können (z. B. über eine reguläre Chat-Nachricht) und dann Code zur Ausführung von einem beliebigen LDAP-Server laden können.

Personen, die Log4j einsetzen, wird dringend empfohlen, ihre Lösungen auf Log4j-Version 2.15.0 (oder höher) zu aktualisieren, um diese Schwachstelle zu entschärfen. Folgendes sollte aber beachtet werden:

  • Das Update schränkt derzeit standardmäßig „nur“ den Zugriff auf externe LDAP-Server ein (erlaubt nur localhost/127.0.0.1) und setzt die Systemeigenschaft log4j2.formatMsgNoLookups auf true.
  • Obwohl dies das Risiko mindert, kann es immer noch Anwendungen geben, die mit Log4j-Version 2.15.0 arbeiten und bei denen beide (oder eine) der oben genannten Einstellungen nicht korrekt oder falsch konfiguriert sind, sodass der Angriffsvektor weiterhin besteht.

In Bezug auf unsere Lösung sollte auch Folgendes beachtet werden:

  • Für eine erfolgreiche Erkennung dieses Risikos muss der Scanner-Host für den Zielhost über TCP erreichbar sein.
  • Es kann auch eine Schwachstelle in einer Software bestehen, die z. B. nur die Syslogs von anderen Remote-Systemen sammelt und protokolliert, aber selbst keine Protokolle annimmt. Solche Systeme könnten immer noch durch Log Pollution angegriffen werden.
  • Es ist sehr wichtig, die Updates der betroffenen Produkte zu überwachen.
  • Außerdem sollten alle Systeme, die anfällig waren, auf Kompromittierung untersucht werden.


Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von