Jackpot für Kriminelle

Dutzende Bausteine türmen sich zur komplexen Maschinerie. Diese ruht links auf einem soliden Fundament, rechts aber stützt nur ein einzelnes dürre Bauklötzchen das ganze Gebilde. Die Maschine ist laut Überschrift „jede moderne IT-Infrastruktur“, der wackelige Stützklotz „ein Projekt, das irgendjemand aus Nebraska seit 2003 unbedankt pflegt“. An diesen Cartoon-Klassiker des Kultautors Randall Munroe fühlten sich viele kürzlich erinnert. Denn in Log4j, einem in Cloud-Services, Unternehmensapplikationen und IT-Gerätschaft gern genutzten Open-Source-Baustein, fand sich eine Sicherheitslücke – noch dazu eine kritische, die Angreifer leicht ausnutzen können.

Die „Log4Shell“ getaufte Lücke ist laut Amit Yoran, CEO des Security-Anbieters Tenable, „die größte und kritischste Schwachstelle des letzten Jahrzehnts“. Deshalb sorgt die offiziell als CVE-2021-44228 bezeichnete Schwachstelle in der Log4j-Bibliothek der Apache Foundation seit Ende November für Aufregung in IT-Kreisen. Dank ihr können laut Fachleuten nicht-authentifizierte Akteure Java-Anwendungen angreifen, die für das Logging die Log4j-Bibliothek verwenden, und dann beliebigen Code inklusive Schadcode ausführen (Remote Code Execution, RCE).

Besonders bedenklich: Die Sicherheitslücke in der JNDI-Komponente (Java Naming and Directory Interface) des LDAP-Connectors von Log4j ist laut Evgeny Lopatin, einem Sicherheitsexperten bei Kaspersky, „besonders einfach“ auszunutzen. Nicht umsonst erhielt sie eine CVSS-Kritikalitätseinstufung (Common Vulnerability Scoring System) mit dem Maximalwert 10,0.

Laut Ciscos Security-Truppe Talos lag die Lücke bei ihrem Auftreten zudem auf der Kenna-Risikoskala bei 93 von 100 – also außergewöhnlich hoch. Der Kenna Risk Score fasst die potenziellen Auswirkungen einer Lücke und damit deren Eignung für einen Angriff in einen Zahlenwert. Laut Talos haben von den 165.000 Sicherheitslücken, die Kenna Security je erfasst hat, nur 0,39 Prozent einen Wert von 93 oder höher. Und hierzulande warnte das BSI, die Schwachstelle führe zu einer „extrem kritischen Bedrohungslage“.

Was ist passiert? Den zeitlichen Ablauf hat Talos in einem Blog-Post zu Log4Shell übersichtlich aufbereitet: Das Security-Team von Alibaba Cloud entdeckt die RCE-Schwachstelle in der – mit über 400.000 Downloads weit verbreiteten – Java-Logging-Bibliothek am 24.11.21 und meldet sie an Apache. Doch bereits am 30.11., also noch bevor Apache sie patchen kann, kommt sie ans Licht der an solchen Dingen interessierten Öffentlichkeit – und schon am 1.12. gibt es erste Berichte, dass Angreifer die Lücke ausnutzen, was Talos am Folgetag dann auch selbst beobachtet. Check Point meldet, 72 Stunden nach der ersten Attacke habe man bereits rund 846.000 Angriffe registriert.

Eine Woche später, am 9.12., stellt die Apache Foundation einen Patch bereit – doch da laufen bereits zahlreiche Angriffe mittels Zero-Day-Exploits. Laut diversen Security-Anbietern dienen diese zunächst dem Ausbringen von Cryptomining-Malware, doch kurz darauf folgen Berichte über offenbar staatlich organisierte Aktivitäten. In den nächsten Tagen schwillt die Angriffswelle an: Das Mirai-Botnet schaltet sich ein, und Angreifer nutzen, wie in solchen Fällen oft üblich, E-Mails als Angriffsvektor. Security-Häuser, beispielsweise SophosLabs und Bitdefender Labs, berichten neben dem Einbetten von Kryptominern nun auch von Ransomware-Attacken. Denn zur Kompromittierung reiche mitunter bereits, in ein Online-Eingabefeld eine einzige Codezeile einzufügen.

