{"id":29588,"date":"2022-12-16T10:39:28","date_gmt":"2022-12-16T08:39:28","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=29588"},"modified":"2022-12-16T10:39:28","modified_gmt":"2022-12-16T08:39:28","slug":"log4shell-still-active-2022","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/log4shell-still-active-2022\/29588\/","title":{"rendered":"Ein Jahr nach Log4Shell"},"content":{"rendered":"

Vor einem Jahr, im Dezember 2021, sorgte die Log4Shell-Schwachstelle (CVE-2021-44228) in der Apache Log4j-Bibliothek f\u00fcr Aufsehen. Obwohl Sie im Fr\u00fchling schon nicht mehr auf den Titelseiten der IT-Medien zu finden war, feierte sie im November 2022 ein Comeback, als davon berichtet wurde, dass Cyberkriminelle die Sicherheitsl\u00fccke erneut ausgenutzt hatten<\/a>, um die US-Bundesbeh\u00f6rde anzugreifen und einen Kryptow\u00e4hrungs-Miner auf deren Systemen zu installieren. F\u00fcr uns ist dies der ideale Anlass, um zu erkl\u00e4ren, was Log4Shell eigentlich ist, warum es zu fr\u00fch ist, die Schwachstelle abzuschreiben, und wie Sie Ihre Infrastruktur sch\u00fctzen k\u00f6nnen.<\/p>\n

<\/h2>\n

Was ist die Apache Log4j-Bibliothek?<\/h2>\n

Weil das Java SDK keine Protokollierung unterst\u00fctzte, sahen sich Entwickler anfangs dazu gezwungen, ihre eigenen L\u00f6sungen zu schreiben; als die offizielle Java Logging API erschien, gab es bereits eine ganze Reihe solcher L\u00f6sungen. Eine davon ist Apache Log4j, eine beliebte Open-Source-Java-Bibliothek, die seit 2001 entwickelt wird. Sie ist zwar nicht die einzige Protokollierungs-L\u00f6sung in Java, aber sicherlich eine der beliebtesten. Viele Alternativl\u00f6sungen sind im Wesentlichen Ableger von Log4j, die in verschiedenen Phasen der Entwicklung der Bibliothek entstanden sind.<\/p>\n

\u00a0<\/p>\n

Was ist die Log4Shell-Schwachstelle?<\/h2>\n

Mithilfe der Log4j-Bibliothek k\u00f6nnen alle Systemereignisse automatisch protokolliert werden. Sie nutzt eine Reihe standardm\u00e4\u00dfiger Schnittstellen, um auf Daten der Java Naming and Directory Interface (JNDI) zugreifen zu k\u00f6nnen. Im November 2021 stellte sich heraus, dass die Bibliothek w\u00e4hrend der Protokollierung in der Lage ist, JNDI-Befehle auszuf\u00fchren, die ihr von einem Ereignis \u00fcbergeben werden, z. B. im Header-Feld einer Anfrage, in einer Chat-Nachricht oder in der Beschreibung eines 404-Fehlers auf einer Webseite.<\/p>\n

Welchen Schaden kann die Schwachstelle Log4Shell anrichten und warum ist sie auch im Jahr 2022 noch gef\u00e4hrlich? #ITSecurity<\/p>Tweet<\/a><\/blockquote>\n

Die Schwachstelle gibt Cyberkriminellen die M\u00f6glichkeit<\/a>, auf dem System des Opfers das zu tun, was sie wollen. Zumindest theoretisch und sofern keine zus\u00e4tzlichen Sicherheitsma\u00dfnahmen greifen. In der Praxis nutzten Angreifer Log4Shell jedoch haupts\u00e4chlich, um illegale Miner zu installieren und Ransomware-Angriffe durchzuf\u00fchren. Nat\u00fcrlich gab es auch exotischere Einsatzgebiete<\/a>, darunter zielgerichtete Angriffe, die Verbreitung des Mirai-Botnets und Rickrolling. Letzteres lotst Nutzer auf ein Videoportal, und spielt den (\u00e4rgerlich s\u00fcchtig machenden) Hit \u201eNever Gonna Give You Up\u201c des 80er-Jahre-S\u00e4ngers Rick Astley in Dauerschleife ab.<\/p>\n

\u00a0<\/p>\n

Warum ist die Schwachstelle so gef\u00e4hrlich und noch immer eine Bedrohung?<\/h2>\n

Java z\u00e4hlt zu einer der prim\u00e4ren Programmiersprachen und wird f\u00fcr viele Backend-Systeme genutzt: Von kleinen Unternehmensservern bis hin zu industriellen Automatisierung-Systemen und IoT-Ger\u00e4ten. Die meisten dieser Systeme implementieren die Protokollierung auf die eine oder andere Weise. Jahrelang war daf\u00fcr der Einsatz der Log4j-Bibliothek am einfachsten. Als im Dezember 2021 bekannt wurde, dass sie eine Sicherheitsl\u00fccke enth\u00e4lt, erkl\u00e4rten Experten, dass dies noch viele Jahre lang ein gro\u00dfes Problem darstellen w\u00fcrde<\/a>. Hier ist der Grund:<\/p>\n