Prüfen und patchen Sie Ihr *nix-System auf die Sicherheitslücke CVE-2021-44228

Log4Shell unter Linux

Was ist Log4Shell?

Log4j ist eine weit verbreitete Java-basierte Bibliothek. Es handelt sich um ein Stück vorgefertigten Code, der von Entwicklern verwendet werden kann, um Protokollierungsfunktionen in ihre Software zu integrieren. Sie wird seit geraumer Zeit gegenüber der eingebauten Funktion System.out.println bevorzugt, da sie umfangreiche Protokollierungsmöglichkeiten und Konfigurationen bietet.

Sicherheitsexperten entdeckten eine schwerwiegende Schwachstelle im Code der Log4j-Bibliothek, die es Angreifern ermöglicht, aus der Ferne bösartigen Code auf Zielsystemen auszuführen. Das führt dazu, dass der Angreifer Shell-Zugang zum System erlangt – daher der Name.

Wie schwerwiegend ist die Log4Shell-Schwachstelle?

Extrem! Auf der CVSS-Skala hat es eine volle Punktzahl von 10,0. Das bedeutet, dass Angreifer, die diese Sicherheitslücke gegen eines Ihrer Systeme ausnutzen, die volle (Root-)Kontrolle über das System erlangen können. Sie müssen alle betroffenen Systeme sofort überprüfen, aktualisieren und/oder patchen.

Die Log4Shell-Bewertung auf der CVSS-Website.

Ist es einfach, die Log4Shell-Schwachstelle zu erkennen und zu beheben?

Betrachtet man die Art und Weise, wie Java-Anwendungen zusammengesetzt sind, kann es ziemlich schwierig sein, die Log4j-Schwachstelle zu entdecken und zu patchen, da Java-Anwendungen als JAR-Archive verteilt werden. Diese Archive können mehrere kleinere JAR-Archive (sogenannte Abhängigkeiten) enthalten, die sie zur Laufzeit benötigen. Jedes dieser „verschachtelten“ JARs könnte eine Version der betroffenen Log4j-Bibliothek enthalten. Es handelt sich dabei allerdings nicht um eine Infektion oder eine bösartige Software. Log4j ist schlichtweg eine legitime und recht nützliche Java-Bibliothek, deren Entfernung zu Fehlfunktionen Ihrer Software/Ihres Systems führen könnte.
Ein weiterer Aspekt ist die Popularität von Log4j: Fast jede Java-Anwendung protokolliert ihre Laufzeitdaten, und nichts macht diese Aufgabe einfacher als Log4j. Die Software könnte sich also in Ihrem System befinden, ohne dass Sie davon wissen.

Welche Systeme sind von dieser Sicherheitslücke betroffen?

Im Allgemeinen sind Systeme mit Apache-Webserver und Java-Binärdateien am anfälligsten. Wenn Ihr System eines oder beide dieser Merkmale aufweist, sollten Sie sich Sorgen machen. Im Folgenden finden Sie Tipps, wie Sie Ihr System auf die betroffenen Softwarekomponenten überprüfen und diese entfernen können.

Wie kann ich überprüfen, ob mein System betroffen ist?
Wie kann ich mein System auf die Log4Shell untersuchen?

Zunächst müssen Sie einige einfache Fragen beantworten:
  1. Läuft auf Ihrem System der Apache-Webserver?
  2. Sind auf Ihrem System Java-Binärdateien oder Java-basierte Anwendungen installiert?

Wenn die Antwort auf beide Fragen ein klares Nein ist, können Sie beruhigt sein – aber Sie sollten dennoch eine Überprüfung durchführen. (Quasi zur Systempflege.)

Zweitens können Sie eine oder alle der unten aufgeführten Methoden anwenden, um Ihr System zu überprüfen:
1. Prüfen Sie, ob Sie Java und/oder Apache installiert haben

$ java -version
$ apache2 -v
$ dpkg –get-selections | grep apache*