Hastiges Patchen

Nun ist das Motto: ordentlich ranklotzen! Allerorten patchen IT-Organisationen und -Dienstleister Java-Applikationen, so schnell es geht. Betroffen sind neben Cloud-Größen wie Amazon, Microsoft (mit der Gaming-Plattform Minecraft) oder Twitter auch zahllose Unternehmen. Check Point meldet am 20.12. über 4,3 Millionen Versuche, die Schwachstelle auszunutzen. Fast jedes zweite von Check Point überwachte Unternehmen weltweit sei von der Schwachstelle betroffen, in Europa sogar noch etwas mehr als die Hälfte (51,2 Prozent).

Laut einem Eset-Report vom 21.12. lag Deutschland hinsichtlich der Angriffsversuche weltweit auf Rang 5, nach den USA (mit großem Abstand auf Platz 1), UK, den Niederlanden und Tschechien. Eine Verschleierung der Zugriffe mit dem Anonymisierungsdienst Tor lässt Deutschland dabei als Nummer-Eins-Herkunftsland der Angriffe erscheinen, berichtet Bitdefender.

Angreifer und Verteidiger liefern sich das branchenübliche Hase-und-Igel-Rennen: Apache bessert seine Patches mehrmals nach, unter anderem, um Denial-of-Service-Angriffe zu verhindern. Bis Weihnachten hat sich die Lage noch nicht entspannt, zumal Fachleute davon ausgehen, dass die gewiefteren Angreifer in der ersten Phase Backdoors installieren, um später nochmals in aller Ruhe Angriffe ausführen zu können. „Aufgrund der Art dieser Schwachstelle geht Talos davon aus, dass diese Schwachstelle in Zukunft häufig von Angreifern ausgenutzt werden wird“, heißt es auf dem Blog der Cisco-Tochter. Der wenig überraschende Rat: „Benutzer sollten betroffene Produkte so schnell wie möglich patchen und Lösungen zur Schadensbegrenzung implementieren.“

Sisyphusarbeit

Das ist leichter gesagt als getan: Das Schließen einer so verbreiteten Lücke ist ein Vorhaben, das IT-Organisationen über Wochen und Monate hinweg beschäftigen kann. Wie ernst die Lage ist, zeigt der Umstand, dass in den USA die Federal Trade Commission (FTC) dortige Unternehmen zum schnellstmöglichen Patchen aufruft und droht: „Die FTC beabsichtigt, ihre rechtlichen Befugnisse voll auszuschöpfen, um gegen Unternehmen vorzugehen, die keine angemessenen Maßnahmen ergreifen, um Verbraucherdaten künftig vor der Gefährdung durch Log4j oder ähnliche bekannte Schwachstellen zu schützen.“

Diese Mahnung der US-Behörde war laut Tenable-Chef Yoran „längst überfällig“, denn: „Die Nichtbehebung von Log4j ist schlimmer, als wenn Sie Ihre Türen und Fenster unverschlossen lassen und einen Eindringling einladen, Ihre Regale zu plündern. Dadurch werden nämlich auch die Daten, die so viele Unternehmen über Einzelpersonen sammeln, gefährdet.“ Die Log4j-Schwachstelle nicht zu beheben, so Yoran, sei „geradezu die Definition von Fahrlässigkeit“.

Verantwortliche allerorten fragen sich: Haben wir Log4j im Einsatz? In der modernen DevOps-Welt mit Downloads von öffentlichen Repositories und zahllosen Abhängigkeiten der Komponenten ist die Antwort auf diese Frage laut Experten oft nicht sofort ersichtlich: „Die Schwierigkeit für viele Unternehmen besteht derzeit darin, zu identifizieren, ob sie Log4j im Einsatz haben und in welcher Konfiguration“, so Dr. Sebastian Schmerl,  Director Security Services EMEA bei Arctic Wolf. „Das kann ohne aktives Monitoring, ein Software-Inventory oder ein Vulnerability-Scanning oftmals nicht einfach beantwortet werden.“ Das BSI stellt deshalb eine Anleitung zur Erkennung und Behebung der Schwachstelle bereit.

