Beiträge

Log4j war von einer Schwachstelle betroffen, die Remote-Code-Execution-Angriffe (RCE-Angriffe) ermöglichte. Kurz gesagt, konnten Benutzereingaben in eine Software zu einer Codeausführung auf einem entfernten Server führen. Dies stellt ein schwerwiegendes Sicherheitsrisiko dar. Die Schwachstelle wurde „Log4Shell“ (CVE-2021-44228) genannt und sofort vom Log4j-Team behoben. In den folgenden Tagen wurden weitere Log4j-Schwachstellen gefunden. Diese haben zwar nicht die gleichen Auswirkungen wie die erste, können aber ebenfalls schwere Schäden verursachen. Aus diesem Grund ist es sehr wichtig, die Systeme zu überprüfen und immer auf die neuesten Versionen zu aktualisieren.

Da Log4j in zahlreichen Softwareprodukten enthalten ist, mussten und müssen auch die Hersteller der Produkte Updates bereitstellen. Dies ist noch nicht abgeschlossen und es könnten in Zukunft weitere Log4j-Schwachstellen auftauchen.

Als ein bewegliches Ziel bekommt Log4j immer noch viel Aufmerksamkeit, unter verschiedenen Aspekten:

  • Neue (und glücklicherweise weniger schwerwiegende) Sicherheitslücken werden gefunden.
  • Es entstehen neue Initiativen zur proaktiven Überprüfung von Log4-Quellen, wie zum Beispiel die Initiative von Google: Improving OSS-Fuzz and Jazzer to catch Log4Shell
  • Bei Greenbone erstellen wir noch mehr Schwachstellentests, um eine bessere Testabdeckung zu erreichen, und stellen sie täglich für unsere Produkte bereit.

Wir haben bereits eine ziemlich gute CVE-Abdeckung für die zusätzlichen Log4j-Schwachstellen, die in den letzten Tagen veröffentlicht wurden, erzielt, einschließlich:

  • CVE-2021-44228
  • CVE-2021-4104
  • CVE-2021-45046
  • CVE-2021-45105

Wie bereits erwähnt, hören wir hier nicht auf. Weitere lokale Sicherheitsprüfungen werden heute und morgen folgen, sobald die Linux-Distributionen ihre Advisories veröffentlicht haben.

Wir haben bereits einige Fakten über Log4j und den Umgang damit in unseren letzten Beiträgen veröffentlicht:


Das Schwachstellenmanagement von Greenbone findet Anwendungen mit Log4j-Schwachstellen in Systemen, die auf jeden Fall gepatcht oder anderweitig geschützt werden müssen. Je nach Art der Systeme und Schwachstelle können diese besser oder schlechter gefunden werden. Auch die Erkennung verbessert sich ständig und wird fortlaufend aktualisiert. Neue Lücken werden gefunden. Es können daher immer noch weitere Systeme mit Log4shell-Schwachstellen im Netz vorhanden sein. Daher lohnt sich eine regelmäßige Aktualisierung und Scannen aller Systeme. Hierfür bietet das Greenbone-Schwachstellenmanagement entsprechende Automatisierungsfunktionen. Wie aber werden Schwachstellen gefunden, und wo können sie sich verbergen? Warum sind Schwachstellen nicht immer direkt auffindbar? Im folgenden Artikel erhalten Sie eine kurze Einsicht, wie das Scanning bei Schwachstellen wie Log4Shell funktioniert.

Ein Schwachstellenscanner stellt gezielt Anfragen an Systeme und Dienste und kann aus den Antworten ablesen, welcher Art die Systeme und Dienste sind, aber auch welche Produkte dahinter stehen. Das schließt auch Informationen wie deren Versionen oder auch Einstellungen und weitere Eigenschaften ein. Damit lässt sich in vielen Fällen ablesen, ob eine Anfälligkeit für eine bestimmte Schwachstelle vorliegt und auch, ob diese schon beseitigt wurde. In der Praxis sind das teilweise hochkomplizierte und verschachtelte Anfragen, vor allem aber auch sehr, sehr viele. Es werden ganze Netzwerke nach Tausenden von verschiedenen Schwachstellen durchforstet.