Wenn diese Befehle ein positives Ergebnis liefern, fahren Sie unten fort…

2. Suchen Sie manuell nach der Klasse Log4j. Führen Sie den folgenden Befehl als root auf dem System aus

Mit dem Befehl „find“ können Sie schnell den Pfad zur Log4j-Bibliothek ermitteln. Dieser Befehl kann sowohl auf Linux- als auch auf FreeBSD-Systemen verwendet werden.

$ find / -name „log4j*“

Durchsuchen des gesamten Dateisystems nach Log4j-Traces mit dem Befehl find .

3. Finden Sie alle Log4j-Referenzen in den Konfigurationsdateien.

Dies kann hilfreich sein, wenn Sie z.B. Ihr System nicht sofort aktualisieren können und den Aufruf von Log4j auskommentieren wollen

$ find /etc/ -type f -name „log4j*“ -exec grep –color -Hni „log4j“ {} ;

Ein betroffenes System, auf dem die javabasierte Videobridge-Software von Jitsi läuft.

4. Verwenden Sie eines der verfügbaren Scan-Skripte

Einige Entwickler haben bereits einfache Skripte geschrieben, mit denen Sie Ihr System scannen können. Eines der verfügbaren Skripte ist dieses auf Github, von Rubo77.

$ wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O – |bash

Log4Shell im Detail
Verwendung des Log4j-Checkerskripts auf einem Ubuntu-basierten System. Das Skript konnte die betroffenen Pakete aufzeigen

5. Verwenden Sie ein spezielles Open-Source-Scan- und Patch-Tool, das für die Log4shell

Es sind Log4j-spezifische Scan-Tools verfügbar. Eine davon ist das Log4j2-Scanner-Dienstprogramm von Logpresso. Dieses Dienstprogramm sucht nach anfälligem Code und bietet Ihnen die Möglichkeit, betroffene Software zu „patchen“. Vor dem Patchen erstellt das Tool eine Sicherungskopie der Dateien, die es ändern wird. Die Datei hat die Erweiterung .bak. Dies ist sehr nützlich, da Sie diese Sicherungen wiederherstellen können, falls Ihr System nach dem Patch nicht mehr funktioniert oder Instabilitäten aufweist.

Hier erfahren Sie, wie Sie den Log4j2-Scanner verwenden:

$ wget https://github.com/logpresso/CVE-2021-44228-Scanner/releases/download/v1.3.2/logpresso-log4j2-scan-1.3.2-linux.tar.gz
$ tar -xvzf logpresso-log4j2-scan-1.3.2-linux.tar.gz
$ chmod u+x ./log4j2-scan
$ ./log4j2-scan / (dies ist ein reiner Scan-Modus)
$ ./log4j2-scan –fix / (dies ist der Scan- und Fix-Modus. Sie müssen diese Aktion bestätigen)

Log4Shell im Detail
Das Log4j-Scanner-Tool von Logpresso mit den zwei möglichen Nutzungsmodi und der erstellten Sicherungsdatei.

6. Verwenden Sie ein Open-Source-Tool zum Scannen von Schwachstellen

Es gibt viele kostenlose und offene Vlunerabitity-Scan-Tools, die Ihnen bei der Diagnose Ihres Systems helfen können. Ich persönlich bevorzuge Grype und Syft. Hier erfahren Sie, wie Sie Ihr System mit Grype scannen können…

Die neueste Version von Grype finden Sie hier. Für andere Versionen passen Sie Ihre Befehle entsprechend an

$ wget https://github.com/anchore/grype/releases/download/v0.27.2/grype_0.27.2_linux_amd64.deb
$ dpkg -i grype_0.27.2_linux_amd64.deb
$ grype dir:/

Log4Shell Log4j
Grype-Scanergebnis auf einem Ubuntu-basierten System. Das System ist sauber.

Log4Shell Log4j
Grype-Scanergebnis auf einem anderen System. Die Ergebnisse zeigen anfällige Pakete und deren Schweregrad.

