Expertentipps

Spring4Shell – so gefährlich ist die neue Java-Lücke

Das Spring4Shell-Patching kommt nur langsam voran, doch die Auswirkungen scheinen im Vergleich zu Log4Shell eher gering zu sein. Trotzdem sollten Unternehmen prüfen, welche Anwendungen anfällig sind.
Von  und
CSO | 07. April 2022 14:45 Uhr
Lesen Sie, welche Risiken die Java-Schwachstelle Spring4Shell mit sich bringt und wie Sie Ihre Anwendungen schützen.
Lesen Sie, welche Risiken die Java-Schwachstelle Spring4Shell mit sich bringt und wie Sie Ihre Anwendungen schützen.
Foto: Lightspring - shutterstock.com

In der vergangenen Woche sorgte die neue Java-Schwachstelle Spring4Shell für Unruhe in der Sicherheitsbranche. Dabei handelt es sich um eine kritische Sicherheitslücke in Spring Framework,- eines der beliebtesten Entwicklungs-Frameworks für Java-Anwendungen. Die Schwachstelle ermöglicht das Ausführen von Remotecode (RCE). Obwohl bereits Ausnutzungsversuche in freier Wildbahn beobachtet wurden, scheint das Tempo beim Patchen langsam zu sein.

Nach Angaben von Sonatype, dem Unternehmen, das mit Maven Central das größte Repository für Java-Komponenten und -Bibliotheken verwaltet, sind seit der Bestätigung der Schwachstelle am 31. März nur 80 Prozent der Spring-Downloads für anfällige Versionen durchgeführt worden. Maven Central ist mit vielen Entwicklungs-Ttools integriert, so dass die Daten darauf hindeuten, dass die Entwickler es nicht eilig haben, ihre Spring-Instanzen zu aktualisieren.

Das bedeutet jedoch nicht, dass Anwendungen, die mit ungepatchten Versionen von Spring arbeiten, zwangsläufig verwundbar sind. Damit die bekannten Exploits funktionieren, müssen die Anwendungen mehrere Bedingungen erfüllen, die in Standardkonfigurationen nicht üblich sind. Abhilfestrategien können auch angewendet werden, ohne das Framework selbst zu aktualisieren.

Voraussetzungen für den Spring4Shell-Exploit

Neben dem ursprünglichen Proof-of-Concept-Exploit, der öffentlich bekannt wurde, bevor ein Patch verfügbar war, kursieren mehrere Varianten. Sicherheitsforscher von Akamai beobachteten Angriffe mit Varianten, die sowohl GET- als auch POST-Anfragen (=HTTP-Anfragemethoden) verwenden, wobei die GET-Variante effizienter ist, da sie es Angreifern ermöglicht, die Sicherheitslücke mit nur einer Anfrage an den Server auszunutzen. Darüber hinaus verwendet eine Variante des Exploits eine Technik zur Codeverschleierung, mit der Eingabefilter oder Erkennungsregeln von Web Application Firewalls (WAFs) umgangen werden sollen.

Das CERT-Team der Deutschen Telekom gab bekannt, dass seine Honeypot-Server seit dem 31. März von Exploit-Versuchen heimgesucht wurden. Das Bedrohungsanalyse-Team von Microsoft meldete ebenfalls eine geringe Anzahl von Angriffsversuchen auf die Cloud-Dienste des Unternehmens. In der Zwischenzeit hat die U.S. Cybersecurity and Infrastructure Agency (CISA) am Montag Spring4Shell, auch bekannt unter der Bezeichnung CVE-2022-22965, in ihren Known Exploited Vulnerabilities Catalog aufgenommen.

Die Spring4Shell-Schwachstelle wirkt sich nur auf Anwendungen aus, die unter Java Development Kit (JDK9) laufen, das eine neue API namens class.getModule eingeführt hat. Diese API bietet Angreifern einen alternativen Pfad zu ClassLoader, einem gefährlichen Attribut, dessen Parameter nicht von außen kontrolliert werden sollten. Spring verfügte seit 2010 über Code, der den Zugriff auf dieses Attribut blockiert. Damals wurde eine ähnliche Schwachstelle gepatcht, aber die Blocklist enthielt nicht die in JDK9 hinzugefügte getModule-API. Glücklicherweise ist JDK8, das die Ausnutzung dieser Schwachstelle nicht zulässt, nach wie vor die am häufigsten verwendete Laufzeitumgebung für Java-Anwendungen.

Zwei weitere Voraussetzungen für einen Angriff sind, dass die anfällige Anwendung unter dem Apache Tomcat-Webserver ausgeführt und als WAR-Paket (Web Application ARchive) bereitgestellt werden muss. Doch viele Spring-Anwendungen werden mit Spring Boot erstellt, einem verwandten Tool, das die Erstellung von eigenständigen Anwendungen ermöglicht und standardmäßig das ausführbare JAR-Format (Java ARchive) verwendet. Diese Anwendungen sind nicht verwundbar.

Um angreifbar zu sein, muss eine Anwendung außerdem den Datenbindungsmechanismus von Spring Framework verwenden. Dieser ermöglicht es Entwicklern, HTTP-Anfrageparameter an ein Java-Objekt zu binden, um angreifbar zu sein. Nicht alle Anwendungen nutzen diese Funktion. Eines der auf der Spring-Website veröffentlichten grundlegenden Tutorials für die Bearbeitung von Formular-Eingaben ist jedoch angreifbar. Entwickler, die diesem Referenzcode folgten, könnten die Schwachstelle eingeführt haben.

Erkennen von Anwendungen, die für Spring4Shell anfällig sind

Mehrere Sicherheitsforscher und Unternehmen haben kostenlose Tools veröffentlicht, mit deren Hilfe anfällige Anwendungen entweder lokal oder aus der Ferne erkannt werden können. Forscher des Cybersecurity-Unternehmens JFrog haben einen Python-Scanner veröffentlicht, der mögliche Instanzen von Datenbindung in WAR- und JAR-Dateien finden kann. Der IT-Spezialist Jan Schaumann veröffentlichte einen ähnlichen Dateisystem-Scanner in Form eines Linux-Shell-Skripts, und der Entwickler Hilko Bengen veröffentlichte einen in Go geschriebenen Scanner.

Microsoft weist darauf hin, dass eine Live-Anwendung aus der Ferne getestet werden kann, indem die folgende Anfrage mit dem Befehlszeilen-Ttool curl ausgeführt wird: curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

Der Security-Forscher Florian Roth hat YARA-Regeln veröffentlicht, die von Verteidigern verwendet werden können, um ein System auf eine potenziell erfolgreiche Kompromittierung über Spring4Shell zu überprüfen. Die Regeln erkennen bösartige JSP-Backdoor-Dateien, die von den bekannten Exploits abgelegt werden.

Das CERT Coordination Center an der Carnegie Mellon University führt eine Liste von Anbietern, die bestätigt haben, dass sie anfällige Produkte haben, sowie von anderen, die noch an der Untersuchung arbeiten. Ein französischer Forscher, bekannt als SwitHak, hat außerdem mit Hilfe der Infosec-Community eine Liste von Herstellerantworten und -hinweisen zu Spring4Shell zusammengestellt.

Abhilfemaßnahmen für Spring4Shell

Die beste Möglichkeit, diese Schwachstelle zu entschärfen, besteht darin, Spring Framework auf Version 5.3.18 oder 5.2.20 und Spring Boot auf Version 2.6.6 oder 2.5.12 zu aktualisieren. Wenn eine Aktualisierung des Frameworks jedoch nicht sofort möglich ist, gibt es alternative Umgehungsmöglichkeiten.

So können Entwickler beispielsweise eine @ControllerAdvice hinzufügen, die Zuweisungen zu einigen der internen ClassLoader-Felder in ihren Anwendungen blockiert. Spring-Entwickler weisen jedoch darauf hin, dass dies in manchen Situationen nicht völlig ausfallsicher ist, und geben in ihrem Advisory weitere Richtlinien an.

Eine weitere vorübergehende Abhilfemaßnahme besteht darin, Tomcat auf Version 10.0.20, 9.0.62 oder 8.5.78 zu aktualisieren, die als Reaktion auf Spring4Shell veröffentlicht wurden. Die derzeit im Umlauf befindlichen Exploits nutzen die Tomcat-spezifische Funktion AccessLogValve, um beliebige Dateien zu überschreiben und Backdoors auf Servern einzurichten. Die Tomcat-Updates können zwar den aktuellen Exploit lahmlegen, dies sollte aber nicht als langfristige Lösung betrachtet werden. Die Gefahr besteht, dass Angreifer alternative Angriffsvektoren entdecken könnten.

Fazit

Trotz der Namensähnlichkeit mit Log4Shell - einer kritischen Sicherheitslücke in der Java-Protokollierungsbibliothek log4j - scheint Spring4Shell nicht die gleichen weitreichenden Auswirkungen zu haben. Der Grund liegt vor allem in den höheren Anforderungen an die Ausnutzung, die weniger Anwendungen erfüllen. Dennoch handelt es sich um eine schwerwiegende Sicherheitslücke, die wahrscheinlich noch lange in Unternehmensanwendungen zu finden sein wird. Den Daten von Sonatype zufolge betreffen fast 40 Prozent der log4j2-Downloads von Maven Central auch drei Monate nach der Ankündigung von Log4Shell noch anfällige Versionen der Bibliothek.

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

Lucian Constantin arbeitet als Korrespondent für den IDG News Service.
Julia Mutzbauer ist  Editor bei CSO. Ihr Schwerpunkt ist Security.