Bei der Log4j-Schwachstelle „Log4Shell“ (CVE-2021-44228) handelt es sich um eine fehlerhafte Programm-Bibliothek, die in vielen Produkten für Web-Dienste verwendet wird. Teilweise ist sie daher durch einen Schwachstellenscan direkt sichtbar, teilweise ist sie aber auch hinter anderen Elementen versteckt. Deshalb gibt es auch nicht nur einen Schwachstellentest für Log4j, sondern zahlreiche. Es kommen ständig weitere hinzu, weil die Hersteller der jeweiligen Produkte entsprechende Informationen teilen und auch Updates zur Verfügung stellen, um die Lücken zu schließen. Die Liste der von Log4Shell betroffenen Systeme wird unter https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 ständig aktualisiert.

Einige der Schwachstellentests erfordern einen authentifizierten Scan. Das bedeutet, dass sich der Scanner zunächst auf einem System anmelden muss, um im System dann die Verwundbarkeit festzustellen. Ein authentifizierter Scan kann mehr Details über Schwachstellen auf dem gescannten System bereitstellen.

Die Schwachstellentests, die geeignet sind die Log4j-Schwachstelle zu finden, werden gesammelt in einer Scan-Konfiguration bereitgestellt. Greenbone hält diese „Log4j“-Scan-Konfiguration kontinuierlich aktuell, um immer wieder neue Tests hinzuzufügen. Dadurch kann ein Scanvorgang morgen eine Log4j-Schwachstelle melden, die heute noch nicht gefunden wurde. Es ist daher ratsam, den Log4j-Scan so zu konfigurieren, dass er automatisch regelmäßig ausgeführt wird. Besonders wichtig ist dies in den nächsten Wochen, in denen viele Softwarehersteller weitere Erkenntnisse zusammentragen. Greenbone integriert diese Erkenntnisse laufend in die Tests und in die Scan-Konfiguration.

Scanning bei Schwachstellen wie Log4Shell

Muss eine Schwachstelle ausgenutzt werden, um sie zu finden?

Eine Schwachstelle auzunutzen, um sie zu finden, ist nicht ratsam. Und zum Glück auch nicht erforderlich. Dabei könnten genau die Schäden entstehen, die unbedingt vermieden werden sollen. Ein Produktanbieter, der das Ausnutzen der Schwachstellen als Funktion bereitstellt, würde zudem möglicherweise den Missbrauch dieser Funktion stark befördern, was weitere – nicht nur rechtliche – Probleme aufwirft. Daher beinhaltet das Schwachstellenmanagement von Greenbone solche Funktionen nicht.

Eine Ausnutzung der Log4j-Schwachstelle wie es Angreifende tun würden, ist auch nicht erforderlich, um das Vorhandensein der Schwachstelle nachzuweisen. Greenbone hat verschiedene Tests zum Nachweis für Log4Shell entwickelt, die jeweils unterschiedlich tief in die Systeme schauen. Mehrere Tests können die Log4j-Schwachstelle mit 100%iger Gewissheit nachweisen, die meisten mit einer Sicherheit von 80 % bis 97 %. Einige Tests sammeln außerdem Indikatoren von 30 %, wo sie nicht nahe genug an die Schwachstelle herankommen. Jeder Test bei Greenbone macht eine Aussage zu der Nachweissicherheit, welche als „Qualität der Erkennung“ angegeben wird.

Welche Rolle spielen die Hersteller von Softwareprodukten?

Hersteller verschiedenster Produkte können Log4j-Bibliotheken verwenden, die damit nun verwundbar sind. Die Produkthersteller haben Log4j auf unterschiedliche Weise eingebunden. In der Regel kann durch einen tiefen Scan Log4j auch ohne Mithilfe des Hersteller gefunden werden. Die meisten Hersteller unterstützen den Vorgang aber auch durch öffentliche Schwachstellenmeldungen. Diese können dann genutzt werden, um Schwachstellentests zu schreiben, die auch mit weniger tiefen Scans eine verlässliche Aussage zur Verwundbarkeit machen können. Der Grund dafür ist, dass die Scans durch Herstellerinformationen einfachere Konfigurationen verwenden können. Hinzu kommt, dass sie auch schneller laufen.

