Neue Java-Security-Lücke sorgt für Wirbel

Erst Log4Shell dann Spring4Shell? Bereits Ende des vergangenen Jahres sorgte die kritische Zero-Day-Lücke Log4Shell in der verbreiteten Java-Bibliothek Log4j für große Aufregung in der Security-Szene. Nun ist offenbar eine neue Schwachstelle im Java-Umfeld aufgetaucht: eine Zero-Day-Sicherheitslücke namens Spring4Shell, die Remote-Code-Ausführung (Remote Code Execution) über das Spring-Framework ermöglicht.

Spring zählt zu den beliebtesten Open-Source-Frameworks für die Entwicklung von Java-Anwendungen. Deshalb wächst auch hier die Sorge, dass die Lücke weitreichende Auswirkungen in der Unternehmens-IT haben könnte. Die Schwachstelle kam ans Licht, als ein chinesischer Entwickler ein Proof-of-Concept (PoC) Exploit auf GitHub veröffentlichte und dann entfernte. Dies führte zu weitreichenden Spekulationen über die Folgen.

Die Spring-Entwickler haben nun die Existenz der neuen Schwachstelle bestätigt und die Versionen 5.3.18 und 5.2.20 veröffentlicht, um sie zu beheben. In der offiziellen Liste der Sicherheitslücken wird sie als CVE-2022-22965 geführt und als kritisch eingestuft. Spring Boot, ein verwandtes Tool zur Paketierung von vorgefertigten, eigenständigen Spring-basierten Anwendungen, erhielt ebenfalls die Updates 2.6.6 und 2.5.12.

Was wir über Spring4Shell wissen

Spring4Shell betrifft Spring MVC- und Spring WebFlux-Anwendungen, die als WAR-Archive verpackt sind, auf Apache Tomcat-Servern bereitgestellt werden und auf JDK 9 und höher laufen. Da WAR ein beliebtes Format für die Verpackung von Java-Anwendungen und Tomcat einer der beliebtesten Java-Webserver is,t und JDK 9 schon 2017 veröffentlicht wurde, könnte die Anzahl der betroffenen Anwendungen erheblich sein.

Die Entwickler weisen darauf hin, dass die Schwachstelle allgemeiner Natur ist und es andere Möglichkeiten geben könnte, sie auszunutzen, auch auf Spring Boot mit eingebettetem Tomcat. Außerdem warnen sie davor, dass die von anderen Sicherheitsexperten vorgeschlagenen Umgehungslösungen, die das Setzen von disallowedFields auf WebDataBinder durch einen @ControllerAdvice beinhalten, einige Schlupflöcher lassen könnten.

"Um den Workaround auf eine ausfallsicherere Art und Weise anzuwenden, könnten Anwendungen den RequestMappingHandlerAdapter erweitern, um den WebDataBinder am Ende nach allen anderen Initialisierungen zu aktualisieren", so die Entwickler. "Um dies zu tun, kann eine Spring Boot-Anwendung eine WebMvcRegistrations-Bean (Spring MVC) oder eine WebFluxRegistrations-Bean (Spring WebFlux) deklarieren."

Schwachstelle in Spring Cloud-Funktion

Neben Spring4Shell wurde auch eine Sicherheitslücke in Spring Cloud Function entdeckt. Das Gefahrenpotenzial der Lücke wird jedoch unterschiedlich bewertet. VMware beschreibt die Schwachstelle als mittelschweres Problem beim Ressourcenzugriff. Andere Forscher wiesen jedoch darauf hin, dass sie tatsächlich Remote Code ausführen kann. Deshalb sei sie gefährlicher und sollte als hochgradig eingestuft werden.

Die Sicherheitslücke steht im Zusammenhang mit einer Funktion namens Spring Expression Language (SpEL) und wurde in Spring Cloud Function 3.1.7 und 3.2.3 gepatcht. Spring Cloud ist ein Framework, das viele der Funktionen implementiert, die zur Entwicklung von Cloud-Anwendungen für verteilte Systeme benötigt werden.

Das Framework bietet Unterkomponenten für die Integration mit bestimmten öffentlichen Clouds wie Azure, AWS und Alibaba sowie die Implementierung allgemeinerer Konzepte wie Konfigurationsmanagement, Service Discovery, Circuit Breakers, intelligentes Routing, verteilte Sitzungen, Cluster-Status und mehr. Eine dieser Komponenten ist Spring Cloud Function. Sie zielt darauf ab, ein einheitliches Programmiermodell über Serverless-Anbieter hinweg bereitzustellen und es Entwicklern zu ermöglichen, Geschäftslogik über Funktionen zu implementieren.

Verwirrung über Deserialisierung und Auswirkungen

