Bug Report: Der andere Blick auf Cyber-Sicherheit

Der April offenbarte eine Reihe von wahrhaft beeindruckenden Schwachstellen, sodass nicht lange überlegt werden musste, wer das Rennen machen würde. Das sind die Bugs des Monats.

• CVE-2022-21449 alias „Psychic Signatures“: Java
• CVE-2022-26809: MSRPC
• CVE-2022-22965 alias „Spring4Shell“: Spring Framework

Man könnte jetzt einwenden: „Spring4Shell ist doch schon seit Ende März bekannt. Warum ist es im Bug-Report vom April enthalten?“ Das hat seinen Grund: Die Sicherheitslücke wurde kurz vor Monatsende, konkret am 29. März, aufgedeckt. Als sich dann herausstellte, wie kritisch Spring4Shell tatsächlich war, stand der März-Report von Trellix schon kurz vor Veröffentlichung. Aber wie heißt es so schön: besser spät als nie! 

CVE-2022-21449 alias „psychische Signaturen“: Elliptisches Scheitern

Worum handelt es sich?

Kryptographie gilt oft als eine der wenigen positiven Entwicklungen in der Cyber-Sicherheit, und das aus gutem Grund. Leider ist es bei der Kryptographie wie bei einem Witz. Er ist nur lustig, wenn die Pointe exakt zum richtigen Zeitpunkt erzählt wird. Übertragen heißt das: Auch der beste kryptographische Algorithmus kann nicht verhindern, dass Implementierungsfehler gemacht werden. Noch viel schlimmer ist es, dass diese Analogie geradezu perfekt auf die ECDSA-Implementierung in Java zutrifft. Mit dem Release von Java 15 wurde die ursprüngliche native Code-Implementierung in Java neu geschrieben. Dabei gelangte ein massiver Bug in den Code, mit dem sich die Verifizierung der ECDSA-Signatur problemlos aushebeln lässt, wie Neil Madden von ForgeRock konstatiert. Madden informierte Oracle im November 2021 über dieses Problem, ging damit aber erst nach sechs Monaten an die Öffentlichkeit, nachdem Oracle die Schwachstelle in seinem Critical Patch Update (CPU) vom April 2022 behoben hatte. In seinem Artikel bezeichnet Madden die Schwachstelle als „psychische Signaturen“ und bezieht sich dabei auf den Science-Fiction-Helden Doctor Who, der ein Blankodokument mit übernatürlichen Eigenschaften als universelles Ausweisdokument verwendet.

Um die Funktionsweise von CVE-2022-21449 wirklich zu verstehen, wäre ein Crashkurs in Kryptographie mit elliptischen Kurven (ECC) notwendig, der den Rahmen des Berichts bei weitem sprengen würde. Kurz gesagt: Eine ECDSA-Signatur besteht aus zwei Werten, r und s. Bei der Verifizierung einer ECDSA-Signatur wird überprüft, ob die linke und die rechte Seite einer mathematischen Gleichung für eine bestimmte elliptische Kurve tatsächlich identisch sind, wobei die linke Seite gleich r ist, während die rechte Seite (sozusagen) proportional zu s ist. Diese Gleichung ist trivial wahr (0 = 0), wenn sowohl r als auch s gleich Null sind. In diesem Fall ist eine Signatur immer gültig, unabhängig vom Inhalt der Nachricht oder vom verwendeten Schlüssel. Um dies auszuschließen, weist der ECDSA-Algorithmus u. a. eine Signatur als ungültig zurück, wenn entweder r oder s gleich Null sind. Dieser einfache Schritt ist in der neuen Java-Implementierung nicht enthalten. 00ps!

Wer ist betroffen?

ECDSA hat eine gewisse Ähnlichkeit mit Abwasserleitungen, die in jedem Haus verlegt sind. Auch diese nutzen wir ständig, ohne uns darüber Gedanken zu machen. Aber wehe, es gibt ein Problem … Als „Armaturen“ der von Java implementierten ECDSA-„Leitungen“ dienen zahlreiche gängige Standards für die Authentifizierung/Autorisierung im Web, z. B. JWTs, SAML und WebAuthn. Sie alle steuern den Zugang zu sensiblen Ressourcen auf Servern und verwalten sogar den SSO-Zugriff (Single Sign-On) von Usern über Sicherheitsdomänen hinweg. Noch beunruhigender ist womöglich, dass manche SSL-Zertifikate mit Signaturen arbeiten, die mittels Java-ECDSA erzeugt werden. Dies ermöglicht Man-in-the-Middle-Angriffe auf verschlüsselten Datenverkehr. Sie sollten sich also keinesfalls davon einlullen lassen, dass Oracle den Bug nur mit einem CVSS-Score von 7,5 eingestuft hat. Laut Oracle sind die Java-Versionen 15, 16, 17 und 18 mit Stand vor der April-CPU allesamt gefährdet. 

