Der Apache-Log4j-Log4Shell-Fehler ist eine der kritischsten Sicherheitslücken in der Geschichte der Cybersicherheit.
Hunderte Millionen Geräte nutzen die Log4j-Komponente für verschiedene Onlinedienste, darunter Behörden, kritische Infrastrukturen, Unternehmen und Privatpersonen.
Tatsächlich verwendet so gut wie jede Software diese in Java geschriebene Bibliothek, daher ist sie ein äußerst weitverbreitetes Risiko und Problem. Deshalb nutzen Hacker den Fehler auch aktiv aus, seit er im vergangenen Jahr öffentlich wurde – teilweise mithilfe öffentlicher POCs (Proofs of Concept), die sich allzu leicht auf GitHub finden lassen; außerdem ist der Exploit notorisch einfach einzusetzen.
Forscher von Zectonal haben aufgedeckt – einen neuen und äußerst wichtigen Angriffsvektor, der den berüchtigten Fehler ausnutzen kann: Datenpipelines und Data Lakes. Die Forscher zeigen, wie Hacker KI und maschinelles Lernen manipulieren könnten, um die Erkennung zu umgehen.
Die infizierte Payload könnte in Big-Data-Dateien eingeschleust werden, die zum Trainieren von KI verwendet werden. Den Forschern zufolge ist ein solcher Angriff nur schwer vorherzusehen und zu erkennen. Um die Schwere der Bedrohung zu demonstrieren, nutzten sie möglichst realistische Prozesse und Cloud-Architekturen.
Ziel des Exploits ist es, die angegriffenen KI-Modelle und die zugehörigen Analysen zu manipulieren und damit die gesamte Dateninfrastruktur unwirksam zu machen. Indem Hacker schädliche Payloads in die globale Datenlieferkette einschleusen, könnten sie ihren Opfern verheerenden Schaden zufügen.
Lesen Sie auch: Die besten Tools für Code-Debugging und Codesicherheit
Den Big-Data-Angriff verstehen
No-Code-Datenpipelines, wie sie in der Untersuchung verwendet wurden, sind für Angreifer besonders attraktiv, da „der Datenfluss vor seiner Verarbeitung und dem anschließenden Zugriff auf ein verwundbares System keinerlei Firewall oder Scanvorrichtung durchläuft.“
Die Forscher verwendeten bewusst eine gängige cloudbasierte Architektur, Speichersysteme (z. B. Buckets) und ETL-Anwendungen (Extract, Transform, Load). Außerdem nutzten sie Standardkonfigurationen und -dateien und versteckten ihre Payload (die speziell erzeugte Zeichenfolge zur Ausnutzung des Log4Shell-Fehlers) in einem einzigen Datenpunkt unter den Millionen verfügbaren:
Der ETL-Prozess führt Daten aus mehreren Quellen in einem einzigen Datenpool zusammen. ETL-Anwendungen sind für Datenanalysen und Workflows des maschinellen Lernens unverzichtbar, da sie die Daten nach bestimmten Regeln bereinigen und organisieren, die den Anforderungen der Business Intelligence entsprechen.
Den Forschern gelang es, „unmittelbare Remote-Code-Ausführung aus einer privaten virtuellen Cloud über das öffentliche Internet zu erlangen.“ Genauer gesagt erhielten sie Fernzugriff auf einen No-Code-ETL-Softwaredienst mit privaten Subnetz-IP-Adressen, der Teil einer von einem Public-Cloud-Anbieter gehosteten VPC (Virtual Private Cloud) war.
Ein solcher Exploit wird wahrscheinlich weitere Angriffe inspirieren, da KI für viele fortschrittliche Anforderungen und Dienste eingesetzt wird. Kritische Systeme wie intelligente Fahrzeuge, das Gesundheitswesen, das Finanzwesen und Lieferketten werden dank Deep Learning automatisiert und können weiter automatisiert werden.
Unternehmen nutzen KI bereits, um Muster und Trends in Kundenanalysen zu erkennen und Geschäftschancen aufzuspüren. Schwachstellen, die einer solchen Umgehungsstrategie den Zugriff auf Data Lakes ermöglichen, müssen schnell behoben werden.
Um die Log4Shell-Sicherheitslücke auszunutzen, griffen die Forscher die Logstash-Komponente des ELK-Stacks (Elasticsearch, Logstash und Kibana) an, eines sehr beliebten Open-Source-Systems zur Protokollverwaltung mit Millionen von Downloads.
Solche Plattformen werden von Unternehmen häufig zum Extrahieren und Analysieren von Daten eingesetzt. Während die neuesten Versionen die Log4Shell-Sicherheitslücke behoben haben, konnten die Forscher in Kombination mit Java 8 Versionen ausnutzen, die unmittelbar vor der Veröffentlichung von Log4Shell erschienen waren.
Die Forscher nutzten eine klassische Kombination von Angriffsvektoren in Unternehmen: mehrere veraltete Komponenten, die letztlich zur Katastrophe führen.
Lesen Sie auch: Die besten Tools für das Schwachstellenmanagement
KI- und Open-Source-Exploits verhindern
Die Forscher verwiesen auf den Synk JVM Ecosystem Report 2021, dem zufolge „60 % der Java-Entwickler Java 8 noch immer in der Produktion einsetzen“. Tatsächlich verwenden viele Unternehmenssysteme veraltete Bibliotheken, wodurch ganze Organisationen einem hohen Risiko ausgesetzt sind.
Obwohl ein aggressives Patch-Management erhebliche Kosten und operative Komplexität verursachen kann, müssen sich Anwender und Administratoren bewusst sein, welche ihrer Hard- und Software verwundbar ist oder ausgemustert werden muss. Angreifer haben inzwischen Zugriff auf ein umfangreiches Angebot fortschrittlicher Hacking-Tools, die Schwachstellen kartieren und vorkonfigurierte Payloads zu deren Ausnutzung bereitstellen können.
Die Softwarelieferkette ist anfällig für Angriffe, und die Open-Source-Bibliothek Log4j ist ein eindrucksvolles Beispiel dafür. Tatsächlich ist Open Source zunehmend Bestandteil von Unternehmensanwendungen und Entwicklungsprojekten, und die Absicherung der verschiedenen zugehörigen Ökosysteme wird weder kostenlos noch einfach sein. Die Abhängigkeiten sind schier unüberschaubar.
Es mag wie ein kostspieliges Unterfangen erscheinen, all das abzusichern, doch die Kosten erfolgreicher Cyberangriffe sind weitaus höher – und bringen Organisationen in manchen Fällen sogar aus dem Geschäft.
Die Open Source Security Foundation (OpenSSF), eine führende Open-Source-Organisation im Umfeld der Linux Foundation, kündigte „einen ehrgeizigen, mehrgleisigen Plan mit 10 zentralen Zielen an, um das gesamte Open-Source-Softwareökosystem besser abzusichern“. Das Programm kostet 150 Millionen US-Dollar; mehr als 30 Millionen US-Dollar davon wurden bereits von Technologieriesen wie Amazon, Ericsson, Google, Intel, Microsoft und VMWare zugesagt.
Der Plan könnte Entwickler dabei unterstützen, Probleme zu beheben, unter anderem durch Schulungen, Sicherheitsprüfungen bereitzustellen und die Verwendung authentifizierter Paketsignaturen für die Verteilung von Softwarekomponenten zu fördern. Die Initiative wird wahrscheinlich vielen Akteuren in der Softwarelieferkette zugutekommen, darunter auch dem öffentlichen Sektor.
Dies ist zwar nicht das erste Mal, dass die Linux Foundation versucht, zur Absicherung der Open-Source-Welt beizutragen, doch der aktuelle Zustand der Softwarelieferkette ist inzwischen so zerrüttet, dass wichtige Führungspersönlichkeiten bereit sind, etwas zu unternehmen. Hoffentlich ist sie nicht unumkehrbar kaputt.
Ob Entwickler ihre Komponente mangels finanzieller Unterstützung selbst sabotieren, böswillige Mitwirkende Hintertüren in beliebte Open-Source-Bibliotheken einschleusen oder Maintainer versehentlich kritische Fehler einführen – das Abhängigkeitsmanagement kann zu einem Albtraum werden.
Zusätzlich zu diesen Bedrohungen verwenden viele Abhängigkeiten bestehende Komponenten, um die Entwicklung zu beschleunigen. Dadurch entsteht eine weitere Komplexitätsebene, die es für Unternehmen noch schwieriger macht, das gesamte Durcheinander zu verwalten.
Lesen Sie als Nächstes: