Keine Frage, die Sache mit in Log4j bzw. die so genannte Lücke Log4Shell (BSI), stellt ein Problem dar. Leider gibt es neben dem eigentlichen Sicherheitsproblem noch diverse Nebenwirkungen.
Der Lesart nach funktioniert Log4j bzw. die problematische Stelle wie designt, ergo konzeptioneller Fehler, also schon mal schlecht. “Irgendeiner” hat es entdeckt, postet ein Proof-of-Concept und/oder gleich (aus-)nutzbaren Code und schon rollt die Zero Day-Attacke.
Keine Frage, die Lücke muss gestopft werden. Neben den rein technischen Aspekten zeigt allerdings Log4shell noch weitere Probleme auf. So kommen täglich zig Anfragen rein, ob man denn selbst betroffen ist, gemeint ist das Kunden dies fragen oder das unaufgefordert unglaublich viele Lieferanten und Distributoren Mails schicken, das ihre Produkte (nicht) betroffen sind. Eigentlich löblich, wenn sich jeder Gedanken macht, aber die Masse ist ungut. So frisst das Anfragen-beantworten/-abarbeiten Zeit, die wiederum zum eigentlichen Patchen (ganz gleich welcher Lücke) fehlt.
Hinzu kommen dann noch solche Situationen, das zufälligerweise ein anderes Problem auftritt, aber der Kollege oder Kunde gleich in Panik verfällt, denn es hängt ja mit Log4shell zusammen, obwohl man Log4j weder bewusst noch unbewusst im Einsatz hat. Zeitweise wurde ich diesbezüglich im Minutentakt zugespamt. Nicht schön und für alle Beteiligten auch nicht hilfreich!
Als weiteres offenbart diese Lücke ein weiteres Mal (ich nenn’ es mal) einen Missstand in der Open Source-Welt. Wichtige Komponenten sind von einer oder wenigen Persone/n abhängig, die das Ganze auch noch unbezahlt entwickeln und pflegen! Das ist schwer zu verstehen, da mitunter milliardenschwere Konzerne die Software nutzen und damit Geld verdienen! Da müsste doch eigentlich etwas Geld über sein, um diejenigen die zum Teil für den Erfolg Mitveranwortlich sind, für ihre Arbeit entlohnen zu können. Vermutlich ist die Dividende für die Aktionäre aber dann wohl wichtiger.
Wo ist nun jetzt welcher Handlungsbedarf und welches Risiko gegeben?
Systeme wie Webserver, die direkt über das Internet erreichbar sind, tragen das Hauptrisiko. Hier sollte zuerst abgesichert bzw. gepatcht werden, vorausgesetzt, der jeweilige Software-Anbieter hat bis jetzt ein oder mehrere Update/s geliefert. Selbst kann man Log4j oft nicht patchen, da es in anderer Software integriert ist.
Mit weniger hohem Risiko sind Systeme belastet, die sich nur im LAN befinden. Hier wäre dann noch zusätzlich zu unterscheiden, ob die betroffenen Ports zum LAN hin offen sind oder nur über localhost erreicht werden können.
Wo und wie findet man allerdings Log4j?
Man denkt zwar mitunter zuerst an (Web-)Anwendungen die man bewusst z.B. für die tägliche Arbeit nutzt, aber es gibt eine Vielzahl an Systemen und Applikationen, die dieses Modul enthalten können. Aus dem IT-administrativen Bereich z.B. Server-Verwaltungsanwendungen oder Monitoring-Systeme. Zwei Beispiele wären SuperDoctor von Supermicro und RAID-Controller-Software wie maxView von Microchip/Microsemi/Adaptec. Allerdings muss dann noch nach Version unterschieden werden, dazu weiter unten mehr.
Wer unter Windows selbst mal suchen möchte kann dies in einer Eingabeaufforderung vom root, gemeint ist “C:\” aus, wie folgt tun:
dir *log4j*.* /s
Eine Ausgabe kann so aussehen:
C:\>dir *log4j*.* /s
Datenträger in Laufwerk C: ist System
Volumeseriennummer: 34E8-EBAA
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\config
22.12.2017 18:25 914 log4j-fdt.properties
22.12.2017 18:25 5.686 log4j.properties
22.12.2017 18:25 1.712 sdclog4j.properties
3 Datei(en), 8.312 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\libs
22.12.2017 18:25 367.444 log4j-1.2.14.jar
22.12.2017 18:25 146.104 log4j-rolling-appender-20100717-1237-1.2.9.j
ar
22.12.2017 18:25 12.244 slf4j-log4j12-1.7.25.jar
3 Datei(en), 525.792 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\plugins\builtin\web\We
bContent\css\imgs\admin
22.12.2017 18:25 21.134 log4j.png
1 Datei(en), 21.134 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\plugins\builtin\web\We
bContent\WEB-INF\classes
22.12.2017 18:25 1.135 log4j.properties
1 Datei(en), 1.135 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\tools\config
22.12.2017 18:16 566 log4j.properties
1 Datei(en), 566 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\tools\libs
22.12.2017 18:16 367.444 log4j-1.2.14.jar
22.12.2017 18:16 146.104 log4j-rolling-appender-20100717-1237-1.2.9.j
ar
22.12.2017 18:16 12.244 slf4j-log4j12-1.7.25.jar
3 Datei(en), 525.792 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\tray\config
22.12.2017 18:25 1.134 tray_log4j.properties
1 Datei(en), 1.134 Bytes
Verzeichnis von C:\Program Files\Supermicro\SuperDoctor5\tray\libs
22.12.2017 18:25 367.444 log4j-1.2.14.jar
22.12.2017 18:25 146.104 log4j-rolling-appender-20100717-1237-1.2.9.j
ar
22.12.2017 18:25 12.244 slf4j-log4j12-1.7.25.jar
3 Datei(en), 525.792 Bytes
Anzahl der angezeigten Dateien:
16 Datei(en), 1.609.657 Bytes
0 Verzeichnis(se), 35.180.187.648 Bytes frei
Sofern Anwendungen auf weiteren Laufwerken installiert sind, sollte man auch diese prüfen.
In der obigen Ausgabe wurde Log4j in einer älteren Version von SuperDoctor gefunden. Von der aktuellen Lücke betroffen ist allerdings “Log4j 2”! Hinzu kommt folgender Punkt:
Für gewöhnlich sollten die Web-Interfaces von Server- oder RAID-Verwaltungsanwendungen nicht für Zugriffe von außerhalb offen sein. Es reicht wenn diese via localhost aufgerufen werden können. Zur Sicherheit kann man seine Firewall-Einstellungen überprüfen oder von einem anderen System aus einen Port-Scan, bspw. mit Angry IP Scanner, durchführen.
Quellen
Thomas Krenn – Wiki – Log4shell Zero-Day-Sicherheitslücke
Supermicro – Security Center – Supermicro’s response to Apache Log4j 2 vulnerability (Log4shell)
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Den Missstand, den Du in der Open-Source-Welt zu erkennen glaubst, den sehe ich nicht. Für mich ist Open Source eher in akademischem Umfeld angesiedelt. Die Offenlegung der Quellen dient dem Lernen und der Lehre, ermöglicht breite Diskussionen und fördert vielleicht neue Ideen zutage. Damit bildet sie einen Gegenpol zur sonst weit verbreiteten kommerziellen Geheimniskrämerei.
Wer jedoch Open Source Produkte für kommerzielle Zwecke einsetzt, ist dazu berufen, die offengelegten Quellen zu überprüfen, zu verstehen und zu verbessern, um die Open-Source-Idee zu fördern. Wer das nicht will, muss eben seine eigene Software entwickeln und gegebenenfalls kommerzielle Produkte hinzukaufen.
Wer sich also durch den ungeprüften Einsatz kostenloser, immanent fehlerhafter Software am Markt einen Wettbewerbsvorteil verschafft, sollte dafür haftbar gemacht werden, wenn es durch solch fahrlässiges Verhalten zu Schäden kommt. Wenn das nicht vor den Gerichten durchgefochten wird, sind alle sorgfältigen Entwickler am Markt letztlich nicht konkurrenzfähig. In Deutschland wäre das vielleicht ein lukratives Betätigungsfeld für Abmahnanwälte. Die brauchen dann nicht mehr Websitebetreibern nachzustellen, die ein Komma im Impressum vergessen haben.
Ein schlimmeres Problem ist jedoch, dass mit Bitcoin und Konsorten in Verbindung mit deren Einbindung in internationale Zahlungssysteme ideale Bezahlmodelle für Kriminelle und Terroristen realisiert worden sind. So hat man es diesen netten Zeitgenossen endlich ermöglicht, gefahrlos die Früchte ihres Treibens ernten zu können. Beispielsweise Verschlüsselungs-Schadsoftware hat dadurch erst ein überaus sinnvolles Einsatzgebiet gefunden: nämlich als wirkungsvoller Knebel für die Erpressung von Firmen und Privatpersonen.