Log4Shell (Log4j) – Eine kleine Sicherheitslücke wird zu einem großen Problem

Eine Sicherheitslücke in der Bibliothek log4j hat im Dezember 2021 für eine Menge Aufsehen in der IT-Gemeinde gesorgt und vielerorts hektische Betriebsamkeit ausgelöst. Wie kann man auf solch ein Ereignis reagieren, und was zeichnet eine etablierte Organisation aus?

Ausgangssituation

Softwareprodukte und -eigenentwicklungen sind heutzutage hochkomplex und bestehen aus sehr vielen einzelnen Komponenten. Nicht in allen Fällen ist unmittelbar ersichtlich, was tatsächlich alles genutzt wird, denn zumeist werden umfangreiche und funktionsreiche „Baugruppen“ verwendet, die wiederum aus einer Vielzahl von einzelnen Komponenten bestehen.

Dies erleichtert zwar die Anwendungsentwicklung maßgeblich, denn es werden bereits Komponenten für die gängigen Fragestellungen so zusammengestellt und ausgeliefert, dass diese „einfach“ eingesetzt werden können. Der Nachteil: Vielfach wird nur ein kleiner Teil der enthaltenen Funktionalität genutzt, doch das Anpassen dieser Frameworks (tailoring) oftmals nicht durchgeführt, selbst wenn es angebracht wäre. Dadurch entsteht schnell die Situation, dass für eine einzelne spezifische Funktionalität, gerade im Kontext von Microservices, ein umfangreiches Gerüst an Bibliotheken und Einzelkomponenten gepackt, ausgeliefert und mitbetrieben wird, auch wenn sie nicht erforderlich wären. Dabei bleibt oftmals die Transparenz über die einzelnen Bestandteile auf der Strecke.

Die Sicherheitslücke in log4j kurz und knapp

Die Bibliothek log4j wird dafür genutzt, relevante Aktivitäten aus einer Anwendung zu protokollieren. Das dient hierbei sowohl der Aktivitätsüberwachung als auch der Fehleranalyse. Durch granulare Protokollierungen können sowohl Meldungen bezüglich der Konfiguration, des Status als auch hinsichtlich eines unerwarteten Verhaltens erfasst werden.

Durch die Sicherheitslücke ist es möglich, auf Basis eines Web-Requests eine „remote code execution“ auszulösen. Das bedeutet, dass die Anwendung, entgegen der eigentlichen Funktionalität, Dinge ausführt, die nicht geplant waren. Dies kann dazu genutzt werden, Passwörter auszuspähen beziehungsweise zu ändern oder einen ausführbaren Programmcode über das Netzwerk nachzuladen und somit massiv schädliche Auswirkungen für die eigene IT zu verursachen.

Da diese Sicherheitslücke sehr einfach ausgenutzt werden kann und die Bibliothek eine große Verbreitung hat (sowohl in Java-basierten Anwendungen, Frameworks, aber auch Netzwerk-Appliances etc.), kommt dieser Lücke eine besondere Kritikalität zu.

Mögliche Reaktionen und eine Bewertung

Es gibt verschiedene Herangehensweisen, mit dieser Situation umzugehen – gerade vor dem Hintergrund, dass der exakte Umfang der Betroffenheit nicht immer klar ist.

Beobachten und unterbinden

Die erste Variante ist, erst einmal nichts zu tun und stattdessen auf eine Überwachung der IT-Landschaft zu setzen. Das ist eine valide Strategie, ab dem Zeit- punkt, wo das genaue Muster des Angriffs bekannt ist. In diesem konkreten Fall war zeitnah bekannt, in welcher Form Aufrufe erfolgen müssen, damit die Lücke ausnutzbar ist.

Für die Umsetzung dieser Strategie bedarf es einer kontinuierlichen Überwachung des Datenflusses, insbesondere in das Unternehmen hinein. Eine solche Überwachung kann durch einen „Content-Filter“ beziehungsweise eine „Deep Packet Inspection“ erreicht werden. Viele moderne Netzwerkkomponenten beziehungsweise „Web Application Firewalls“ bieten hierfür Möglichkeiten. Im Fall eines erkannten Aufrufs kann dieser automatisch unterbunden werden. Der Vorteil ist, dass man Zeit gewinnt, um herauszufinden, inwiefern man betroffen ist, und eine Behebung anzugehen.

