Neue Sicherheitslücke im Spring-Framework: Wie Sie feststellen können, ob Sie gefährdet sind, und was Sie tun können

Vor kurzem hat Spring, eine der beliebtesten Bibliotheken der Java-Community, zwei Sicherheitslücken im Zusammenhang mit der Remote-Code-Ausführung (RCE) offengelegt. Um Ihnen zu helfen, leichter zu verstehen, ob Sie einem Sicherheitsrisiko ausgesetzt sind und welche Maßnahmen Sie ergreifen sollten, haben wir die bekannten Details zu „Spring4Shell“ und „Spring Cloud Function“ aufgeschlüsselt.

Sicherheitslücke 1 – „Spring4Shell“ (CVE-2022-22965)

Am 29. März 2022 entdeckte die Community eine Reihe von Tweets, die Screenshots eines Proof-of-Concept für eine Sicherheitslücke in Spring Core (SC) enthielten. Diese Sicherheitslücke ermöglicht die Remote-Ausführung von Code in allen Versionen von Spring Core, einschließlich der kürzlich veröffentlichten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit ist nur für Anwendungen, die auf Tomcat gehostet werden, das Risiko dieser neuen Sicherheitslücke bestätigt. Obwohl Angriffe auf eingebettete Tomcat-Servlet-Container oder andere nicht auf Tomcat gehostete Anwendungen bislang nicht erfolgreich waren, schließt dies nicht aus, dass diese Frameworks in Zukunft erfolgreich für Angriffe genutzt werden könnten.

Im Frühjahr wurde eine offizielle Erklärung zu dieser Sicherheitslücke veröffentlicht. Nach dem derzeitigen Verständnis dieser Sicherheitslücke müssen die folgenden Bedingungen erfüllt sein, damit ein Angriff möglich ist:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als traditionelle WAR-Datei verpacken (im Gegensatz zu Spring Boot-ausführbaren JAR-Dateien)
• Spring-webmvc oder Spring-webflux Abhängigkeiten
• Spring Framework Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und frühere Versionen

Wie funktioniert die Sicherheitslücke „Spring4Shell“?

Die Schwachstelle hängt davon ab, dass in Anfragen, die gewöhnliche alte Java-Objekte (POJO) in der Methodensignatur verwenden, „Datenbindung“ (org.springframework.web.bind.Web.bind.WebDataBinder) verwendet wird:

Die Klasse Foo ist eine POJO-Klasse, die wie folgt definiert werden kann. Beachten Sie, dass die tatsächliche Klasse nicht wichtig ist, solange sie vom Klassenlader geladen werden kann.

Wenn eine Anfrage auf diese Weise verarbeitet wird, wird der Klassenlader zum Parsen der Klasse verwendet. Der Klassenlader ist dafür zuständig, Klassen zur Laufzeit zu laden, ohne zuvor alle möglichen Typen in den Speicher vorzuladen. Er berechnet, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.

Aktuelle und detaillierte Informationen zu dieser Sicherheitslücke finden Sie direkt auf Spring in einem Blogbeitrag, einschließlich möglicher Korrekturen oder Workarounds.

Sicherheitslücke 2 – Spring Cloud-Funktion (CVE-2022-22963)

Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer noch ungeschlossenen Zero-Day-Sicherheitslücke in Spring Cloud Functions, die eine Remote-Code-Ausführung (RCE) ermöglicht. Die Sicherheitslücke wurde mit der ID CVE-2022-22963versehen : Spring Expression Resource Access Vulnerability.

Welche Anwendungen sind gefährdet?

Die Sicherheitslücke betrifft Anwendungen unter folgenden Bedingungen:

• JDK 9 oder höher
• Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede andere nicht unterstützte Version

Wie funktioniert Ausbeutung?

Spring Cloud Function ermöglicht es Entwicklern, die Verarbeitung von Routen über die Eigenschaft spring.cloud.function.routing-expression zu konfigurieren, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine Art der die Leistungsfähigkeit der „Spring Expression Language“ (SpEL) nutzt. Durch diese 0-Tage-Sicherheitslücke haben wir erfahren, dass diese Eigenschaft über den HTTP-Header der Anfrage festgelegt werden kann, was bedeutet, dass Angreifer SpEL-Code direkt in die HTTP-Anfrage ihres RoutingFunction-Endpunkts einbetten und so beliebigen Code ausführen können.

Welche Maßnahmen sollten Nutzer ergreifen, um das Risiko zu verringern?

Im Frühjahr wurden die Versionen 3.1.7 und 3.2.3 veröffentlicht, die dieses Problem beheben, indem sie die Einstellung dieser Eigenschaft über HTTP-Header nicht zulassen und so die Sicherheitslücke schließen. Nach dem Upgrade auf eine dieser Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern dabei helfen, sichereren Code zu schreiben?Buchen Sie eine Demo oder sehen Sie sich unseren kostenlosen Leitfaden für sicheres Programmieren an : Security Code Coach.

‍

Quelle

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