Obwohl CVE-2022-21449 sicher weniger drastische Folgen hat als die berühmt-berüchtigte Log4Shell-Sicherheitslücke, sollte erwähnt werden, dass Log4Shell ein Bug in einer Drittanbieter-Bibliothek war. CVE-2022-21449 hingegen ist ein Bug in der Java-Laufzeitumgebung. Dazu kommt, dass sich „psychische Signaturen“ ebenso leicht ausnutzen lassen wie die Log4Shell-Lücke und dass bereits ein PoC-Code existiert. Obwohl es in freier Wildbahn noch keinen Exploit gibt, dürfte das nur eine Frage der Zeit sein. Wenn Sie sich also wegen Log4Shell Sorgen gemacht haben, sollten Sie CVE-2022-21449 ebenfalls auf dem Monitor haben.

Was kann ich tun?

Wie so häufig, ist auch hier ein schnellstmöglicher Patch das Mittel der Wahl, insbesondere, da Oracle in seinem April-CPU das Loch bereits gestopft hat. Wenn dies nicht machbar sein sollte, können Sie alle Provider von Java Cryptography Architecture (JCA) auf BouncyCastle umstellen, eine Open-Source-Implementierung, die nicht von dem Bug betroffen ist. Sie wollen herausfinden, ob Ihre Organisation gefährdet ist? Nehmen Sie sich die Liste vor, die Sie nach Log4Shell für alle Softwareprogramme in Ihrer Umgebung angelegt haben, die auch nur im Entferntesten mit Java zu tun haben. Sie werden ganz sicher Überschneidungen mit dem aktuellen Problem feststellen. Darüber hinaus hat JFrog ein Tool auf GitHub veröffentlicht, das beliebige JAR/WAR-Dateien auf die Sicherheitslücke untersuchen kann – auch dies ein nützliches Instrument.

CVE-2022-26809: RPC – so einfach wie das Einmaleins

Worum handelt es sich?

CVE-2022-26809 hat keinen so eingängigen Spitznamen wie die beiden anderen Bugs des Monats, ist deshalb aber nicht weniger gefährlich. Veröffentlicht am 12. April im Rahmen des „Microsoft Patch Tuesday“, handelt es sich um eine vollständig remote ausgeführte, Zero-Click-Vorauthentifizierungsschwachstelle in Microsoft Remote Procedure Call (MSRPC). Diese Kernkomponente des Windows-Betriebssystems ist standardmäßig aktiviert, über das Netzwerk zugänglich und lässt sich nicht deaktivieren, ohne das Betriebssystem zu beschädigen. Ich kann verstehen, wenn Sie jetzt erst mal tief durchatmen müssen.

Die Schwachstelle wurde Microsoft von Cyber Kunlun gemeldet, einer Cyber-Sicherheitsfirma mit Sitz in Peking, die den Redmondern auch einen Exploit lieferte, der das Netzwerktransportprotokoll Server Message Block (SMB) als Angriffsvektor nutzt. Als Reaktion darauf empfahl Microsoft in seinem Leitfaden für Sicherheitsupdates zunächst, die durch das SMB-Protokoll verwendeten TCP-Ports 139 und 445 zu blockieren. Obwohl diese Ports nicht MSRPC-spezifisch sind, eröffnen sich Angriffsmöglichkeiten, wenn sie nicht geschlossen werden, da MRSPC das Protokoll als Transportmittel verwenden kann. Theoretisch gilt dies auch für MSRPC über TCP und MSRPC über HTTP.

Davon abgesehen, gibt es momentan nur sehr wenig belastbare Informationen dazu, mit welchen Methoden sich die Schwachstelle konkret ausnutzen lässt. Lediglich Akamai und MalwareTech haben grundlegende Analysen durchgeführt, die sich auf „Patch Diffing“ stützen. Demnach wurden durch den Patch einige Ganzzahlüberlauf-Checks eingeführt, die gegen einen potenziellen Überlauf des Heapspeichers bei Funktionen schützen, die für die Verarbeitung von RPC-Paketen zuständig sind. Genau dies dürfte die Lücke sein, durch die eine Remote-Codeausführung möglich wird.

Wer ist betroffen?

Grundsätzlich sollte jede Organisation mit einer Windows-Umgebung diese Gefahr sehr, sehr ernst nehmen. Es ist gut denkbar, dass Exploits zur Ausnutzung der Schwachstelle einen Wurm in Umlauf bringen und damit Malware-Kampagnen Tür und Tor öffnen. Dazu kommt, dass laut Microsoft quasi jede Version ab Windows 7/Server 2008 angreifbar ist. Es nützt also gar nichts, seit einem Jahrzehnt keine Windows-Updates mehr durchgeführt zu haben. Und ja, diese Mahnung richtet sich besonders an das Gesundheitswesen…

