In Servern und Serverdiensten, die auf der Programmiersprache #JAVA basieren (nicht Javascript!), gibt es eine Bibliothek namens #LOG4J zum Protokollieren von Informationen. Manche Software-Produkte verwenden diese Bibliothek. Ist diese Bibliothek nicht auf dem neusten Stand (betrifft Versionen 2.0 bis 2.16), können Angreifer Kontrolle über den darunter liegenden Server erlangen. Betroffen sind somit Linux-, Unix- und Windows Server – sofern Sie einen JAVA-basierten Serverdienst mit der Bibliothek nutzen. [Anm d. Red.] Grundsätzlich haben auch alte LOG4J-Bibliotheken Version 1.x Sicherheitslücken. Das Bundesamt (BSI) stuft diese alten Versionen aber als geringes Risiko ein.
Zwei Beispiele: Die vielfach verwendeten Uqibiti WLAN-Access Points der amerikanischen Firma Unifi. Die Controller-Software, um ganze WLAN-Netzwerke zu verwalten, lässt sich auf einer Hardware-Appliance, unter Linux oder unter Windows (-Server) als Dienst betreiben. Nur mit der aktuellen Version sind die Lücken geschlossen. Firmware- bzw. Software-Updates sind unbedingt erforderlich. Als JAVA-Runtime kann das kostenlose Adoptium Temurin eingesetzt werden.
Seccommerce, der Anbieter von Digitalen Signatur-Lösungen (z.B. E-Rechnung mit digitaler Signatur gegen Fake E-Mails) hat veröffentlicht, dass sie kein LOG4J einsetzen in deren Server-Softareprodukten – und am Client Adoptium JRE unterstützen.
Handlungsbedarf
- Ermitteln Sie den Software-Bestand auf Ihren Servern und Endgeräten (Windows und Linux), sowie auf Hardware-Appliances (wie Kamera-Servern, Zeiterfassungs-Software und Diensten auf Servern). Hierbei kann Open-Audit (audit und nmap scan) insbesondere für die Windows-Umgebung hilfreich sein.
- Nehmen Sie mit den Herstellern der Software Kontakt auf, und/oder prüfen, ob es aktuelle Versionen oder Firmware Updates gibt.
- Führen Sie diese Updates durch (oder lassen sie vom Anbieter durchführen).
Scan-Tool (nur für Windows)
Für das Entdecken von Lücken auf der Windows-Plattform (erkennt damit nicht Log4J in Hardwaregeräten oder Linux-Systemen) gibt es auf GitHub ein Befehlszeilen Werkzeug, das man auf jedem Windows-Server oder PC, auf denen JAVA installiert ist, ausführen muss. Es sucht (nur die angegebenen Laufwerke) nach anfälligen Bibliotheken und schreibt einen Bericht darüber. Die Java-Komponente aktualisieren oder entfernen (wenn die Software sie nicht benötigt), muss man immer noch:
Eine Beschreibung wie man das Werkzeug nutzt und der direkte Download sind hier beschrieben. An der administrativen Befehlszeile oder Powershell ist dann: Log4j2-scan c:\ –fix auszuführen und das Ergebnis auszuwerten.
Die gängigen Tools finden auch alte (Version 1.x) Bibliotheken von LOG4J. Im Regelfall eignet es sich, solche unbenutzten JAR-Dateien zu isolieren und wenn keine Nebenwirkungen auftreten, dann zeitverzögert zu entsorgen. Lässt sich eine genutzte Software (die diese Bibliotheken und JAVA benötigt) nicht mehr nutzen, wenden Sie sich bitte an den jeweiligen Software-Hersteller.
Ein Leben ohne JAVA ist möglich (und nicht sinnlos)
Ungeachtet der oben genannten Schritte gilt: Wenn möglich und geprüft, JAVA Runtimes komplett deinstallieren oder den Hersteller fragen, ob sich Adoptium Temurin Runtime einsetzen lässt. Hier gibt es regelmäßig Sicherheitsupdates.
Produktmatrix und Status
Produkt | enthält unsicheres LOG4J 2.x | Empfehlung |
w.safe Firewall | Nein | abschalten und durch Managed | Firewall ersetzen, Supportende der ubuntu Version erreicht, nur 1Gen Firewall |
Blackbox alt | Nein | durch Managed | VPN Access ersetzen, da Supportende der ubuntu Version erreicht |
Managed | Firewall und Managed | vpn Access | Nein | neue 2. Generation Firewall und Blackbox mit Azure Cloud Option |
Seccommerce Secsigner Server und Komponenten | Nein | verwendet JAVA (Adoptium), Logging ist aber anders gelöst |
Uqibiti Controller Firmware/Software | Ja | Update verfügbar. Version auf 6.5.55 aktualisieren, ab dieser Version keine Gefährdung mehr. Mit dem 55er Update wurde auch die in LOG4J 2.15 entdeckte zweite Lücke niedrigen Grades geschlossen. |
Fujitsu IRMC | unbekannt | Vorsorglich aktuelle Firmware-Version einsetzen, Konsole auf HTML5 umstellen (Einstellungen, Dienste, erweiterte Videoumleitung – AVR) |
Fujitsu ServerView Suite | Ja | Problem noch nicht gelöst, kritische Komponente enthalten, Die ServerView-Suite, wenn Sie auf Ihren Server installiert ist, sowie die dazugehörige JAVA Plattform deinstallieren! PDF Advisory von FTS |
Fujitsu RAID Manager | Ja | Auch wenn laut Fujitsu eine nicht betroffene Version eingesetzt wird: Deinstallieren, sowie die alten JAVA-Versionen unter Windows, die diese Software mit sich führt. Die RAID Konfiguration lässt sich auch im UEFI/BIOS des Servers verändern. |
s.dok d.3 Presentation Server | Nein | JAVA wird verwendet, LOG4J laut d.velop nur wenn individuelle Webdienste dies nutzen und mitbringen. Wir haben keine solchen Webdienste im Einsatz in s.dok.* |
d.velop documents (d.3ecm) ab Version 2020.07 | Nein | Betrifft nicht direkt log4j, ist aber eine andere Sicherheitslücke, über die der Hersteller informiert. Patch verfügbar von d.3, Das Risiko eines Angriffs wird als sehr niedrig vom Hersteller eingestuft, der Patch sollte aber installiert werden. |
s.dok d.3 andere Komponenten | Nein | Aus unserer Sicht sind keine der betroffenen Module in unseren s.dok Installationen installiert oder in Verwendung. Hersteller-Information hier: https://kb.d-velop.de/s/article/000001798?language=de* |
s.scan Verify | Nein | The following products do not use Log4J: IRISXtract |
Managed | Monitoring | Nein | Paessler PRTG Network Monitor ist nicht betroffen |
IGEL UMS Software (Thin Clients) | Ja | Patch verfügbar. Update to UMS 6.09.120, which contains Log4j version 2.17. Details hier: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html |
E/D/E Multishop | Nein | Der Multishop ist von der aktuellen Bedrohung nicht betroffen. Präventiv wurden zusätzliche Schutz-Maßnahmen durch unseren Hosting-Partner ergriffen. Darüber hinaus wird die aktuelle Bedrohungslage überwacht. Der Dienst „Elasticsearch“, wurde entsprechend der Empfehlungen der Elastic-Entwickler, abgesichert. |
Syntellect CT-Connect CTI (end of life) | Ja | Noch vorhandene Installationen auf (alten) Servern sollten ebenso wie alte JAVA-Versionen gelöscht werden, da diese Middleware sowohl JAVA, als auch die Bibliothek verwendet. Diese Middleware war bei der GWS Telefonsteuerung in den 2000ern im Einsatz.Hierbei ist nur die Serverkomponente, nicht der Client betroffen. Mittlerweile gibt es das Unternehmen nicht mehr. Als Nachfolge-Middleware kommen CATS und CATSpro von Spuentrup Software zum Einsatz. |
s.tel und s.tel Pro bzw. CATS und CATSpro | Nein | Keine Versionen der CATS – Software nutzen das Modul Log4J. Die CATS Server sind somit generell nicht betroffen. Java-Code wird nur in CATS/3 Servern eingesetzt, wenn sie auf der TAPI Schnittstelle aufsetzen. Auch hier wird Log4J nicht verwendet. |
w.shop, w.info, Managed|Transfer | Nein | Sofern in den Server-Komponenten das LOG4J Modul von uns entdeckt wurde, ist es entweder nicht von den Sicherheitslücken betroffen oder wurde zeitnah auf aktuelle Versionen, die nicht von der Lücke betroffen sind, aktualisiert, bzw. die betreffende JAVA-Klasse entfernt |
gevis (classic und ERP | BC) Azure Plattform |
Nein | In unserer Warenwirtschaft und dem darunter liegenden Microsoft Dynamics 365 Business Central bzw. Dynamics NAV werden keine LOG4J Komponenten eingesetzt. Kein Handlungsbedarf. Details: https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ |
Eine weitere Sammlung von Softwareprodukten und Hersteller-Erklärungen ist auf Gist zu finden. Allerdings unterscheidet die Liste nicht, ob das Produkt ein verwundbares LOG4J enthält oder nicht. Wenn Sie die von Ihnen verwendeten Produkte in der Liste durchklicken, erfahren Sie, ob Ihre Produkte betroffen sind oder gar kein LOG4J enthalten.
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592