Das Internet ist explodiert, weil eine Programmiersprache verwendet wird, indessen ein Modul eingebunden werden kann, welches für das Logging zuständig ist und auf Grund der Struktur auch gleich alle FQDN Anfragen auflöst, die möglicherweise mit geloggt werden. Und wenn es ein FQDN zu einem bösartigen LDAP Verzeichnis ist, dann hat man Freunde auf seinem Server oder Client.
Das Modul heißt Log4J, die Programmiersprache Java und die Schwachstelle hat den schönen Namen Log4Shell. Und fast alle größeren Java Anwendungen sind betroffen, über alle Systeme verteilt. Weil irgendjemand meinte, “Jopp, ein Modul das OpenSource von zwei Hobbyprogrammierern entwickelt wurde, wird zum defacto Standard zum Logging in Java erklärt.” Das nennt man dann Komplettversagen der gesamten IT Welt. Und nicht die Entwickler des Moduls sind Schuld, Schuld sind die Entwickler der großen Hersteller, welche das Modul vor Einbinden in ein Programm nicht kontrolliert haben.
Aber nun ist das Kind in den Brunnen gefallen und die wichtigste Frage ist:
Wie verflucht schütze ich nun meinen Minecraft Server? Oder respektive andere Java-Anwendungen wie die gesamte Unifi Software.
Erste Fall und der Beste: Aktualisieren!!
Unifi bietet bereits aktuelle Updates an, wie auch andere Hersteller.
Auch Mojang bietet bereits mit Version 18.1 die aktuellste Fassung an, wo diese Schwachstelle nicht mehr enthalten ist.
DOCH HALT, stimmt das wirklich?
Die Version 18.1 verwendet Log4J Version 2.14.1 wo prinzipiell die Bibliothek noch enthalten ist – und sie ist es auch noch, wahrscheinlich.
Es gibt zwei Log4J Module in Minecraft, welche mit 2.14.1 bezeichnet sind. In dem einen ist die Bibliothek noch vorhanden, in dem Anderen nicht mehr.
Wie dem auch sei, wenn man eine ältere Version von Minecraft spielt oder auf Nummer sicher gehen möchte sollte man MultiMC (https://multimc.org/posts/log4j-remote-execution.html) verwenden. Jede Änderung direkt in den Dateien, wird vom offiziellen Mojang Launcher wieder rückgängig gemacht. Natürlich muss man dem alternativen Launcher trauen – man hinterlegt nämlich seine Anmeldedaten ganz normal. Die Entscheidung liegt also zwischen Pest und Cholera.
Entscheiden müsst ihr aber, denn auch der Client loggt eine Menge mit und kann, wenn man auf einem Server eingeloggt ist und der String für eine Remote Code Execution ausgegeben wird, gekapert werden.
Log4J JNDI Bibliothek entfernen
- Um die Bibliothek aus dem Minecraft Server wie Spigot zu entfernen benötigt man ein Archivprogramm wie 7-Zip.
- Geht zur JAR-Datei für den Server – bei mir “spigot_server-1.16.5.jar”
- Macht vorher ein Backup der JAR-Datei.
- Dort nun Rechtsklicken, 7-Zip auswählen und Öffnen klicken.
- Nun durch die Verzeichnisstruktur klicken:
“org\apache\logging\log4j\core\lookup\”- Die Struktur ist im Normalfall immer dieselbe. Egal ob eine Log4j*.jar direkt aufgemacht wird oder sie bereits in einer JAR wie dem Spigot Server integriert ist.
- In diesem Ordner liegt “JndiLookup.class”.
Diese löscht ihr nun – fertig. Problem gelöst. JNDI Anfragen können nicht mehr von Log4j aufgelöst werden. - 7-Zip schließen, der Inhalt wird automatisch gespeichert.
So der Server ist soweit mit der Holzhammer-Methode gesichert. Prinzipiell könnte man so ähnlich auch den Client von älteren Versionen präparieren. Auf Grund der Launcher Überprüfung ist dies wie bereits oben benannt nicht möglich und man muss auf Drittanbieter Tools zurückgreifen. Jede andere Anwendung die ebenfalls diese Schwachstelle aufweist und keine automatische Dateiprüfung macht, kann ebenfalls so gesichert werden.
Problem: Wenn die JDNI Bibliotheksklasse unbedingt notwendig ist, stürzt im schlimmsten Fall die Anwendung ins Nirvana. Beim Minecraft Server gibt es einen kurzen Hänger, läuft dann aber weiter.
