Log4Shell – Kritische Schwachstelle in Standardsoftware

Log4j - kritischer Sicherheitsfehler

 

Beliebte Angriffsarten auf Server sind das Versenden von HTTP-Anfragen mit der bösartigen Zeichenkette innerhalb der URL oder in HTTP-Headern, wie zum Beispiel als „User-Agent“ [1]. Eine weitere Möglichkeit wäre das Eingeben der bösartigen Zeichenkette in eine Login-Maske, da häufig aus Sicherheitsgründen auch fehlgeschlagene Anmeldeversuche protokolliert werden. Bei Minecraft Servern reicht es bereits aus, wenn über einen verbundenen Client eine Chatnachricht verschickt wird, um auf der Serverseite Schadcode auszuführen.

Da sich Log4Shell sehr einfach ausnutzen lässt, wird allen Betreibern von Software, welche intern Log4j verwendet, zu einem Update geraten. Alle aktuellen Versionen von Log4j in der Version 2 bis zu 2.14.1 sind verwundbar [4]. Das vor der Bekanntmachung der Sicherheitslücke veröffentlichte Update auf Version 2.15.0 konnte jedoch nicht sämtliche Schwachstellen beseitigen [1]. Nur durch ein Update auf Version 2.16.0 oder höher lässt sich Log4Shell beheben [4]. 

Sollte kein Update möglich sein, muss die Klasse JndiLookup aus dem Java-Classpath entfernt werden, um die betroffene Funktionalität in Log4j vollständig zu deaktivieren. Es existieren zudem bereits Lösungen, welche die Schwachstelle innerhalb der laufenden Software beheben, ohne dass ein Neustart durchgeführt werden muss. Eine solche Lösung ist zum Beispiel das von Amazon entwickelte Tool Log4jHotPatch [5].

Die Log4Shell Schwachstelle verdeutlicht, wie wichtig es in Zeiten der Digitalisierung für Unternehmen ist, über die eigenen Hardware- und Software-Assets Bescheid zu wissen. Ein lückenloses Inventar aller verwendeten Assets inklusive der sog. „nested components“, also der verwendeten Komponenten wie z.B. Software-Bibliotheken, ermöglicht es von Schwachstellen betroffene Systeme (wie hier die Bibliothek Log4j) schnellstmöglich zu identifizieren. Das Asset-Management sollte dabei in einen übergeordneten Patch-Management-Prozess eingebunden sein, welches dafür sorgt, dass die Risiken identifizierter Schwachstellen entweder durch Hersteller-Patches beseitigt oder zumindest durch virtuelle Patches (z.B. Web Application Firewalls oder andere kompensierende Maßnahmen) auf ein akzeptables Niveau gesenkt werden.

Beliebte Angriffsarten

 

Beliebte Angriffsarten auf Server sind das Versenden von HTTP-Anfragen mit der bösartigen Zeichenkette innerhalb der URL oder in HTTP-Headern, wie zum Beispiel als „User-Agent“ [1]. Eine weitere Möglichkeit wäre das Eingeben der bösartigen Zeichenkette in eine Login-Maske, da häufig aus Sicherheitsgründen auch fehlgeschlagene Anmeldeversuche protokolliert werden. Bei Minecraft Servern reicht es bereits aus, wenn über einen verbundenen Client eine Chatnachricht verschickt wird, um auf der Serverseite Schadcode auszuführen.

Da sich Log4Shell sehr einfach ausnutzen lässt, wird allen Betreibern von Software, welche intern Log4j verwendet, zu einem Update geraten. Alle aktuellen Versionen von Log4j in der Version 2 bis zu 2.14.1 sind verwundbar [4]. Das vor der Bekanntmachung der Sicherheitslücke veröffentlichte Update auf Version 2.15.0 konnte jedoch nicht sämtliche Schwachstellen beseitigen [1]. Nur durch ein Update auf Version 2.16.0 oder höher lässt sich Log4Shell beheben [4]. 