Grundsätzlich kann jedoch ein Schwachstellenscanner auch prüfen und Schwachstellen finden, ohne dass der Hersteller eine Schwachstellenmeldung veröffentlicht.

Fazit

Schwachstellenmanagement ist ein unverzichtbarer Bestandteil der IT-Sicherheit. Es kann Risiken finden und liefert wertvolle Hinweise zu deren Behebung. Eine 100%ige Sicherheit bietet jedoch keine einzelne Maßnahme, auch kein Schwachstellenmanagement. Um ein System sicher zu machen, werden viele Systeme eingesetzt, die in ihrer Gesamtheit die bestmögliche Sicherheit bieten sollen.

Das ist vergleichbar zu einem Fahrzeug, das durch Fahrgastzelle, Gurte, Airbags, Bremsunterstützung, Assistenzsysteme und vieles mehr die Sicherheit erhöht, aber nie garantieren kann. Schwachstellenmanagement macht Risiken beherrschbar.

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


Update vom 20.12.2021: Es sind nun auch Schwachstellentests für Produkte unter Microsoft Windows verfügbar.

Hinweis: Die Tests prüfen die Existenz von Log4j und dessen Version. Ein separater Schwachstellentest ist möglicherweise nicht für jede betroffene Anwendung verfügbar, aber alle Log4j-Dateien werden gefunden und gemeldet (/pfad-zur-log4j-datei/).

Die ausgegebenen Installationspfade müssen geprüft und ggf. der Hersteller kontaktiert werden. Es muss geprüft werden, ob für die jeweilige Anwendung bereits Updates verfügbar sind und ob der Fund relevant ist.

PowerShell-Ausführungsberechtigungen auf einem Zielsystem sind für den Account erforderlich, der in einem authentifizierten Scan verwendet wird. Einige Schwachstellentests führen PowerShell-Befehle aus, um die Genauigkeit der Ergebnisse zu erhöhen, wofür Berechtigungen für die Dauer eines Scans erforderlich sind.


Update vom 15.12.2021: ein zusätzlicher Angriffsvektor wurde identifiziert und in CVE-2021-45046 gemeldet. Wir arbeiten an Schwachstellentests für diesen Vektor, obwohl unsere Tests auch für diesen zusätzlichen Fall funktionieren. Wir empfehlen, auf die neueste Log4j-Version zu aktualisieren. Der Angriff ist komplizierter und ein Schutz erfordert eine andere Konfiguration. Da es sich aber um einen sehr neuen Vektor handelt, raten wir, besser auf Nummer sicher zu gehen. Mehr Informationen unter https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.


Dieser Artikel enthält Antworten auf die am häufigsten gestellten Fragen zu Greenbones Log4j-Schwachstellentests.

Worum handelt es sich bei der Log4j-Schwachstelle?

Die „Log4Shell“-Schwachstelle betrifft eine Softwarebibliothek, die für die Aufzeichnung von Ereignissen (das so genannte „Logging“) in Software zuständig ist, die in der Programmiersprache Java geschrieben wurde. Böswillige Angreifende können diese Sicherheitslücke nutzen, um Code auf den betroffenen Systemen auszuführen.

Da diese Schwachstelle über das Internet und ohne jegliche Authentifizierung ausgenutzt werden kann, kann dies für betroffene Systeme und Unternehmen sehr kritisch sein. Da die Software auch in einer Vielzahl von Software und Diensten enthalten ist, die über das Internet zugänglich sind, sind wahrscheinlich viele Unternehmen und Dienste betroffen.

Weitere Informationen zu dieser Sicherheitslücke finden Sie hier:

Sind Greenbone-Produkte und -Dienste betroffen?

Wir haben den Status der möglicherweise betroffenen Systeme mit höchster Priorität überprüft. Keine unserer Produkte oder intern und extern erbrachten Dienstleistungen sind betroffen.

