Neue Sicherheitslücken in Spring-Bibliotheken: Wie Sie feststellen können, ob Sie gefährdet sind und was zu tun ist

Vor Kurzem haben Spring-Bibliotheken, eine der beliebtesten Bibliotheken in der Java-Community, zwei Sicherheitslücken im Zusammenhang mit Remote Code Execution (RCE) aufgedeckt. Um Ihnen das Verständnis zu erleichtern, ob Sie durch eine der Sicherheitslücken gefährdet sind und welche Maßnahmen Sie ergreifen müssen, haben wir die bekannten Details für „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 Machbarkeitsnachweises eines Exploits gegen Spring Core (SC) enthielten, der die Remote-Code-Ausführung für alle Versionen von Spring Core ermöglicht, einschließlich der zuletzt veröffentlichten Version 5.3.17.

Welche Anwendungen sind gefährdet?

Derzeit wurde bestätigt, dass nur Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es wurde zwar nicht nachgewiesen, dass der Exploit gegen den Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht von Tomcat gehostet werden, erfolgreich ist, aber das schließt nicht aus, dass sich die Bedrohung dieser Frameworks in Zukunft als erfolgreich erweisen könnte.

Spring hat einen offiziellen veröffentlicht Aussage über die Sicherheitsanfälligkeit, in der klargestellt wird, dass die folgenden Bedingungen erfüllt sein müssen, um nach derzeitigem Verständnis der Sicherheitsanfälligkeit gefährdet zu sein:

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als traditionelles WAR verpackt (im Gegensatz zu einer ausführbaren Spring Boot-Jar)
• Spring-Webmvc- oder Spring-Webflux-Abhängigkeit
• Spring Framework-Versionen 5.3.0 bis 5.3.17, 5.2.0 bis 5.2.19 und ältere Versionen

Wie funktioniert die „Spring4Shell“ -Ausbeutung?

Die Ausnutzung basiert auf der Verwendung von „Data Binding“ (org.springframework.web.bind.WebDataBinder) in Anfragen, die Plain Old Java Objects (POJO) in der Methodensignatur verwenden:

Wobei die Foo-Klasse eine POJO-Klasse ist, die wie folgt definiert werden könnte. Beachten Sie, dass die eigentliche Klasse nicht wichtig ist, solange sie vom Class Loader geladen wird.

Wenn eine Anfrage mit einer solchen Methode bearbeitet wird, wird der Class Loader verwendet, um die Klasse aufzulösen. Der Class Loader ist dafür verantwortlich, Klassen zur Laufzeit zu laden, ohne dass zuerst alle möglichen Typen in den Speicher geladen werden müssen. Er findet heraus, welche JAR-Datei geladen werden muss, wenn eine neue Klasse verwendet wird.

Die aktuellsten und detailliertesten Informationen zu dieser Sicherheitsanfälligkeit finden Sie direkt von Spring auf ihrer Blogbeitrag, einschließlich möglicher Korrekturen oder Problemumgehungen.

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

Am 27. März 2022 veröffentlichte Cyber Kendra Details zu einer 0-tägigen Remote Code Execution (RCE) -Sicherheitslücke in Spring Cloud Functions, für die es keinen Patch gab. Der Sicherheitslücke wurde die ID zugewiesen CVE-2022-22963: Sicherheitslücke beim Zugriff auf Spring Expression-Ressourcen.

Welche Anwendungen sind gefährdet?

Die Sicherheitsanfälligkeit betraf Anwendungen unter den folgenden Bedingungen:

• JDK 9 oder neuer
• Spring Cloud Functions Version 3.1.6 (oder niedriger), 3.2.2 (oder niedriger) oder jede nicht unterstützte Version

Wie funktioniert die Ausbeutung?

Spring Cloud Function bietet Entwicklern die Möglichkeit, zu konfigurieren, wie das Routing über die Eigenschaft spring.cloud.function.routing-expression gehandhabt wird, was normalerweise über Konfiguration oder Code erfolgt. Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SPel) akzeptiert. Durch diese 0-Day-Sicherheitslücke haben wir herausgefunden, dass diese Eigenschaft über die HTTP-Header einer Anfrage gesetzt werden kann. Dies bedeutete, dass ein Angreifer SPel-Code direkt in seine HTTP-Anfrage an einen RoutingFunction-Endpunkt einbetten und so beliebigen Code ausführen konnte.

Welche Maßnahmen sollten Benutzer ergreifen, um das Risiko zu mindern?

Der Frühling hat veröffentlicht Versionen 3.1.7 und 3.2.3, um dieses Problem zu beheben, indem sie nicht zulassen, dass diese Eigenschaft über HTTP-Header gesetzt wird, wodurch die Sicherheitsanfälligkeit gemindert wird. Nach dem Upgrade auf eine der Versionen sind keine weiteren Schritte erforderlich.

Möchten Sie mehr darüber erfahren, wie wir Entwicklern helfen, sichereren Code zu schreiben? Eine Demo buchen oder lesen Sie unsere kostenlosen Richtlinien zur sicheren Codierung unter sicherer Code-Coach.

‍

Quellen

• 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/

‍