Sollte kein Update möglich sein, muss die Klasse JndiLookup aus dem Java-Classpath entfernt werden, um die betroffene Funktionalität in Log4j vollständig zu deaktivieren. Es existieren zudem bereits Lösungen, welche die Schwachstelle innerhalb der laufenden Software beheben, ohne dass ein Neustart durchgeführt werden muss. Eine solche Lösung ist zum Beispiel das von Amazon entwickelte Tool Log4jHotPatch [5].

Die Log4Shell Schwachstelle verdeutlicht, wie wichtig es in Zeiten der Digitalisierung für Unternehmen ist, über die eigenen Hardware- und Software-Assets Bescheid zu wissen. Ein lückenloses Inventar aller verwendeten Assets inklusive der sog. „nested components“, also der verwendeten Komponenten wie z.B. Software-Bibliotheken, ermöglicht es von Schwachstellen betroffene Systeme (wie hier die Bibliothek Log4j) schnellstmöglich zu identifizieren. Das Asset-Management sollte dabei in einen übergeordneten Patch-Management-Prozess eingebunden sein, welches dafür sorgt, dass die Risiken identifizierter Schwachstellen entweder durch Hersteller-Patches beseitigt oder zumindest durch virtuelle Patches (z.B. Web Application Firewalls oder andere kompensierende Maßnahmen) auf ein akzeptables Niveau gesenkt werden.

Fazit

 

Die Log4Shell Schwachstelle verdeutlicht, wie wichtig es in Zeiten der Digitalisierung für Unternehmen ist, über die eigenen Hardware- und Software-Assets Bescheid zu wissen. Ein lückenloses Inventar aller verwendeten Assets inklusive der sog. „nested components“, also der verwendeten Komponenten wie z.B. Software-Bibliotheken, ermöglicht es von Schwachstellen betroffene Systeme (wie hier die Bibliothek Log4j) schnellstmöglich zu identifizieren. Das Asset-Management sollte dabei in einen übergeordneten Patch-Management-Prozess eingebunden sein, welches dafür sorgt, dass die Risiken identifizierter Schwachstellen entweder durch Hersteller-Patches beseitigt oder zumindest durch virtuelle Patches (z.B. Web Application Firewalls oder andere kompensierende Maßnahmen) auf ein akzeptables Niveau gesenkt werden.

Autoren:

Prof. Dr. Bodo Kraft ist Informatiker und beschäftigt sich mit agiler, qualitätsgetriebener Vorgehensweise zur Entwicklung wartbarer Softwaresysteme für das betriebliche Umfeld.

Prof. Dr. Marko Schuba ist Informatiker und beschäftigt sich insbesondere mit Industrial Cybersecurity.

Hendrik Karwanni M. Sc. ist Informatiker und Mitarbeiter im Labor Business Programming von Prof. Kraft. Er ist Experte für den Bereich Software-Entwicklung, speziell im Umfeld Java, Spring und Web.

 

[1] Wikipedia contributors, „Log4Shell,“ [Online]. Available: https://en.wikipedia.org/wiki/Log4Shell. [Zugriff am 17 Dezember 2021].

[2] I. Turunen, „Log4shell by the numbers- Why did CVE-2021-44228 set the Internet on Fire?,“ sonatype, 14 Dezenmber 2021. [Online]. Available: https://blog.sonatype.com/why-did-log4shell-set-the-internet-on-fire. [Zugriff am 17 Dezember 2021].

[3] „Recently uncovered software flaw ‘most critical vulnerability of the last decade’,“ 11 Dezember 2021. [Online]. Available: https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell. [Zugriff am 16 Dezember 2021].

[4] B. Vermeer, „Log4j vulnerability explained: Prevent Log4Shell RCE by updating to version 2.16.0,“ snyk.io, 10 Dezember 2021. [Online]. Available: https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/. [Zugriff am 17 Dezember 2021].

[5] „Log4jHotPatch,“ GitHub, 12 Dezember 2021. [Online]. Available: https://github.com/corretto/hotpatch-for-apache-log4j2. [Zugriff am 17 Dezember 2021].

Weitere Fachbeiträge rund ums Thema Digitale Transformation

Registrieren sie sich jetzt KOSTENLOS um von folgenden Vorteilen zu profitieren:

Newsletter

iDA Shop