Der Nachteil dieser Herangehensweise liegt in der grundsätzlichen Natur einer Überwachung, die nur reaktiv sein kann und entsprechend bei einem geänderten Angreiferszenario ebenso angepasst werden muss. Damit ist gleichermaßen auch nicht sichergestellt, dass alle Angriffe früh genug erkannt werden, sodass ein Maß an Unsicherheit verbleibt.

Abschottung und Behebung

Die zweite Variante ist, den Datentransfer massiv zu beschränken beziehungsweise einzustellen und die Behebung des Problems anzugehen. Erst nach einer erfolgten Lösung kann anschließend der Datentransfer wieder freigegeben werden. Insbesondere in großen und technologisch unübersichtlichen Umgebungen kann dies ein Vorgehen der Wahl sein, sofern die betroffenen IT-Systemverbünde nicht geschäftskritisch sind, oder auch gerade dann, wenn es um sehr geschäftskritische Bereiche geht. Der Vorteil einer solch vorsichtigen Strategie ist, dass man die Risikofläche minimiert, denn ein Datentransfer zwischen Geschäftspartnern kann dann zugelassen werden, wenn sichergestellt ist, dass über eine Partnerstrecke kein Einfall zu erwarten ist. Allerdings verbleibt eine gewisse Restunsicherheit, abgesehen von den verschiedenen Schadensarten (Reputations-, Geschäftsschaden etc.), die eine solche Reaktion hervorrufen kann und potenziell hervorrufen wird.

Auch bei dieser Variante gewinnt man Zeit, die eigene Betroffenheit zu klären und Schritte einzuleiten. Allerdings muss dies sehr genau abgewogen werden, denn die Außenwirkung ist klar erkennbar (zumindest für Geschäftspartner).

Scan & Patch

Die dritte Variante ist, sehr zeitnah mit einer automatisierbaren Suche nach vulnerablen Komponenten zu beginnen und diese „auto-magisch“ zu patchen, indem Fehlererhebungen oder Mitigationen aufgespielt werden.

Dieses Vorgehen wirkt auf den ersten Blick attraktiv, ist aber mit verschiedenen Risiken verbunden:

• Korrektheit und Zuverlässigkeit der Umsetzung
• Rechtliche Darstellbarkeit

Im Kontext der automatisierten Anpassung von Softwarebibliotheken oder -konfigurationen verbleibt eine gewisse Unsicherheit, dass der gewünschte Effekt ohne Beeinträchtigung der Funktionalität hergestellt werden kann. Gerade im Kontext von Konfigurationen bieten sich in komplexen Szenarien unterschiedliche Fehlerkonstellationen, die nicht im Vorfeld abgeschätzt werden können. Um Fehlfunktionen auszuschließen, sollten daher solche Verfahren sehr genau getestet und die entsprechend modifizierten Anwendungen fachlich überwacht werden. Bei einer automatischen Veränderung der Bibliothekskomponenten selbst kann wiederum ein Fehlverhalten induziert werden, wenn die genaue Funktions- weise und Einbindung in die Gesamtanwendung nicht bekannt sind.

Neben der technischen Machbarkeit ist auch der rechtliche Aspekt relevant, da sich Wartungs-, Support- und Lizenzverträge in aller Regel auf die Komponenten beziehen, die durch den Hersteller ausgeliefert wurden. Im Fall von Konfigurationsänderungen ist dies meist unproblematisch, aber bei einer Veränderung der Binärdateien sind die durchgeführten Maßnahmen für den Hersteller nicht mehr nachvollziehbar. Dies kann sehr schnell dazu führen, dass Anfragen abgelehnt werden, sollten die (technisch sehr leicht ermittelbaren) Prüfsummen der ausgelieferten Komponenten auf eine Veränderung hindeuten.

