Wir befinden uns mitten im Dezember 2021, kurz vor dem Ende des Kalenderjahres, und die log4j-Schwachstelle steht ganz oben auf der To-Do-Liste eines jeden Unternehmens, vor allem wenn es Anwendungen hat, die mit dem Internet kommunizieren.

In diesem Beitrag soll der Log4Shell-Fehler in verständlichen Worten beschrieben werden und wie Sie unser Team um Hilfe bitten können.

‍

Zusammenfassung:

1. Log4Shell muss ernst genommen werden.

2. Die Sicherheitslücke in log4j, die als "Log4Shell" bezeichnet wird, ist offiziell NIST CVE-2021-44228.

3. Ausführliche Aktualisierungen finden Sie in der Github-Beratung hier.

4. Ein RASP-Tool (Runtime Application Self-Protection) hilft Ihnen, sich während der Abhilfemaßnahmen zu schützen. AppDynamics-Kunden können Cisco Secure Application für sofortigen Schutz während der Behebung nutzen.

5. Unternehmen brauchen eine Plattform wie Lacework, die ganzheitliche Sicherheitstransparenz in der Cloud bietet.

6. Sobald die Log4Shell-Schwachstelle behoben ist, sollten Unternehmen ihre DevOps-Infrastruktur und -Richtlinien überprüfen und sicherstellen, dass sie für eine schnelle und entschlossene Reaktion auf diese Bedrohungen gerüstet sind.

‍

Betroffene Apache Log4j-Versionen: 2.0 bis 2.14.1

Schweregrad: Kritisch (10.0 insgesamt NIST CVSS)

NISTs offizielle Auflistung: CVE-2021-44228

TALOS-Bedrohungshinweis: CVE-2021-44228

Apache's Anleitung zur Behebung: Ferngesteuerte Code-Einschleusung in Log4j

‍

Die Grundlagen: Was ist Log4Shell?

Breiterer Kontext

Die Apache Log4j-Sicherheitslücke, Log4Shell genannt, weist Ähnlichkeiten mit der SolarWinds-Sicherheitslücke auf. Natürlich sind sie unterschiedlich, aber es sind zwei sehr ähnliche Situationen. Und warum? SolarWinds und Log4Shell sind beides Sicherheitslücken in der Software-Lieferkette. Bei der SUNBURST-Schwachstelle (die zu dem SolarWinds-Vorfall führte) handelte es sich um eine böswillige Einbindung (einen Angriff) in eine DLL, und bei der Log4Shell-Schwachstelle wird derzeit davon ausgegangen, dass es sich um eine versehentliche Einbindung in die log4j-Bibliothek handelt, aber beide sind Schwachstellen in der Software-Lieferkette.

‍

Was ist eine "Schwachstelle in der Software-Lieferkette"?

In allen Anwendungen sind Code-Bibliotheken versteckt, die der Anwendungsentwickler nicht geschrieben und nicht persönlich überprüft hat. Sie sind allgegenwärtig. Bei diesen Bibliotheken handelt es sich um kleine (manchmal auch nicht ganz so kleine) Bündel von vorformuliertem Code, die eine bestimmte Funktion oder eine Reihe von Funktionen ausführen.

Entwickler verwenden öffentliche Code-Bibliotheken, um das Rad nicht neu zu erfinden. Oder in diesem Fall, um ein Java-Protokollierungs-Framework nicht neu zu erfinden. Entwickler nutzen Bibliotheken wie log4j, weil sich die Bibliotheken als robuste, leistungsfähige und zuverlässige Lösungen für gängige Softwareaufgaben bewährt haben.

Eine Schwachstelle in der Software-Lieferkette liegt also vor, wenn eine Code-Bibliothek weiter oben in der Lieferkette der Anwendung kompromittiert wird.

‍

Wie kommt es zu Schwachstellen in der Software-Lieferkette?

Probleme treten auf, wenn in Software-Bibliotheken eine Sicherheitslücke gefunden wird. Unabhängig davon, ob eine Schwachstelle böswillig oder versehentlich in den Bibliothekscode gelangt, sind Sie gefährdet, wenn Sie die Bibliothek verwenden. Software- und Sicherheitsingenieure können sich nicht völlig vor der Gefahr von Schwachstellen in Abhängigkeiten schützen. Teams könnten strenge Prüfungen durchführen oder versuchen, die Verwendung externer Bibliotheken ganz zu vermeiden, aber diese Optionen sind in der Regel wirtschaftlich nicht machbar.

