Neue Schwachstelle in der Spring-Bibliothek: Wie Sie feststellen können, ob Sie gefährdet sind, und wie Sie damit umgehen sollten

Vor kurzem hat die Spring-Bibliothek, eine der beliebtesten Bibliotheken in der Java-Community, zwei Schwachstellen im Zusammenhang mit der Remote-Code-Ausführung (RCE) veröffentlicht. Um zu verdeutlichen, ob Sie von einer dieser Schwachstellen betroffen sind und welche Maßnahmen Sie ergreifen sollten, haben wir die bekannten Details zu „Spring4Shell“ und „Spring Cloud Function“ kategorisiert.

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-Exploits für Spring Core (SC) enthielten. Dieser Exploit ermöglicht die Remote-Codeausführung 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 bekannt, dass Anwendungen, die auf Tomcat gehostet werden, von diesem neuen Exploit bedroht sind. Es gibt keine Hinweise darauf, dass der Exploit erfolgreich auf Embedded Tomcat Servlet Container oder andere Anwendungen, die nicht auf Tomcat gehostet werden, angewendet werden kann. Dies schließt jedoch nicht aus, dass diese Bedrohung in Zukunft auch auf diese Frameworks erfolgreich angewendet werden kann.

Offizielle Erklärung zu Schwachstellen im Frühjahr. Damit wird deutlich, dass nach dem derzeitigen Verständnis von Schwachstellen die folgenden Bedingungen erfüllt sein müssen, damit eine Schwachstelle entsteht.

• JDK 9 oder höher
• Apache Tomcat als Servlet-Container
• Als herkömmliche WAR-Datei gepackt (im Gegensatz zu Spring Boot-ausführbaren JAR-Dateien)
• Spring Web MVC oder Spring Web Flux 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 der Exploit „Spring4Shell“?

Dieser Missbrauch hängt davon ab, dass in Anfragen, die Plain Old Java Objects (POJO) in Methodensignaturen verwenden, „Datenbindung” (org.springFramework.web.bind.WebDataBinder) verwendet wird.

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

Wenn eine Anfrage mit dieser Methode verarbeitet wird, wird die Klasse mithilfe des Klassenladers aufgelöst. Der Klassenlader lädt die Klasse zur Laufzeit, ohne zuvor alle möglichen Typen in den Speicher vorzuladen. Wenn eine neue Klasse verwendet wird, wird entschieden, welche .jar-Datei geladen werden soll.

Aktuelle und detaillierte Informationen zu dieser Sicherheitslücke erhalten Sie direkt von Spring. Der Blogbeitragenthält mögliche Korrekturen oder Workarounds.

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

Am 27. März 2022 veröffentlichte CyberKendra Details zu einer Zero-Day-Sicherheitslücke in Spring Cloud Functions, die eine Remote-Code-Ausführung (RCE) ermöglicht und für die noch kein Patch verfügbar ist. Dieser Sicherheitslücke wurde die ID CVE-2022-22963zugewiesen : Sicherheitslücke beim Zugriff auf Spring-Ausdrucksressourcen.

Welche Anwendungen sind gefährdet?

Diese Schwachstelle betraf die Anwendung unter den folgenden Bedingungen.

• JDK 9 oder spätere Versionen
• Spring Cloud Functions Version 3.1.6 (oder früher), 3.2.2 (oder niedriger) oder nicht unterstützte Versionen

Wie funktioniert die Ausbeutung?

Mit Spring Cloud Function können Entwickler die Routing-Verarbeitung mithilfe der Eigenschaft spring.cloud.function.routing-expression konfigurieren. Dies geschieht in der Regel über Konfigurationen oder Code.Dies ist eine leistungsstarke Funktion, die die „Spring Expression Language“ (SpEL) akzeptiert. Diese Zero-Day-Sicherheitslücke hat gezeigt, dass diese Eigenschaft über den HTTP-Header einer Anfrage konfiguriert werden kann. Das bedeutet, dass Angreifer SpL-Code direkt in HTTP-Anfragen an den RoutingFunction-Endpunkt einbetten und beliebigen Code ausführen können.

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

In den im Frühjahr veröffentlichten Versionen 3.1.7 und 3.2.3 wurde dieses Problem behoben und die Schwachstelle gemindert, indem diese Eigenschaft nicht mehr über HTTP-Header konfiguriert werden kann. Nach dem Upgrade auf eine dieser Versionen sind keine weiteren Maßnahmen erforderlich.

Möchten Sie mehr darüber erfahren, wie Sie Entwickler dabei unterstützen können, sichereren Code zu schreiben?Buchen Sie eine Demo oder sehen Sie sich die kostenlosen Richtlinien für sicheres Codieren an : Secure Code Coach.

‍

情報源

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

‍