Korrektur des Log4j-Problems in NAKIVO Backup & Replication für Linux

Anwender müssen die Datei „JndiLookup.class“ aus der Jar-Datei „log4j-core-2.2.jar“ mit den folgenden Schritten entfernen:

  1. Navigieren Sie mit einer Terminal-Shell zum Ordner „libs“, der sich im Installationsordner von NAKIVO Backup & Replication befindet.
  2. Führen Sie den folgenden Befehl aus:
    $ zip q -d log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  3. Starten Sie NAKIVO Backup & Replication neu.

Laut NAKIVO sollte die Software danach wieder wie erwartet funktionieren.

Korrektur des Log4j-Problems in NAKIVO Backup & Replication für FreeNAS/TrueNAS

Auf FreeNAS/TrueNAS-Systemen läuft die NAKIVO-Software in einer Jail. Um das Problem zu beheben, müssen Sie sich in diese Jail einloggen und das Zip-Binary installieren. Und das geht so:

  1. Melden Sie sich in Ihrer FreeNAS/TrueNAS-GUI an, scrollen Sie nach unten und klicken Sie auf der linken Seite auf die Schaltfläche „Shell“.
  2. Geben Sie den folgenden Befehl ein, um sich in das NAKIVO-Gefängnis einzuloggen

    $ iocage Konsole nbr
  3. Installieren Sie das Zip-Binary

    $ pkg install zip (Sie müssen diesen Schritt mit Y bestätigen)
  4. Navigieren Sie in das Installationsverzeichnis und patchen Sie das betroffene JAR

    $ cd /usr/local/nakivo/director/
    $ zip -q -d log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Laut NAKIVO sollte die Software danach weiterhin wie erwartet funktionieren.

So überprüfen Sie die NASdeluxe NDL-2xxx Serie auf Log4J-Spuren

NDL2xxx
Der Screenshot wurde von einem NASdeluxe NDL-2880R mit Firmware-Version 2.06.03 aufgenommen

1. Melden Sie sich in der GUI an und aktivieren Sie den SSH-Dienst unter Netzwerkdienst > SSH
2. Verwenden Sie einen Terminal/SSH-Client, um sich als root mit der IP Ihres NASdeluxe-Systems zu verbinden. Das Passwort sollte „admin“ sein, sofern Sie es nicht geändert haben.

$ ssh root@NASDeluxe_IP

3. Führen Sie die folgenden Befehle aus, um sicherzustellen, dass Ihr System die betroffene Bibliothek oder das Java-Binary nicht enthält:

$ find / -name „log4j*“

$ find / -type f -name „log4j*“ -exec grep –color -Hni „log4j“ {} \;

$ java -version

WICHTIG: Die ersten beiden Befehle sollten eine leere Eingabeaufforderung zurückgeben, während der dritte Befehl die Fehlermeldung „java: command not found“ ausgeben sollte.

4. Um manuell zu überprüfen, welche Bibliotheken in dem installierten Apache-Verzeichnis enthalten sind, können Sie den Inhalt des Verzeichnisses /opt/apache/lib/ wie folgt auflisten;

$ ls -lah /opt/apache/lib/

Dies sollte visuell bestätigen, dass die lib4j-Bibliothek nicht vorhanden ist.

5. Beenden Sie die SSH-Shell durch Drücken von STRG + D oder geben Sie „exit“ ein und drücken Sie Enter.

6. Gehen Sie zurück zur Web-GUI und deaktivieren Sie den SSH-Dienst.
Weitere Einzelheiten und Tipps zur Überprüfung und Sicherung Ihrer Systeme finden Sie in unserer entsprechenden technischen Ankündigung

Aktualisieren Ihres Linux-basierten Systems

Die Softwareanbieter haben sich mit der Veröffentlichung von Sicherheitsupdates für diese Schwachstelle beeilt. Es ist möglich, dass für Ihr System bereits ein Update veröffentlicht wurde. Um neue Updates auf Ihrem Linux-basierten System zu prüfen und zu installieren, können Sie den folgenden Befehl ausführen:

