ein Mitglied der Elefantengruppe

über den Unternehmenszweck hinaus

Verstehen der Log4j-Schwachstelle

RSVP jetztRSVP jetzt
1. November 2021
10:30 UHR
1. November 2021
10:30 UHR

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.

Helfende Hand oder Zweitmeinung

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.

Kurzfristig

Helfende Hand oder Zweitmeinung

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.

Cisco Sichere Anwendung

Cisco Secure Application ist ein RASP-Tool (Runtime Application Self Protection), das zusammen mit AppDynamics entwickelt wurde. Von den verfügbaren RASP-Tools ist Cisco Secure Application das am einfachsten zu implementierende und zu verwendende Tool, das mir je begegnet ist.

Es ist in alle AppDynamics-Agenten ab Version 21.3 integriert. Es automatisiert die Behebung nicht für Sie, aber es kann Ihnen dabei helfen, festzustellen, wo Sie für Log4Shell anfällig sind, und bietet Schutz, während Sie die Behebung durchführen. Da es in den AppDynamics Agent integriert ist, ist nichts schneller als das Hinzufügen von Secure Application, wenn Sie bereits ein AppDynamics-Benutzer sind. Sie können es in nur einem Tag aktivieren und Ihre Anwendungen aktiv schützen.

Secure Application spürt Schwachstellen auf, indem es sich die geladenen Bibliotheken der Anwendung ansieht. Es kann die anfällige Bibliothek erkennen und die Ausführungen sehen, die den anfälligen Codepfad verwenden. Es ist dann in der Lage, Exploits zu erkennen, die gegen diesen (und andere) anfällige Codepfade laufen, und Sie darauf aufmerksam zu machen. Optional kann es auch so konfiguriert werden, dass es die Ausführung dieses Exploits blockiert.

Wenn Sie Agenten der Version 21.3 oder höher einsetzen, kann Secure Application ohne zusätzliche Installation aktiviert werden. Die Log4Shell-Schwachstelle und Exploits gegen diese Schwachstelle werden automatisch erkannt. Die einzige Konfiguration besteht darin, Anwendungen zu aktivieren und dann das automatische Blockieren des Exploits zu konfigurieren, falls gewünscht.

Sehen Sie diesen Blog-Beitrag über Cisco Secure Application in Aktion

Cloud-Konten absichern | Lacework

Wie Secure Application kann auch die Erkennung von Schwachstellen in Runtime-Containern von Lacework Ihnen helfen, herauszufinden, wo in Ihrer Umgebung Sie für diese Art von Bedrohung anfällig sind. Über Secure Application hinaus kann Lacework Ihnen helfen, auf Host-Ebene jede Instanz einer anfälligen Bibliothek in Ihren Cloud-Konten zu erkennen.

Darüber hinaus hilft Ihnen das Container-Scanning von Lacework, diese Schwachstellen in Ihrer Software zu erkennen, bevor sie eingesetzt wird. Dies ist besonders hilfreich, weil Sie so vermeiden können, jemals wieder zu einer anfälligen Version zurückzukehren.

Lacework glänzt aber vor allem durch seinen ganzheitlichen Ansatz für Cloud-Sicherheit. Mit der branchenführenden Anomalieerkennung von Lacework können Sie Bedrohungen, die sich erfolgreich Zugang zu Ihrer Umgebung verschafft haben, schnell erkennen.

Lacework-Analyse der Log4Shell-Angreifer ansehen

Mit einer anfänglichen Bereitstellungszeit von nur einer Woche können Sie mit Lacework schnell von einer blinden zu einer vollständigen Cloud-Transparenz übergehen.

Langfristig

Patchen und Bereitstellen von Updates | Harness

Längerfristig sollten Sie unbedingt dafür sorgen, dass Ihr Entwicklungsteam über einen Mechanismus für die schnelle Bereitstellung von Patches und Software-Updates verfügt.

Harness ermöglicht es Kunden, komplexe moderne DevOps-Umgebungen zu vereinfachen. Die erfolgreiche Strategie ist dreifach: schnellere Markteinführung, automatisierte Cloud-Optimierung und die Befähigung von Entwicklern, die Sicherheit in den Vordergrund zu stellen. Harness sorgt für Governance bei IT-Änderungen, wenn Kunden Code und Patches bereitstellen und neue Infrastrukturen einrichten. IT-Änderungen stellen für Kunden ein Geschäftsrisiko dar, und der ROI für Governance ist enorm, sowohl in Geld als auch in Bezug auf die Moral.

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.

Präsentator

Autor

Devin Steinkyphäe
Direktor, Sicherheit

Devin hat über ein Jahrzehnt lang in verschiedenen IT-Bereichen gearbeitet und ist jetzt Director of Security bei Evolutio.

Möchten Sie sehen, was wir für Ihr Unternehmen tun können?

Kontakt
Cookie-Zustimmung

Wenn Sie auf "Akzeptieren" klicken, stimmen Sie der Speicherung von Cookies auf Ihrem Gerät zu, um die Navigation auf der Website zu verbessern, die Nutzung der Website zu analysieren und unsere Marketingaktivitäten zu unterstützen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie und Cookie-Richtlinie.