Es besteht nicht nur die Gefahr, dass Schwachstellen in bereits vorhandenem Code gefunden werden, sondern auch, dass in Zukunft neuer anfälliger Code veröffentlicht wird. Diese Bibliotheken werden ständig aktualisiert. Mit den Aktualisierungen werden Fehler behoben und Sicherheitslücken geschlossen, worüber wir uns alle freuen, aber es werden auch neue Funktionen hinzugefügt. Diese neuen Funktionen stellen eine ständig wachsende Angriffsfläche für unsere Anwendungen dar. Ein Entwicklungsteam könnte beschließen, seine Abhängigkeiten an eine bestimmte Version zu binden, die nur die Funktionen enthält, die es braucht, aber dann verpasst es Fehlerbehebungen und Sicherheitspatches. Im schlimmsten Fall können Schwachstellen böswillig hinzugefügt werden, was einen Angriff auf die Software-Lieferkette darstellen würde.

‍

Was ist Log4Shell im Einzelnen?

Log4Shell, offiziell CVE-2021-44228, ist eine Schwachstelle für Remote Code Execution (RCE) in einem allgegenwärtigen Java Logging Framework, log4j (v2).

‍

Es gibt drei Faktoren, die Log4Shell so gefährlich machen:

1. Die anfällige Bibliothek log4j ist weit verbreitet.

2. Die Sicherheitslücke ist erschreckend einfach auszunutzen.

3. Die Ausnutzung gibt Angreifern die Möglichkeit, beliebigen Code aus der Ferne auszuführen.

‍