$ apt update && apt list –upgradable

Dadurch werden alle möglichen Aktualisierungen aufgelistet. Sie können alle verfügbaren Aktualisierungen mit dem Befehl durchführen:

$ apt upgrade -y

Wenn Sie nur die betroffenen Pakete aktualisieren möchten, können Sie den Befehl verwenden:

$ apt –only-upgrade install Paket_Name

Log4Shell im Detail

Wichtiger Hinweis

Apache.org hat einen frühen Patch veröffentlicht, um die Log4Shell (Version Apache Log4j 2.15.0) zu reparieren, der sich als unvollständig erwiesen hat und unter bestimmten Betriebskonfigurationen immer noch anfällig ist. Wenn Sie den oben genannten Patch angewendet haben, ist Ihr System immer noch gefährdet. Sie müssen ein weiteres Mal auf die neueste sichere Version aktualisieren. Weitere Informationen finden Sie auf dieser Seite von Apache.org.

Gibt es weitere Maßnahmen, die wir ergreifen können, um unsere Systeme noch sicherer zu machen?

Ja, es gibt einige Dinge, die Sie tun können, um die Sicherheit Ihres Systems zu verbessern. Hier sind einige Ideen:

1. Verwenden Sie iptables-Regeln, um Verbindungen auf bekannte sichere IPs zu beschränken.

Dies ist ein RCE-Exploit (Remote Code Execution). Er beruht darauf, dass das angegriffene System in der Lage ist, bösartigen Code von einem entfernten Server abzurufen, den der Angreifer kontrolliert. Die Beschränkung der Kommunikation auf eine Liste vertrauenswürdiger IPs kann diesen Exploit aufhalten. Sie können dies tun, indem Sie ein paar Regeln zu Ihrem iptables hinzufügen. Wenn Ihre Anwendung auf einem Linux-Rechner läuft, können Sie die folgenden Befehle ausführen:

Beginnen Sie damit, Ihren aktuellen iptables-Regelsatz zu speichern:

Debian/Ubuntu

$ iptables-save > /etc/iptables/rules.v4 (dies speichert Ihren aktuellen iptables IPv4-Regelsatz)
$ ip6tables-save > /etc/iptables/rules.v6 (dies speichert Ihren aktuellen iptables IPv6-Regelsatz)

CentOS/Red Hat/Fedora

$ iptables-speichern > /etc/sysconfig/iptables
$ ip6tables-save > /etc/sysconfig/ip6tables

Wichtig: Wenn Sie diesen Server aus der Ferne verwalten, müssen Sie zunächst SSH-Verbindungen zulassen. Andernfalls werden Sie möglicherweise vom Server blockiert. Angenommen, Sie verwenden den Standard-SSH-Port, dann tun Sie das;

$ iptables -A INPUT -p tcp –dport 22 -j ACCEPT

Jetzt können Sie anfangen, Regeln hinzuzufügen:

$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
$ iptables -A INPUT -s 10.0.0.XXX/24 -j ACCEPT (Wiederholen Sie diesen Schritt für alle Ihre vertrauenswürdigen IPs. Bearbeiten Sie IP/Subnetz)
$ iptables -A INPUT -m state –state INVALID -j DROP
$ iptables -P FORWARD DROP
$ iptables -P INPUT DROP

Damit weisen Sie die in Ihrem System eingebaute Firewall an: Pakete von der Local-Loop-Adresse anzunehmen, gültige und relevante Pakete zu akzeptieren, Pakete von einer bestimmten IP zu erlauben, die Weiterleitung von Paketen an andere Systeme innerhalb und außerhalb Ihres Netzwerks zu stoppen sowie alles andere zu verwerfen.

Wenn Sie die oben genannten Regeln anwenden, überwachen Sie Ihr System/Ihre Anwendung, um sicherzustellen, dass alles wie vorgesehen mit anderen Systemen interagiert, mit denen es/sie eine Verbindung herstellen oder von denen es/sie Verbindungen annehmen soll. Ändern Sie die Regeln entsprechend. Wenn Sie Ihren vorherigen Regelsatz wiederherstellen müssen, tun Sie das;