„Zuerst sollten Unternehmen prüfen, ob eine Version von Log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten“, sagt Jonathan Tanner, Security-Forscher bei Barracuda Networks. „Sowohl Maven als auch Gradle – beides auf Java basierende Build-Management-Tools – bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken.“ So lasse sich feststellen, ob eine verwundbare Version von Log4j im Einsatz ist oder nicht.

Mit dem Stopfen der Sicherheitslücke allein ist es dabei längst nicht getan – ähnliche Schwachstellen könnten schließlich jederzeit wieder auftreten. Zum reinen Nachbessern an den Java-Anwendungen gesellen sich deshalb weiterreichende Konsquenzen. So hagelte es in den Wochen vor Weihnachten Kommentare, Empfehlungen und Hinweise von Security-Anbietern, wie man in dieser brenzligen Lage vorgehen sollte.

Doch Verteidigungsmaßnahmen sind laut Lothar Hänsler, COO beim Wiener MSSP Radar Cyber Security, nicht so einfach umzusetzen: „Dies liegt unter anderem daran, dass alle Mitigationsstrategien Risiken und Nebenwirkungen für die Applikationen haben können, die von der Schwachstelle betroffen sind“, so Hänsler. Deshalb gebe es in Fachkreisen „unterschiedliche Sichtweisen zu den Mitigationsstrategien“.