Mitigation und Behebung

Die vierte Variante ist, in einem ersten Schritt das Risiko zu minimieren beziehungsweise abzustellen, indem die Mitigationsmaßnahmen umgesetzt werden. Solange diese umgesetzt sind, ist die Funktionalität gegebenenfalls eingeschränkt, aber ein IT-Betrieb weiterhin möglich. Parallel dazu kann eine Behebung durchgeführt werden.

Bei den umzusetzenden Mitigationen empfiehlt es sich, die genauen Auswirkungen und Szenarien zur Ausnutzung der Lücke zu prüfen, da nicht in jedem Nutzungskontext die möglichen Angriffsvektoren auch relevant sind. Eine Kenntnis der individuellen Rahmenbedingungen ist daher unabdingbar.

Fazit der Varianten

Bei den vorgestellten Varianten geht es immer um eine Abwägung der möglichen Schadenshöhe und der Reaktionsgeschwindigkeit. Eine souveräne Entscheidung basiert jedoch auf der genauen Kenntnis der Umstände einer Sicherheitslücke, also deren Ausnutzbarkeit, aber auch der eigenen Betroffenheit im Sinne der Intensität (Anzahl der betroffenen Applikationen) und des Umfangs (betroffene Geschäftsprozesse). Hierüber bedarf es einer hohen Transparenz, um zeitnah reagieren zu können. Denn eines ist sicher: Fehler und Sicherheitslücken wird es immer geben und die effektive Reaktion darauf immer wichtiger.

 Aktives Management der IT als zukunftsorientierte Strategie

Für das aktive Management von Fehlern und Sicherheitslücken gibt es etablierte Verfahren, Standards und Werkzeugunterstützung, die eingesetzt werden können.

Die ersten Schritte hierzu sind in den meisten Unternehmen auch bereits implementiert, gerade im Kontext ein- gesetzter Softwarelizenzen. Darüber hinaus bedarf es aber einer weitergehenden Betrachtung, um die eigene IT-Landschaft umfassend analysieren zu können.

Stückliste der IT-Bebauung

Wesentlich für ein effektives Management der IT-Landschaft und der einzelnen Komponenten in dieser Landschaft ist das Wissen darüber, aus welchen Bestandteilen diese Landschaft besteht. Dies betrifft sowohl die Hardwarekomponenten und die Softwareanwendungen als auch deren Bestandteile im Kontext einer „Stück- liste“ (bill of materials).

Eine solche Stückliste muss aktuell sein und einem einheitlichen Schema entsprechen. Die Benennung von Komponenten ist über den Standard „Common Platform Enumeration“ (CPE) möglich. Hierbei handelt es sich um eine eindeutige Beschreibung zur Zuordnung von Komponenten, die folgendem Format entspricht:

• cpe: part : vendor : product : version : update : edition : language

Durch die feingranulare Beschreibung können die wesentlichen und gebräuchlichen Versionierungsschemata abgebildet werden, wie nachfolgende Beispiele zeigen:

Durch eine Übersicht ist zu jedem Zeitpunkt bekannt, welche Komponenten genutzt werden. Anhand dieser Liste kann nun geprüft werden, ob Sicherheitslücken vorliegen, und damit die individuelle Betroffenheit bewertet werden.

Überwachung sicherheitsrelevanter Meldungen Sicherheitslücken, die bekannt und veröffentlicht wer- den, bekommen zumeist eine feste Benamung, damit darauf verwiesen werden kann. Außerdem ermöglicht dies eine Prüfung und Auswertung, wie viele Sicherheits-lücken zu einem Produkt oder in einem bestimmten Zeit- raum aufgetreten sind.

Für die Benennung und Sammlung hat sich das Schema der „Common Vulnerabilities and Exposures“ (CVE) etabliert. Hierbei gibt es zwei verschiedene Aspekte zu beachten:

• Handelt es sich um einen Fehler in der Implementierung?
• Handelt es sich um einen Fehler in der Konfiguration?