Einige der frühen Berichte zogen Parallelen zu Log4Shell, da Spring ein sehr beliebtes Entwicklungsframework für Desktop- und webbasierte Java-Anwendungen ist. Diese Berichte enthielten jedoch auch etwas widersprüchliche Informationen, die sich auf einen kürzlich erfolgten Spring-Code-Commit zur Ablehnung von SerializationUtils#deserialize bezogen, einer Funktion, von der seit langem bekannt ist, dass sie bei der Verwendung von Objekten aus nicht vertrauenswürdigen Quellen unsicher ist. Die Spring-Entwickler mussten Kommentare im Code-Tracker veröffentlichen, um klarzustellen, dass der Code-Commit in keinem Zusammenhang mit neuen Schwachstellen stand.

In anderen frühen Berichten wurde auch die Deserialisierung erwähnt, was Zweifel aufkommen ließ, ob es sich tatsächlich um eine Schwachstelle in Spring handelt oder um die falsche Verwendung einer als unsicher bekannten Funktion durch den PoC-Autor. Außerdem war nicht klar, wie hoch die Anforderungen an die Ausnutzung der Schwachstelle waren und wie viele reale Anwendungen sie erfüllten.

Auch jetzt ist nicht klar, wie viele Anwendungen verwundbar sind. Das Spring-Advisory enthält nicht viele Details über die Quelle dieser Schwachstelle, doch mehrere Sicherheitsunternehmen, die den ursprünglichen PoC analysiert haben und in der Lage waren, darauf aufbauend funktionierende Exploits zu erstellen, haben in ihren Advisories weitere Informationen bereitgestellt.

Angreifer ändern das Ziel der Protokollierungsfunktion

Experten des Sicherheitsunternehmens Praetorian beschrieben die Schwachstelle als Umgehung einer viel älteren Schwachstelle, die als CVE-2010-1622 verfolgt wird, und erklärten, dass für die Ausnutzung ein Endpunkt mit aktiviertem DataBinder erforderlich ist, was stark vom Servlet-Container für die Anwendung abhängt.

Forscher von Sonatype merkten in ihrer Analyse an, dass der PoC eine bisher unbekannte Methode zur RCE ausnutzt und bestätigten die Verbindung zu CVE-2010-1622. Sie sagten, dass das zugrundeliegende Problem hinter dieser Schwachstelle wieder ausnutzbar wird, wenn es mit JDK9 verwendet wird.

Die Fachleute des Sicherheitsunternehmens Contrast SecuritySecurity kommentierten: "Bei der Erstellung eines Objektgraphen, der dem Entwickler zur Verfügung gestellt wird, achtet Spring besonders darauf, dass Angreifer keine Kontrolle über Teile der Class, ProtectionDomain und ClassLoader der zu erstellenden Instanz haben". Leider hätten die Änderungen am Class-Objekt in Java 9 dazu geführt, dass die Prüfungen von Spring nicht mehr ausreichend waren. Alles zu Security auf CIO.de

Insbesondere die Einführung von Class#getModule(), das von den bisherigen Prüfungen nicht abgedeckt werde, eröffne einen neuen Weg, das Problem auszunutzen. Der Angriff funktioniert wie folgt: Die Angreifer ändern das Ziel der Protokollierungsfunktion des ClassLoaders, um eine neue, bösartige JSP-Datei zu erstellen. Mit ein paar Tricks schreiben sie dann bösartigen Code in die JSP-Datei und schaffen so eine Hintertür, über die sie Systembefehle aufrufen.

"Das ist schlimm, scheint aber nicht so schlimm wie Log4Shell zu sein", so Forscher des auf DevOps spezialisierten Unternehmens JFrog auf Twitter. "Nach unseren Recherchen sind nicht alle Spring-Apps verwundbar (nur Apps, die Request-Parameter an ein POJO binden) und die beliebteste JDK-Version (8) ist nicht betroffen (nur 9+ sind betroffen)."

Die JFrog-Forscher haben ein kostenloses Tool entwickelt und veröffentlicht, mit dem Benutzer ihre Java-Anwendungen scannen können, um festzustellen, ob sie möglicherweise verwundbar sind. Die Bedingung, dass Spring-Endpunkte Anforderungsparameter an einen nicht-primitiven (Java Bean) Typ binden, dürfte selten sein, was die meisten Anwendungen in der Praxis nicht ausnutzbar machen könnte, heißt es in der Beschreibung des Tools.

Nach Meinung von Sebastian Schmerl, Director Security Services EMEA bei Arctic Wolfist ist Spring4Shell "kein Log4Shell 2.0, weil die Standardkonfiguration nicht anfällig ist. Das bedeutet, dass die meisten Installationen unbedenklich sein sollten." Dennoch müssten Sicherheitsteams schnellstmöglich herausfinden, ob sie bezüglich CVE-2022-2296 gefährdet sind.

"Spring4Shell zeigt erneut, wie wichtig ein gutes IT-Asset- und Konfigurationsmanagement sowie ein Vulnerability-Management für Unternehmen sind", betont der Experte.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.