• Home
  • News
  • Log4SHELL Angriff: LOG4j 2.x CVE-2021-44228 – Was ist zu tun?

Asian male hacker use laptop © stock.adobe.com/# 439482203 

Log4SHELL Angriff: LOG4j 2.x CVE-2021-44228 – Was ist zu tun?

Von Florian Oelmaier, Corporate Trust

Sie haben sicherlich schon von der Log4j Lücke gehört. Ich spare mir jetzt auch die Detailbeschreibungen, das Internet ist voll davon. Ein paar Hinweise für die Verteidiger (IT-Admins und CISO Organisationen) kommen aus unserer Sicht aber zu kurz:

Ein Scan von außen auf diese Schwachstelle ist kaum möglich – die Angriffsfläche ist zu riesig. Jeder Test von außen kann nur zeigen, dass die Schwachstelle da ist, Ihnen aber keine zuverlässige Antwort liefern, dass sie nicht vorhanden ist. Es gibt mittlerweile eine gute Liste von Kauf-Komponenten, die betroffen sind: https://github.com/authomize/log4j-log4shell-affected - Wichtig: es ist aber auch eine ganze Menge an Individualsoftware betroffen. Der Fehler kann auch von intern gut und einfach ausgenutzt werden. Auch ein Durchtunneln nach intern ist denkbar. Die Schwachstelle muss also nicht nur in Ihren DMZ bzw. Internet-facing Systemen gefixed werden (auch wenn die sicherlich Priorität haben) sondern in Ihrer gesamten Infrastruktur. Log4j 2.0 kam im Juli 2014 aus der Betaphase. Log4j 1.x hatte im August 2015 sein End-of-Life. Nur Log4j > 2.0 hat den Fehler. D.h. Individualsoftware die Sie seit 2014 ohne Updates betreiben ist mit großer Wahrscheinlichkeit von diesem Fehler nicht betroffen (sie sollten sich aber dennoch dafür angemessen schämen). Der Fehler ist normalerweise in einer Datei mit dem Namen log4j*.jar. Dieses Framework kann aber auch tiefer eingebaut sein oder unter anderem Namen vorhanden sein. Wichtig: ".jar" Dateien sind normale ZIP Dateien und können mit einem ZIP-Tool (wie 7z oder ähnlichem) bearbeitet werden.

Um den Fehler zu beseitigen, gibt es mehrere Wege:

Der ideale Weg ist sicherlich das updaten des log4j Frameworks. Dort gibt es dann Settings, um die Schwachstelle zu neutralisieren (allowedJndiProtocols, allowedLdapHosts, allowedLdapClasses). Das greift aber in den Programmcode ein und muss vom Programmhersteller erledigt werden (vor allem weil die Konfiguration von log4j an vielen Stellen passieren kann). Insbesondere bei Individualsoftware ist dies oft langwierig. Unsere Empfehlung: stoßen Sie den Updateprozess an, warten Sie aber nicht darauf. Sowohl Oracle JDK als auch OpenJDK haben seit 2019 eine Einstellung das die Ausnutzung verhindert: Wenn com.sun.jndi.rmi.object.trustURLCodebase auf "false" steht, kann die Schwachstelle nicht genutzt werden. Da es viele Wege gibt, dieses Setting umzustellen (unter anderem in Aufrufskripten und im Programmcode selbst) ist es kaum möglich herauszufinden, ob diese Einstellung durchgehend wirksam ist. Die gute Nachricht: die verwundbare Funktion wird häufig nicht gebraucht. Der verwundbare Code findet sich in der Datei JndiLookup.class (oder .java). Wenn sie "nur" der Administrator und nicht der Programmierer sind, empfehlen wir Ihnen, auf allen Rechnern in allen Verzeichnissen und in allen ".jar"-Dateien (siehe oben, das sind "nur" ZIP-Dateien) nach einer Datei JndiLookup.* zu suchen. Wenn Sie diese auf einem Server NICHT finden, dann können Sie mit >98% Sicherheit sagen, dass dieser Server auch nicht betroffen ist.

Unter Linux könnten Sie diese Suche z.B. so machen:

#> find / -name JndiLookup.* 2> /dev/null

#> find / -name *.jar -exec unzip -l \{\} 2> /dev/null | fgrep JndiLookup

Wenn diese beiden Befehle keine Ergebnisse liefern, dann wurde der verwundbare Code nicht gefunden.

Unter Windows können Sie dies analog mit Powershell erledigen.

Wenn Sie eine Datei mit dem Namen JndiLookup finden, prüfen Sie als nächstes ob dieser Teil eines log4j Frameworks ist (das erkennen Sie schnell an den "import"-Befehlen in der Datei). Wenn ja, löschen Sie diese Datei einfach aus der .jar-Datei (z.B. mit 7z) oder dem Dateisystem (ja bitte, machen Sie vorher eine Sicherungskopie - aber passen Sie auf, dass die nicht aufgerufen werden kann). Dann testen Sie die Anwendung nochmal kurz durch - maximal sollte es aber ein paar kleinere Probleme bei der Logausgabe geben.

Weitere Ressource für die Verteidigerseite finden Sie hier:

  https://github.com/curated-intel/Log4Shell-IOCs

  https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

 

Kontakt

VEKO GmbH

Im Spatzennest 5
73113 Ottenbach
Deutschland

Tel.: +49 7165 9490255
E-Mail: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Copyright © 2022 VEKO Online. Alle Rechte vorbehalten.