Die anfällige Bibliothek log4j ist weit verbreitet: Log4J2 existiert als Bibliothek seit 2001 und ist damit fast 21 Jahre alt. Zum Zeitpunkt der Erstellung dieses Artikels hat sie knapp 11.500 Commits in ihrem Git-Repository (https://github.com/apache/logging-log4j2), und sie ist völlig frei verwendbar, lizenziert von der gemeinnützigen Apache Foundation. Entwickler könnten versuchen, die 21 Jahre andauernde Arbeit zu replizieren, oder sie könnten diese kostenlose, leicht verfügbare Bibliothek verwenden, die bereits vertraut ist und fast überall verwendet wird.

‍

Die Log4Shell-Schwachstelle ist unglaublich einfach auszunutzen: Sie müssen nur in der Lage sein, eine anfällige Anwendung dazu zu bringen, etwas Ihrer Wahl zu protokollieren.

Das ist viel einfacher, als es klingt. Nehmen wir an, ein Benutzer geht zu einem Online-Geschäft. Er versucht, sich anzumelden, und die Webapp protokolliert seinen Versuch. Der Benutzername wird zusammen mit dem Datum, an dem der Versuch unternommen wurde, aufgezeichnet, ebenso, ob der Versuch erfolgreich war oder nicht, usw. Wenn der Benutzer also ein Angreifer ist und eine bösartige Zeichenfolge in das Feld für den Benutzernamen eingibt, wird dies protokolliert. Die Website muss nicht einmal eine Option zur Anmeldung haben. Wenn ein Benutzer zu einer Seite navigiert, wird sein Besuch protokolliert. Oft wird auch der User-Agent-Bezeichner des Browsers protokolliert. Ein Angreifer kann diesen Benutzer-Agenten mit einer Zeichenfolge seiner Wahl fälschen, und die Anwendung protokolliert dann diese eigene Zeichenfolge.

Die Protokollierung der benutzerdefinierten Zeichenfolge eines Angreifers wäre an sich nicht problematisch. Das Problem liegt in einer der vielen Funktionen von log4j: der Substitution von Nachrichten durch Lookups. Wenn Message Lookups aktiviert sind, geben Lookups log4j die Möglichkeit, Daten durch die Durchführung von Lookups gegen Urls in der protokollierten Nachricht anzureichern.

‍

Jetzt können Angreifer beliebigen Code aus der Ferne ausführen: Ein Angreifer hostet eine URL, die bösartigen Code enthält, und zwingt eine Anwendung, auf der log4j läuft, diesen zu protokollieren. Nach der Protokollierung führt log4j einen Lookup durch und stellt eine Verbindung zu dieser URL her, lädt den bösartigen Code herunter und führt ihn aus. Der bösartige Code nutzt die Log4Shell-Schwachstelle aus und injiziert eine zweite Stufe des Angriffs in die jvm. Die zweite Stufe ermöglicht es dem Angreifer dann, seinen eigenen Code aus der Ferne auszuführen. Dies ist eine vereinfachte Version des vollständigen Verfahrens, das Talos Intelligence hier beschreibt:(https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html).

‍

Welche Maßnahmen sollte ich ergreifen?

Nach meiner Erfahrung mit Log4Shell in den letzten Tagen war diese Seite die zuverlässigste Quelle für präzise und genaue Informationen:

Github CVE-2021-44228 Hinweis

‍

Unmittelbar zu ergreifende Maßnahmen sind:

- Wenn Sie einen RASP verwenden, stellen Sie sicher, dass er so konfiguriert ist, dass er Angriffe auf diese Sicherheitslücke blockiert.

- Machen Sie eine Bestandsaufnahme, wo Ihre eigenen Anwendungen durch Schwachstellen-Scans oder andere Methoden anfällig sind.

- Machen Sie eine Bestandsaufnahme Ihrer Software von Drittanbietern und überprüfen Sie deren Hinweise.

- Korrigieren Sie Ihre Anwendungen, indem Sie alle verwendeten log4j-Bibliotheken auf >=2.16.0 aktualisieren.

- Bereinigen Sie die Software von Drittanbietern, indem Sie die Anweisungen in den Hinweisen Ihrer Anbieter befolgen.

- Verfolgen Sie mögliche Bedrohungen intern. Die Geschwindigkeit, mit der Log4Shell von Angreifern ausgenutzt wurde, bedeutet, dass es selbst dann, wenn ein Unternehmen alles richtig gemacht hat, zu einem Einbruch gekommen sein könnte.

‍

Wie kann Evolutio helfen?

Unternehmen werden die Log4Shell-Schwachstelle nicht über Nacht, in dieser Woche oder gar in diesem Monat vollständig beheben. Sicherheits-, DevOps-, Infrastruktur- und IT-Führungsteams müssen sowohl kurz- als auch langfristig zusammenarbeiten.

Sicherheits- und Technologie-Teams brauchen Möglichkeiten, komplexe Unternehmensplattformen transparent, einfach und benutzerfreundlich zu gestalten, um die digitale Transformation voranzutreiben und Schwachstellen schnell zu beheben, ohne dass dies zu einer Kaskade von IT-Kopfschmerzen führt.

Wir können Beratungsgespräche mit unseren Experten anbieten, um zu überprüfen, ob unsere Kunden die Schwachstellen richtig angehen. In der Regel können wir bei der Identifizierung von anfälligen Anwendungen und Komponenten innerhalb der Kundenlandschaft durch automatisches Scannen helfen. Es gibt verschiedene Möglichkeiten, wie wir bei der eigentlichen Schadensbegrenzung helfen können, insbesondere in komplexeren Szenarien. Und schließlich können wir Ratschläge geben, wie die Systeme in Zukunft geschützt werden können, einschließlich Vorschlägen zu Tools und Risikomanagement.

‍

Schlussfolgerung

Zusammenfassend lässt sich sagen, dass Log4Shell eine ernsthafte Bedrohung darstellt, aber wahrscheinlich nicht die letzte Bedrohung dieser Art sein wird, der Sicherheitsteams begegnen. Es ist wichtig, auch in Zukunft auf diese Art von Bedrohungen vorbereitet zu sein, denn wir werden noch mehr von ihnen sehen. So beängstigend diese Bedrohungen auch sein mögen, moderne Tools (wie Cisco Secure Application) sind gut gerüstet, um Sie zu schützen und Transparenz zu schaffen. Vorausschauende Sicherheitsexperten sollten dieses Tooling und diese Governance vor der nächsten Schwachstelle implementieren, und Evolutio kann dabei helfen.

Wenn Sie mehr erfahren möchten, folgen Sie dem Formular "Kontakt " und wir können ein Gespräch führen.