Update (22.12.2021):
Log4j 2.17.0 ist veröffentlicht. Diese Version verhindert eine Denial-of-Service Attacke.
Die bisherigen Mitigations-Lösungen, wie z. B. das Setzen der Variable log4j2.formatMsgNoLookups auf "true", werden nicht mehr als vollständig wirksam angesehen und sind auch offiziell diskreditiert.
Falls kein Update von Log4j erfolgen kann, muss die JndiLookup Klasse aus dem Klassenpfad entfernt werden, zum Beispiel:
"zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class"
Quellen:
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
Update (20.12.2021):
Es wurde festgestellt, dass der Fix zur Behebung von CVE-2021-44228 in Apache Log4j 2.15.0 in bestimmten nicht-standardmäßigen Konfigurationen unvollständig war.
Log4j 2.16.0 (Java 8) und 2.12.2 (Java 7) beheben dieses Problem, indem sie die Unterstützung für Nachrichten-Lookup-Muster entfernen und die JNDI-Funktionalität standardmäßig deaktivieren.
Quelle: nvd.nist.gov/vuln/detail/CVE-2021-45046
Liebe Kolleginnen und Kollegen der IT in den Fachbereichen und zentralen Einrichtungen,
aktuell bedroht eine kritische Sicherheitslücke in log4j derzeit Serversysteme weltweit. Dies erfordert Handlungsbedarf für zentrale sowie dezentrale IT-Systeme der HSBO.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat der Schwachstelle die höchste Warnstufe erteilt IT-Bedrohungslage*: 4 / Rot.
Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen.
Nach aktuellem Stand sind die Versionen 2.0 bis 2.14.x betroffen die es Angreifern gegebenenfalls ermöglicht, auf dem Zielsystem eigenen Programmcode auszuführen und so den Server zu kompromittieren.
Hinweis: IT-Systeme, die Apache Struts verwenden, sind höchst wahrscheinlich verwundbar.
ToDo:
- prüfen Sie umgehend ob in Ihren IT-Systemen diese Bibliothek eingesetzt wird,
- falls ja UND log4j in den betroffenen Versionen 2.0 bis 2.14.1 installiert ist, MUSS umgehend der für log4j bereits verfügbare Sicherheits-Patch installiert werden. Informieren Sie sich auch vorab auf den Herstellerseiten ob für die betroffene Anwendung bereits ein Sicherheitsupdate vorliegt.
- Falls diese Maßnahmen aktuell nicht umgesetzt werden können, sollte das System temporär außer Betrieb genommen werden.
- Geben Sie dem IT-Sicherheitsbeauftragten (Herr Kabashi) bitte Bescheid falls ein betroffenes System gefunden wurde und welche Maßnahmen dazu ergriffen wurden.
Log4j v1 Hinweis:
Falls Log4j in älteren Versionen als 2.0 verwendet wird ist zu beachten, dass diese für andere RCE-Angriffe anfällig sind und die gleichen Maßnahmen, wie oben beschrieben, empfohlen werden.
Erkennen von verwundbaren Systemen:
- Sie können über Suchfunktionen des eingesetzten Betriebssystems nach Dateien mit dem Muster log4j*.jar in den entsprechenden Anwendungsverzeichnissen suchen.
- Der einfachste Weg um festzustellen ob ein System verwundbar ist, ist eine DNS-Abfrage auszulösen. Durch die Verwendung der Adresse eines kostenlosen Online-DNS-Protokollierungstools im Exploit-String können wir feststellen, ob die Schwachstelle ausgelöst wird.
- CanaryTokens.org ist eine Open-Source-Webanwendung für diesen Zweck, die sogar den Exploit-String automatisch generiert und eine E-Mail-Benachrichtigung sendet, wenn der DNS abgefragt wird. Wählen Sie Log4Shell aus dem Dropdown-Menü. Fügen Sie dann die Zeichenfolge in ein Anfragefeld ein, von dem Sie erwarten, dass der Server es protokolliert. Dabei kann es sich um eine Formulareingabe oder einen HTTP-Header handeln (Beispiel: Sie fügen den generierten Token im Benutzername-Feld einer Login-Seite ein und klicken auf Anmelden).
Folgend finden Sie ein Dokument von unserem externen IT-Dienstleister G DATA mit einer zussammenfassung von Handlungsempfehlungen: Dokument sehen
*Diese Seite wird fortlaufend zu diesem Thema aktualisiert.
Bei Rückfragen und Hilfestellung steht die Campus IT Ihnen gerne zur Verfügung.
Quellen:
