0Day-Schwachstelle in Spring-Framework (CVE-2022-22965)

Am Mittwoch, den 30.03.22 haben Gerüchte über eine 0Day-Schwachstelle in Spring Framework, einem Framework zur Entwicklung von Java-Anwendungen, die Runde gemacht. Aufgrund der Verbreitung von Spring Framework wurden schnell Vergleiche mit der Schwachstelle Log4Shell (CVE-2021-44228) gezogen, die Ende 2021 die Sicherheitsbeauftragten weltweit in Atem gehalten hat. Die Schwachstelle wurde in Anlehnung an diese Erfahrungen Spring4Shell getauft, da auch diese nach ersten Analysen zur Ausführung beliebigen Programmcodes ausgenutzt werden kann.

Spring4Shell heißt jetzt CVE-2022-22965

Aufgrund der Veröffentlichung einer Schwachstelle in Spring Cloud zeitnah zur Veröffentlichung eines ersten Exploits für CVE-2022-22965, Problemen bei der Übersetzung der chinesischen Aufzeichnungen zum Exploit und der falschen Attributierung eines Commits zu Spring Core zur Schwachstelle CVE-2022-22965 wurde das eigentliche Problem erst umfassender analysiert, nachdem das Gerücht von einem neuen Log4Shell bereits großflächig die Runde gemacht hatte. Auch DFN-CERT hat frühzeitig über die mögliche Schwachstelle berichtet:
https://twitter.com/DFNCERT/status/1509255122462904320

Offizielle Informationen zur Schwachstelle wurden von VMware, die Spring 2009 übernommen haben, am 31.03.2022 veröffentlicht:
https://tanzu.vmware.com/security/cve-2022-22965

Mit der Veröffentlichung des CVE-Bezeichners CVE-2022-22965 und wenigen Hintergrundinformationen zur Schwachstelle konnte zumindest die allgemeine Aufregung etwas gemildert werden. Spring4Shell ist nicht das neue Log4Shell und kann mit der notwendigen Aufmerksamkeit, die eine 0Day-Schwachstelle bekommen sollte, die ("nur") unter bestimmten Bedingungen zur Ausführung beliebigen Programmcodes aus der Ferne ausgenutzt werden kann, behandelt werden.

Ausführung beliebigen Programmcodes nicht bedingungslos

Zumindest eine Quelle hat die neue Schwachstelle auf eine Umgehung der Schwachstelle CVE-2010-1622 zurückgeführt (http://blog.o0o.nu/2010/06/cve-2010-1622.html) und die Analyse des Exploits hat gezeigt, dass die Ausführung beliebigen Programmcodes anders als bei Log4Shell nicht ohne Weiteres möglich ist. Der bekannte Exploit funktioniert nur auf Systemen, die JDK9 oder höher einsetzen und nur, wenn die verwundbare Anwendung als traditionelles WAR (Web Application Archive) paketiert ist und auf Apache Tomcat als Servlet Container ausgeführt wird. Die eigentliche Schwachstelle dürfte auch unter anderen Bedingungen ausnutzbar sein, weitere Exploits sind bisher aber nicht bekannt.

Sicherheitsupdates und Mitigationen

Spring hat als Sicherheitsupdates zunächst Spring Framework 5.3.18 und 5.2.20 bereitgestellt und zusätzlich Spring Boot 2.5.12 und 2.6.6 veröffentlicht, die das Spring Framework enthalten:
https://github.com/spring-projects/spring-framework/releases/tag/v5.3.18
https://github.com/spring-projects/spring-framework/releases/tag/v5.2.20.RELEASE
https://github.com/spring-projects/spring-boot/releases/tag/v2.5.12
https://github.com/spring-projects/spring-boot/releases/tag/v2.6.6

Das Apache Tomcat Team hat auf die Veröffentlichung der Schwachstelle mit Apache Tomcat 10.0.20, 9.0.62 und 8.5.78 reagiert, um den Angriffsvektor von dieser Seite zu schließen. Auf diesem Weg könnten beispielsweise nicht mehr unterstützte Releases von Spring Framework abgesichert werden:
https://tomcat.apache.org/tomcat-10.0-doc/changelog.html#Tomcat_10.0.20_(markt)
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.62_(remm)
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.78_(markt)

Darüber hinaus hat Spring Hinweise zum Downgrade auf JDK8 und zu den Updates von Tomcat sowie generelle Workarounds bereitgestellt:
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement#suggested-workarounds

Betroffene Software, Mitigation über Drittanbieter und Detektion

Ähnlich wie Log4J wird auch das Spring Framework in zahlreichen anderen Anwendungen eingesetzt. Da der Exploit bisher nicht ohne Weiteres zu reproduzieren ist und die verwendeten Payloads an die jeweiligen Anwendungen angepasst werden müssen, sind einige Softwareanbieter dazu übergegangen, ihre Produkte prophylaktisch zu aktualisieren. Für den Bildungssektor relevant sind hier sicherlich Shibboleth und HISinOne. Beide Hersteller konnten keinen Exploit reproduzieren oder die Verwundbarkeit anderweitig bestätigen, haben aber Sicherheitsupdates oder Patches bereitgestellt:
https://hiszilla.his.de/hiszilla/show_bug.cgi?id=277384
https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631499/ReleaseNotes#4.1.6-(March-31,-2022)

Eine gute Zusammenstellung der Informationen zu verfügbaren Patches, Detektionstools und Mitigationsmöglichkeiten durch Sicherheitsprodukte wie Web Application Firewalls findet sich bei den Kolleg:innen von NCSC-NL:
https://github.com/NCSC-NL/spring4shell

Weltweite Scans nehmen zu, Ausblick

Laut Berichten von Honeypotbetreibern waren erste Scans und Exploitversuche, die dem allgemeinen Spring4Shell-Pattern folgen, bereits am 30.03.22 zu sehen. Genauer gescannt wurde dann spätestens ab 31.03.22 in der Frühe:
https://isc.sans.edu/forums/diary/Spring+Vulnerability+Update+Exploitation+Attempts+CVE202222965/28504/
https://twitter.com/Shadowserver/status/1509576257188638732

Es ist anzunehmen, dass aktuell eine internetweite Spring-Inventur gemacht wird, die zur massenhaften Ausnutzung der Schwachstelle führen kann, sollte es einen einfach umzusetzenden Exploit geben. Aktuell ist das noch nicht der Fall und die Unruhe um die Schwachstelle wird hauptsächlich für Awareness-Kampagnen genutzt.

In diesem Sinne:

• halten Sie Ihr Software-Verzeichnis aktuell
• prüfen Sie insbesondere auf Abhängigkeiten von bekannten OpenSource-Projekten
• patchen Sie spätestens, sobald das Ergebnis Ihrer Risikoabschätzung Ihre Nachtruhe beeinflusst