Viele Anbieter nutzen die Gelegenheit, auf den Wert ihrer eigenen Security-Lösungen für diese Mitigationsstrategien hinzuweisen. In der Tat kann praktisch die gesamte Bandbreite der Security-Lösungen von der Code-Qualitätskontrolle im DevOps-Einsatz bis hin zu EDR, NDR und XDR (Endpoint/Network(Extended Detection und Response) zum Aufspüren von Angriffsversuchen hier ihre Schlagkraft unter Beweis stellen. Talos empfiehlt den Unternehmen darüber hinaus die Aktualisierung von Incident-Response-Plänen und Playbooks oder eine Tabletop-Übung, um ihre Reaktionsfähigkeit bei derlei Vorfällen zu testen.

Sicherheit der digitalen Supply Chain

Von Anfang an stand eine Frage im Raum: Welche Rolle spielt der Umstand, dass es sich hier um Open Source handelt, bei dieser Sicherheitslücke? Schließlich beruht ein erheblicher Teil der globalen Digitalinfrastruktur auf der Arbeit Freiwilliger, die – oft in ihrer Freizeit und ohne jegliche Vergütung – quelloffenen Code schreiben und zur Verfügung stellen. Als Sicherheitsvorteil quelloffener Software gilt, dass jedermann und jedefrau jederzeit jede Codezeile einsehen und überprüfen kann.

„Generell kann jede Software anfällig für Angriffe sein, und bei populärer Open-Source-Software gibt es oft ein großes Ökosystem, das nach Sicherheitsbedrohungen sucht und diese behebt“, erläutert Barracuda-Mann Tanner. Er betont: „Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist.“ Closed Source ist also keineswegs die bessere Alternative – auch hier gibt es genügend Beispiele für Sicherheitslücken.

Ein Damoklesschwert kann allerdings laut scheppernd herunterkrachen, wenn es sich um ein verbreitetes, aber aus Entwicklersicht „unsexy“ Stückchen Code handelt, für das sich nur „irgendjemand in Nebraska“ verantwortlich fühlt – das deutsche Pendant der Metapher wäre: „irgendjemand auf einer Almhütte im tiefsten Allgäu“. Denn da hängt der Code mitunter nur an einer Person – bei Log4j übrigens an drei Personen in der Schweiz. Wie also lässt sich das „Nebraska-Almhütten-Problem“ nicht nur im aktuellen Einzelfall, sondern dauerhaft lösen?

Ein erster Schritt könnte es laut Marktkennern sein, die Open-Source-Entwicklergemeinde finanziell besser auszustatten. Dass muss nicht heißen, dass alle Freiwilligen künftig Honorar erhalten. Doch dass Organisationen wie die Apache Foundation von den Zuwendungen einer Sponsorenschar abhängig sind, wird der eminenten Rolle nicht gerecht, die Open-Source-Code in der digitalisierten Welt spielt.

So schlug Filippo Valsorda, in Googles Go-Team verantwortlich für die Security, auf seinem Blog vor: Open-Source-Entwickler sollten den Unternehmen, die von ihrer Arbeit abhängen, ruhig mal fünf- bis sechsstellige Rechnungen schicken. Hierzulande fordert die Open Knowledge Foundation vor dem Hintergrund politischer Bestrebungen, stärkere digitale Souveränität zu etablieren: Für die Entwicklung, Verbesserung und Instandhaltung offener digitaler Basistechnologien müsse es einen „Sovereign Tech Fund“ geben, der das Open-Source-Ökosystem nachhaltig stärkt.

Ein Bremsklotz: Dazu muss man staatliche Finanzbürokratie in Einklang bringen mit einer agilen Softwareentwicklungswelt – nicht unbedingt ein Traumpaar. Immerhin, erste Ansätze dazu gab es bereits: Das Fossa-Projekt (Free and Open Source Software Auditing) der EU zielte darauf ab, die Sicherheit und Integrität kritischer Open-Source-Software zu erhöhen. Die Europäische Kommission hatte es 2014 nach der Entdeckung des Heartbleed-Bugs ins Leben gerufen – das Projekt lief jedoch im Juli 2020 aus.

Als – neben der leidigen Finanzierungsfrage – zweite große Hürde besteht die immense Herausforderung, in der DevOps- und idealerweise DevSecOps-Welt den Überblick über die zahllosen verwendeten Softwarebausteine zu behalten. Nicht umsonst herrschte anfangs die erwähnte Unsicherheit, wen Log4Shell überhaupt betrifft. So stellt Udo Schneider, IoT-Security-Experte bei Trend Micro, die provokante Frage: „Nutzt vielleicht eine bei Ihnen eingesetzte Bibliothek eines Drittanbieters intern Log4J? Oder noch schlimmer – nutzt eine Library, die Sie verwenden, eine Library, die wiederum von einer Library abhängt und so weiter, die Log4J nutzt?“

Schneider rät deshalb zu einer „Software Bill of Materials“ (SBOM, Software-Materialstückliste), also zur Dokumentation der Softwarebausteine und zum Tracking von deren Abhängigkeiten. Dies müsse einhergehen mit einem Schwachstellen-Monitoring und einem Software-Supply-Chain-Management.

Wichtig: Nicht nur in der IT-, sondern auch in der OT-Welt (Operational Technology, industrielle Betriebstechnik) kann ein Eingreifen erforderlich sein: „Die meisten OT-Infrastrukturen basieren auf alter Technologie und eingeschränkten, eingebetteten Systemen. Hier kam Java kaum zum Zug, sodass die Gefahr weniger groß ist“, erklärt Tony de Bos, Vice President Operations bei Kudelski Security. Doch er warnt: „Moderne OT-Anlagen mit Internetzugang sind dagegen ähnlich bedroht wie herkömmliche IT-Systeme – und Hacker werden diese Gelegenheit ausnutzen. Betroffene sollten sich Transparenz über ihre Anlagen verschaffen und insbesondere für Altanlagen ohne Aussicht auf Patches alternative Sicherheitskonzepte suchen.“

Laut Fachleuten haben wir hinsichtlich der Schäden, die Log4Shell anrichten kann, bislang wohl nur die Spitze des Bauklötzchenbergs gesehen – schließlich steckt Log4j nicht nur in Cloud-Services und Enterprise-Applikationen, sondern auch in Switches, WLAN-Routern und industrieller Betriebstechnik. Wünschenswert wäre, dass Log4Shell als Weckruf dient, die Open-Source-Sicherheit ebenso ernst zu nehmen, ebenso finanziell zu unterfüttern und ebenso effizient zu organisieren wie die Sicherheit kommerzieller Software – idealerweise sogar effizienter. Hier heißt es: nicht kleckern, sondern klotzen! Denn sonst werden wir uns künftig immer wieder bei Lücken in scheinbar nebensächlichen Softwarekomponenten aus irgendeiner Entwickler-Almhütte die Augen reiben und angesichts der enormen Auswirkungen Bauklötzchen staunen.

(Dieser Beitrag erschien erstmals in LANline 02/2022.)

Bild: (c) Wolfgang Traub