Können Greenbone-Produkte diese Schwachstelle erkennen?

Ja, Schwachstellentests wurden in den Greenbone Community Feed und in den Greenbone Enterprise Feed integriert, beginnend mit Feed-Version 202112130808. Dies bedeutet, dass sowohl unsere Appliances als auch unser Cloud-Produkt in der Lage sind, diese Sicherheitslücke zu erkennen.

Es sind zwar Schwachstellentests verfügbar, aber aufgrund der Komplexität dieser Sicherheitslücke kann nicht garantiert werden, dass eine Erkennung jedes einzelne betroffene System oder Produkt findet. Dies gilt insbesondere für nicht-authentifizierte „Remote“-Überprüfungen, und zwar aus den folgenden Gründen:

  • Das Produkt oder der Dienst könnte nur unter ganz bestimmten Umständen verwundbar sein. Da die Log4j-Bibliothek sehr komplex und hochgradig konfigurierbar ist und in vielen Produkten unterschiedlich eingesetzt wird, ist es nicht möglich, alle verwundbaren Instanzen durch eine Remote-Prüfung zu finden.
  • Sicherheitskonfigurationen im zu scannenden Netzwerk können eine erfolgreiche Überprüfung der Schwachstelle verhindern.
  • Produkte und Dienste können auch indirekt betroffen sein.

Eine spezielle Scan-Konfiguration zur direkten und schnellstmöglichen Erkennung dieser Sicherheitslücke ist ebenfalls über beide Feeds verfügbar. Bitte beachten Sie, dass die aktuelle Scan-Konfiguration nur aktive Prüfungen (remote und lokal) enthält. Paketversionsprüfungen sind nicht enthalten, um die Scan-Konfiguration und damit die Scanzeit minimal zu halten.

Ist die Erkennung im Greenbone Community Feed enthalten?

Ja. In beiden Feeds ist eine grundlegende Erkennung der Sicherheitslücke enthalten. Zusätzliche Schwachstellentests für potenziell betroffene Unternehmensprodukte sind über den Greenbone Enterprise Feed verfügbar.

Welche Erkennung ist in welchem Feed enthalten?

Greenbone Enterprise Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Enterprise Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
  • Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
  • Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
  • Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
  • VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
  • ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
  • Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
  • Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
  • Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
  • SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
  • IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)
Greenbone Community Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Community Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Consolidation of Apache Log4j detections
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

Über authentifizierte/unauthentifizierte Tests

Für einige Versionsprüfungen ist eine Authentifizierung erforderlich, für andere nicht. Außerdem können einige beides haben.

Die entsprechenden Informationen sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Die „Qualität der Erkennung“ enthält Informationen über die Erkennungsmethode. Ein Wert von „package (97 %)“ deutet auf eine authentifizierte Prüfung hin, andere Werte wie „remote_banner (80 %)“ geschehen unauthentifiziert.

Weitere technische Informationen hierzu finden Sie unter https://docs.greenbone.net/GSM-Manual/gos-21.04/de/reports.html#quality-of-detection-concept.

Über aktive Tests/Testprüfungsversion, QoD

Sie können anhand des QoD und der „Erkennungsmethode“ auf der Web-Oberfläche erkennen, ob es sich um eine aktive Prüfung handelt, wenn Sie sich die Details des Schwachstellentests anzeigen lassen.

Hinweis: Nur Systeme, die tatsächlich Eingaben protokollieren, die von Angreifenden verändert werden können (z. B. bestimmte HTTP-Anfrage-Header, URLs, …), sind verwundbar.

Die Erkennungsmethode, die Qualität der Erkennung, die Schadensminderung und viele weitere Details sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Scannen nach Knoten auf separaten VRFs & VLANs

  • Out-of-band-Scanning (OOB) ist derzeit nicht möglich. Bitte scannen Sie in jedem Segment.
  • Wir denken, dass eine solche Out-of-band-Kommunikation (OOB)/externe Interaktionsmöglichkeit in Zukunft integriert werden kann.


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.