Spring4Shell: Was wir über die Java-RCE-Schwachstelle wissen

Sie wissen bereits über Spring4Shell Bescheid? Springen Sie direkt zum Abschnitt Behebung von Spring4Shell in diesem Blog oder lesen Sie unseren ausführlichen Überblick zu Spring4Shell, um zu erfahren, wie die Zero-Day-Remote-Code-Execution (RCE) funktioniert.

Früh am Morgen des 30. März (zumindest für mich) schrieb mein Kollege DeveloperSteve eine Nachricht in unseren Slack-Kanal: „Hey, haben Sie das gesehen?“ Es war eine „Vorwarnung“ vor einer „wahrscheinlichen“ Remote-Code-Execution (RCE) im äußerst beliebten Java-Framework Spring. Wie ich später erfuhr, hatte das Snyk-Sicherheitsteam sogar schon vorher mit der Untersuchung einer möglichen RCE in Spring begonnen, nachdem es einen inzwischen gelöschten Tweet gesehen hatte.

Die Details wirkten zunächst vage. Es gab einen Tweet mit Screenshots, der gelöscht worden war. Außerdem wurde auf einen Pull Request (PR) verwiesen, der, wie sich herausstellte, erstmals am 18. Februar eingereicht, aber erst am 29. März zusammengeführt worden war.

Verschiedene Parteien versuchten, den Spitznamen „Spring4Shell“ (oder manchmal einfach SpringShell) zu etablieren, während die Maintainer von Spring Core Kommentare zum PR hinzufügten, denen zufolge keine RCE bekannt sei.

Was zum Teufel war also los – und was ist jetzt los?

Was ist Spring4Shell?

Wenn Sie die Annotation @Autowired verwendet oder die Möglichkeiten der Konstruktor-Injektion genutzt haben, sind Sie im Spring-Ökosystem bereits mit Dependency Injection in Berührung gekommen.

In betroffenen Versionen lässt sich eine RCE erreichen, indem der ClassLoader mit einer sorgfältig zusammengestellten HTTP-POST-Anfrage manipuliert wird.

Derzeit ist der Exploit nachweislich nur mit einer Java Runtime Environment (JRE) ab Version 9 UND Tomcat ab Version 9 möglich.

Aus äußerster Vorsicht und um nicht auf Grundlage unvollständiger Informationen zu handeln, untersuchten die Sicherheitsforscher von Snyk die Situation im Laufe des 30. März.

Unser Fazit lautet derzeit: Es besteht eine glaubwürdige RCE-Bedrohung im Spring-Core-Paket spring-beans. Ob es uns gefällt oder nicht: Spring4Shell ist der offizielle Name. Das ist nachvollziehbar, da es im Spring-Ökosystem bereits ein legitimes Projekt namens Spring Shell gibt.

Wir werden Sie über unsere Schwachstellendatenbank weiterhin auf dem Laufenden halten, während sich die Lage entwickelt.

Behebung von Spring4Shell

Es wurden neue Versionen des Spring Framework veröffentlicht, bei denen der aktuelle Exploit nicht funktioniert. Dies sind die Versionen 5.2.20und 5.3.18. Und falls Sie mit Spring Boot arbeiten: Erst heute wurden die Versionen 2.5.12 und 2.6.6 veröffentlicht, die die Änderungen am Spring Framework und an spring-beans enthalten.

Hier finden Sie eine Liste der empfohlenen Maßnahmen zur Behebung, in absteigender Reihenfolge:

• Wenn Sie Spring Framework direkt verwenden, aktualisieren Sie auf Version 5.2.20 oder 5.3.18

• Wenn Sie Spring Boot verwenden, nutzen Sie Version 2.15.12 oder 2.6.6

• Wenn Sie Ihre Spring-Version derzeit nicht aktualisieren können, verwenden Sie eine JRE der Version 8 und/oder einen Tomcat-Container der Version 8, um das Problem einzudämmen.

Beachten Sie, dass es wahrscheinlich weitere Spring-Updates geben wird, wenn zusätzliche (und möglicherweise andere) Schwachstellen entdeckt werden. Das ist oft der typische Verlauf, wenn ein schwerwiegendes Problem wie dieses besonders viel Aufmerksamkeit erhält (man denke nur an Log4Shell).

Die Tools von Snyk wurden bereits aktualisiert und benachrichtigen Sie, wenn Ihr Projekt gefährdet ist!

Besuchen Sie Snyk, um sich für ein kostenloses Konto anzumelden. Anschließend können Sie Ihr Projekt testen – direkt dort oder über die Befehlszeile –, um festzustellen, ob es von Spring4Shell betroffen ist.

Wir planen, diesen Beitrag zu aktualisieren und ein PoC-Code-Repository zu erstellen, das die RCE mit JRE und Tomcat ab Version 9 demonstriert. Schauen Sie hier wieder vorbei, um Updates zu erhalten.

Die anfängliche Verwirrung rund um Spring4Shell

Einer der ersten Blogbeiträge, auf den unser Team in den frühen Morgenstunden des 30. März aufmerksam gemacht wurde, wurde inzwischen gelöscht. In diesem Beitrag wurde auf einen Tweet verwiesen, der ebenfalls gelöscht wurde. Trotz der doppelten Löschung gab es einen überprüfbaren Verweis auf einen Commit in Spring Core, der mit Deserialisierung zusammenhing (einer Java-Funktion, die schon früher zu RCEs geführt hat – Log4Shell, anyone?).

Im Kommentar zu diesem Commit heißt es:

1Since SerializationUtils#deserialize is based on Java's serialization
2mechanism, it can be the source of Remote Code Execution (RCE)
3vulnerabilities.

Im Laufe des Tages wurde immer mehr darüber spekuliert (ohne viele überprüfbare Fakten), dass es sich um eine RCE in Spring Core handeln könnte.

Weiter unten in den Kommentaren bestätigte ein Spring-Core-Committer eine andere Aussage: Dieser Commit habe nichts mit einer bekannten RCE zu tun.

Und tatsächlich: Wenn Sie sich den PR ansehen, zu dem der Commit gehört, sehen Sie, dass er erstmals am 18. Februar eröffnet wurde.

Unterm Strich: Während all das vor sich ging, war das Internet damit beschäftigt, dieses sich entwickelnde Problem mit einem anderen bekannten Problem in einem völlig anderen Projekt zu vermischen: Spring Cloud Function. Um nicht noch mehr Verwirrung zu stiften, gehe ich nicht näher auf diese Schwachstelle ein. Es genügt zu sagen: Wenn Sie etwas über Schwachstellen in Spring Cloud lesen, sind Sie bei der Suche nach Informationen zu Spring4Shell auf dem Holzweg (können wir dem bitte einen anderen Namen geben?).

Fazit

Schützen Sie sich vor Spring4Shell, indem Sie die oben empfohlenen Maßnahmen zur Behebung umsetzen. Melden Sie sich für ein kostenloses Snyk-Konto an, um mit der Behebung zu beginnen.