Systemadministratoren und Analysten, bei denen dies schlimme Erinnerungen weckt, kann ich trösten: Zum Zeitpunkt der Veröffentlichung des aktuellen Bug-Reports gibt es wohl noch keinen legitimen PoC-Code für CVE-2022-26809. Auch ein Exploit in freier Wildbahn wurde noch nicht gesichtet. Es bleibt also noch Zeit, sich zu wappnen, bevor Cyber-Kriminelle Payloads an jedes der 700.000 Windows-Systeme schicken, das über den Port 445 aus dem Internet erreichbar ist.

Ich gehe doch recht in der Annahme, dass alle 700.000 Systeme gepatcht sind, oder?

Was kann ich tun?

Patchen Sie Ihre Systeme. Patchen Sie sie jetzt. Da eine Deaktivierung von RPC schlicht nicht in Frage kommt, sind Patches und eine radikale Entfernung der Gefahrenquelle die einzigen wirksamen Methoden, um die Sicherheit von Windows-Systemen zu gewährleisten. Zugleich sagt mir mein gesunder Menschenverstand, dass es immer auch einen zweiten Weg geben muss. Wenn Sie also absolut nicht in der Lage sind, Ihre Systeme jetzt sofort zu patchen, sollten Sie zumindest die TCP-Ports 135 (MSRPC über TCP), 139 und 445 (MSRPC über SMB) sowie 593 (MSRPC über HTTP) Ihrer Netzwerkperimeter-Firewall dichtmachen. Genauso wahr ist aber auch: Effektive Firewall-Richtlinien setzen auf das Whitelisting von Ports für notwendige Services, nicht auf das Blacklisting von Ports, die als mögliche Einfallstore dienen können. Wer nur reagiert, läuft den Ereignissen ewig hinterher.

CVE-2022-22965 alias „Spring4Shell“: Das Mirai-Botnet ist wieder da

Worum handelt es sich?

Um adäquat erklären zu können, was Spring4Shell ist, muss man zunächst erklären, was es nicht ist. Es ist nicht CVE-2022-22963, eine auf den ersten Blick ähnliche Schwachstelle, die zur gleichen Zeit wie Spring4Shell bekannt gemacht wurde und eine serverseitige Code-Injektion in Spring Cloud Function ermöglicht. Ende März, während der ersten 72 Stunden nach Veröffentlichung der beiden Schwachstellen, waren auf Twitter jede Menge unzutreffende Dinge zu lesen, da viele User nicht zwischen den beiden Bedrohungen unterschieden und beide als „Spring4Shell“ bezeichneten. Tatsächlich bezieht sich Spring4Shell ausschließlich auf CVE-2022-22965, und sowohl diese Schwachstelle als auch CVE-2022-22963 wurden mit einem CVSS-Score von 9.8 eingestuft (kritisch). Da Spring4Shell allerdings ein sehr viel höheres Schadenspotenzial hat, haben wir diesen Bug und nicht seinen hässlichen Bruder in unseren aktuellen Report aufgenommen.

Nach dieser Klarstellung werde ich nun kurz auf das Spring-Framework eingehen, das Angriffsziel der Spring4Shell-Schwachstelle. Vereinfacht ausgedrückt, handelt es sich um ein äußerst populäres, von VMware entwickeltes quelloffenes Framework, das die Erstellung von Java-Applikationen auf Enterprise-Niveau erleichtert, indem es Features wie Abhängigkeitsinjektion, Datenbindung und Web-Frameworks sowohl für das Model-View-Controller-Prinzip (Spring MVC) als auch für reaktive Programmierungen (Spring WebFlux) unterstützt. Eines dieser Features besteht darin, dass HTTP-Requests auf spezifische Handler-Methoden abgebildet werden. Die Request-Handler-Methoden können wiederum Objekte instantiieren und deren Mitglieder automatisch mit Werten auffüllen, wobei Parameter verwendet werden, die über eben diese HTTP-Requests bereitgestellt werden. Dieses Feature wird als Parameterbindung bezeichnet.