Fehler, die aus der Implementierung resultieren, wer- den über CVE gut adressiert und bieten eine einfache Möglichkeit, in Verbindung mit CPEs eine eindeutige Zuordnung zu treffen. Fehler, die aus einer Konfiguration herrühren, werden zwar auch über CVE erfasst, aber zusätzlich noch mit einem eindeutigen Bezeichner annotiert, damit eben diese Konfigurationsparameter schneller gefunden und berücksichtigt werden können. Hierbei handelt es sich um „Common-Configuration- Enumeration“-(CCE-)Bezeichner.

Aus dem Triplet dieser drei Strukturen können somit Sicherheitsthematiken sehr gut zugeordnet und feingranular identifiziert werden:

• Common Platform Enumeration
• Common Vulnerability and Exposures
• Common Configuration Enumeration

Es ist aber nicht praktikabel, diese Listen regelmäßig manuell zu prüfen. Hierfür bedarf es, im Sinne eines aktiven Managements, einer Werkzeugunterstützung.

Einbindung in den Software-Lifecycle

Im Softwareeinsatz sowie in der Softwareentwicklung bedarf es einer eigenständigen Prüfung, ob eine Betroffenheit vorliegt. Für die eigene Softwareentwicklung ist es wichtig, nur „fehlerfreie“ Komponenten einzusetzen und schnell zu erkennen, ob ein (neues) Problem aufgekommen ist, das beachtet werden muss. Im Softwareeinsatz muss auch bei Drittprodukten überwacht werden, ob diese gefährdet sind oder eine gefährdete Komponente beinhalten.

In der eigenen Softwareentwicklung hat es sich etabliert, Artefakt-Repositorys zu verwenden, die sowohl als Ablageort für die eigenen Entwicklungsergebnisse als auch als Spiegel für Komponenten dienen, die aus öffentlichen Quellen bezogen werden. Für diese Repository-Produkte gibt es oftmals Erweiterungen und Scanner, die regelmäßig gegen öffentliche Quellen prüfen, ob neue Probleme aufgetreten sind. Im Fall eines Problems werden die betroffenen Komponenten markiert. Falls keine Artefakt-Repositorys verwendet werden, gibt es wiederum verschiedene Scanner-Komponenten, die im Softwarebuild eingesetzt werden können, um ebensolche Prüfungen durchzuführen. In diesem Handlungsfeld bestehen somit etablierte Möglichkeiten, von vornherein nur „sichere“ Komponenten einzusetzen.

Etwas anders sieht es aus, wenn man Dritt- und Kaufprodukte einsetzt. Hierbei ist es für ein aktives Management erforderlich, jeweils eine Übersicht zu bekommen, welche Komponenten „verbaut“ sind. Dies ist durch die Erstellung und Einforderung einer „Stückliste“ möglich. Solche Stücklisten wiederum können über etablierte Standards auch (teil-)automatisiert erstellt werden, beispielsweise über CycloneDX1. Anhand von solchen Softwareunterstützungen können sehr einfach Stücklisten erstellt werden, die dann automatisiert ausgewertet werden können.

Fazit

Beim Einsatz von Produkten werden, ebenso wie in der Entwicklung von Software, viele Einzelkomponenten verwendet. Diese werden von Unternehmen, Privatpersonen und verschiedensten Organisationen entwickelt, gepflegt und bereitgestellt. Gleichzeitig werden immer wieder Fehler und Sicherheitslücken bekannt, die dezentral erfasst und behoben werden. Durch die Kombination aus eineindeutiger Klassifikation von Komponenten, Parametern und Betroffenheiten kann dies zentral erfasst und geprüft werden. Durch die Erstellung und Pflege von „Stücklisten“ für die eigenen Softwareentwicklungen, aber auch der eingesetzten Produkte, die ohne großen Aufwand von Produktherstellern zugeliefert werden können, bietet sich für jedes Unternehmen die Möglichkeit, eine aktive Rolle einzunehmen und die Sicherheit der eigenen IT-Infrastruktur zu stärken.