Debian/Ubuntu

$ iptables /sbin/iptables-restore < /etc/iptables/rules.v4
$ ip6tables-restore < /etc/iptables/rules.v6

CentOS/Red Hat/Fedora

$ iptables-restore < /etc/sysconfig/iptables
$ ip6tables-restore < /etc/sysconfig/ip6tables

2. Beschränken Sie den Zugriff nur auf die erforderlichen Ports

Auch hier gilt, dass der Exploit über einen einzigen offenen Port kommunizieren muss. Wenn Sie alle Ports abschalten, außer denen, die Ihr Server unbedingt benötigt, haben Sie eine bessere Chance, nicht kompromittiert zu werden. Wenn Sie davon ausgehen, dass Ihr System nur die Ports 80/TCP und 443/TCP benötigt, um zu funktionieren, können Sie wie folgt vorgehen:

$ -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
$ -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

3. Sichern Sie Ihre JVM

Der Exploit beruht auch auf einer lockeren Konfiguration Ihrer Java-Umgebung. Sie können die Java-Eigenschaft ändern, die für die JNDI-URL-Lookups von log4j verantwortlich ist. Hier wird empfohlen, die Eigenschaft auf „false“ zu setzen.

com.sun.jndi.ldap.object.trustURLCodebase = false

Sie sollten auch den Konfigurationswert log4j2.formatMsgNoLookups auf true setzen. Dadurch werden die LDAP-Abfragen deaktiviert.

4. Verwendung von NGINX mit ModSecurity WAF und LUA-Skripten

Dies ist eine radikalere und aufwändigere Lösung. Aber der Sicherheits- und Leistungsgewinn könnte sich auf lange Sicht tatsächlich lohnen.

NGINX ist ein beliebter, schneller und leichtgewichtiger Open-Source-Webserver. NGINX ist nicht anfällig für den Log4Shell-Exploit, da er vollständig in C geschrieben ist und weder Java noch Java-basierte Bibliotheken verwendet. ModSecurity ist ein Open Source Web Application Firewall (WAF) Modul, das für NGINX und andere Webserver verfügbar ist. Es verwendet eine Reihe von generischen Angriffserkennungsregeln, die Core Rule Set (CSR) genannt werden, um Webanwendungen vor einer Vielzahl von Angriffen zu schützen, mit einem Minimum an Fehlalarmen.

Es gibt auch einige nützliche LUA-Skripte, die die Widerstandsfähigkeit von NGINX gegen solche Angriffe verbessern können. LUA-Skripte erfordern das NGINX-Modul. Die Experten von Infiniroot Hosting haben ihre nützlichen LUA-Skripte auf dieser Github-Seite veröffentlicht, begleitet von diesem ausgezeichneten Blogbeitrag.

Die Umstellung auf NGINX könnte allerdings eine Weile dauern, da die Konfigurationen von Websites zwischen Apache und NGINX nicht kompatibel sind. Es könnte sinnvoll sein, zunächst mit einem lokalen Testserver zu experimentieren, um sicherzustellen, dass Ihre Website/Anwendung mit NGINX reibungslos läuft.

Starline Kontakt

Noch Fragen? Kontaktieren Sie uns.

Der ausgewiesene Experte für alle Linux- und Ceph-Plattformen kam 2018 zu Starline. Seine Vorliebe gilt raffinierten Open-Source-Lösungen und kniffligen Produktentwicklungen. Deshalb steht er auch für Anfragen bezüglich PetaSAN und TrueNAS (ehemals FreeNAS) bereit. Aber auch ARM-Server von Ambedded oder Mac-Betriebssysteme haben es ihm angetan. Privat befasst sich der Ingenieur gern mit 3D-Druckern und Robotern.

Mohammad Ammar
Technik