Ein sehr viel älterer Bug, CVE-2010-1622, machte sich dieses Feature in Kombination mit der integrierten Java-Methode getClassLoader() zunutze, um das Tomcat-Objekt ClassLoader dazu zu bringen, eine JAR-Datei von einem Angriffsserver zu laden und dadurch eine Remote-Codeausführung zu ermöglichen. Spring hat diesen Angriffsvektor schnell beseitigt und eine Prüfung eingeführt, die getClassLoader() aus der Parameterbindung ausschließt. Allerdings eröffnete die Einführung von Modulen in Java 9 einen neuen Weg für den ClassLoader-Zugriff, sodass der Spring-Patch umgangen werden konnte. Dies war die Geburtsstunde von CVE-2022-22965. Im Gegensatz zu seinem Vorgänger funktioniert der Spring4Shell-Exploit in erster Linie über die Erzeugung einer Webshell (daher der Name) auf einem Zielserver, der Tomcat ausführt. Dies schreibt eine spezielle .jsp-Datei in den Webroot-Ordner, wodurch die Tomcat-Klasse AccessLogValve manipuliert wird. Die eigentliche Schwachstelle, d. h. die missbräuchliche Nutzung der Parameterbindungsfunktion, entspricht im Wesentlichen dem älteren Bug.

Wer ist betroffen?

Was die Folgen angeht, gibt es gute und schlechte Nachrichten. Die gute Nachricht lautet, dass nicht jede Java-Applikation, die das Spring-Framework nutzt, gleichermaßen anfällig ist. Vielmehr muss die Applikation folgende Bedingungen erfüllen:

• Sie verwendet JDK >= 9.0
• Sie wird in einer WAR-Datei (Web Application Archive) verpackt
• Sie wird in einem eigenständigen Servlet-Container bereitgestellt
  • Das Servlet weist entweder spring-webmvc oder spring-webflux als Abhängigkeit auf
• Installiert ist eine Spring-Framework-Version vor 5.2.20/5.3.18 (d. h. vor der Patch-Bereitstellung)

Die schlechte Nachricht: Die bösen Jungs (und Mädels) haben einen erheblichen Vorsprung. Das liegt zum einen daran, dass Einzelheiten zu der Schwachstelle und sogar ein PoC-Exploit geleakt wurden, und zwar schon vor der CVE-Veröffentlichung, die für das Frühjahrspatch vorgesehen war. Tatsächlich haben Honeypots einen Exploit der Spring4Shell-Schwachstelle bereits am 31. März festgestellt, nur zwei Tage nach der öffentlichen Meldung –  seitdem gibt es immer weitere Angriffe. Der ursprünglich veröffentlichte PoC-Code war speziell auf Spring-Applikationen zugeschnitten, die Tomcat als Servlet verwenden. Allerdings hat Spring seitdem bekanntgegeben, dass auch die Servlets Payara und Glassfish angreifbar sind.

Damit nicht genug. Wie Trend Micro berichtete, kommt Spring4Shell bereits in einer groß angelegten Kampagne zum Einsatz, die – passend zu Ostern – die Botnet-Malware Mirai wiederauferstehen lässt. Bekommt man da nicht geradezu nostalgische Anwandlungen?

Was kann ich tun?

Obwohl ein Update des Spring-Frameworks auf 5.2.20/5.3.18 oder höher ganz offensichtlich die beste Lösung ist, hat Spring in seinen Sicherheitsleitlinien zusätzlich eine Reihe von Eindämmungsstrategien beschrieben:

• Upgrade von Tomcat-Upgrade mindestens auf 8.5.78/9.0.62/10.0.20. Auch wenn dies die Sicherheitslücke nicht komplett schließt, blockiert es den Tomcat-Angriffsvektor und damit den am häufigsten verwendeten Exploitation-Ansatz.
• Ein Downgrade von Java auf einen Stand vorVersion 9 beseitigt zwar die Modul-bedingte Umgehungsmöglichkeit, die für CVE-2022-22965 anfällig macht. Allerdings dürfte die Verwendung einer veralteten Java-Version ganz eigene Sicherheitsgefahren mit sich bringen.
• Das exklusive Whitelisting der Parameter, deren Bindung Sie zulassen wollen, mittels setAllowedFields() ist ein möglicher Ansatz, genau wie das Blacklisting der von Exploits verwendeten Felder mittels setDisallowedFields(). Unglücklicherweise besteht bei der globalen Feldeinstellung das Risiko, dass sie auf lokaler Ebene überschrieben wird. Noch komplizierter wird die Sachlage dadurch, dass Sie bei diesen Eigenschaften – wenig intuitiv – die Groß-/Kleinschreibung beachten müssen. Leider wird auf diese Eigenheit in der Dokumentation nicht klar hingewiesen, was viele Abwehrmaßnahmen hinfällig macht. Das Problem ist unter CVE-2022-22968 erfasst und wird in den Spring-Framework-Versionen 5.2.21 und 5.3.19 „gefixt“. Aber wir wollen nicht undankbar sein. Wenigstens hat man sich die Behauptung verkniffen, dass alles „funktioniert wie beabsichtigt“.