Kritische 0-Day-Sicherheitsanfälligkeit im Spring Framework, das in vielen Java-Projekten verwendet wird.

Im Modul Spring Core, das Teil des Spring Frameworks ist, wurde eine kritische 0-Day-Sicherheitslücke entdeckt, die einem nicht authentifizierten Remote-Angreifer ermöglicht, seinen Code auf dem Server auszuführen. Es ist noch unklar, wie katastrophal die Folgen des entdeckten Problems sein könnten und ob die Angriffe ebenso massenhaft sein werden wie im Fall der Schwachstelle in Log4j 2. Die Schwachstelle trägt den Codenamen Spring4Shell, ein CVE-Identifikator wurde jedoch bisher nicht vergeben. Im Spring Framework bleibt das Problem unbereinigt und im Internet sind bereits mehrere funktionierende Prototypen von Exploits verfügbar (1, 2, 3, 4). Das Problem wird verschärft durch die Tatsache, dass viele Unternehmens-Java-Anwendungen, die auf Spring Framework basieren, mit Root-Rechten ausgeführt werden und die Schwachstelle es ermöglicht, das System vollständig zu kompromittieren.

Nach Schätzungen wird das Spring Core-Modul in 74 % der Java-Anwendungen verwendet. Die Gefahr der Schwachstelle wird dadurch verringert, dass nur Anwendungen betroffen sind, die die Annotation „@RequestMapping“ bei der Anbindung von Request-Handlern und der Bindung von Webformularparametern im Format „name=value“ (POJO, Plain Old Java Object) verwenden, anstelle von JSON/XML.

Welche spezifischen Java-Anwendungen und Frameworks von dem Problem betroffen sind, ist noch unklar. Die Schwachstelle blockiert das Hinzufügen der Felder „class“, „module“ und „classLoader“ zur schwarzen Liste oder die Nutzung einer expliziten weißen Liste erlaubter Felder. Die Ausnutzung der Schwachstelle ist nur mit Java/JDK 9 oder einer neueren Version möglich. Das Problem ist auf eine Umgehung des Schutzes vor der Schwachstelle CVE-2010-1622 zurückzuführen, die im Spring Framework bereits 2010 behoben wurde und mit der Ausführung des classLoader-Handlers bei der Analyse von Anfrageparametern zusammenhängt.

Die Funktionsweise des Exploits besteht darin, eine Anfrage mit den Parametern „class.module.classLoader.resources.context.parent.pipeline.first.*“ zu senden, deren Verarbeitung zur Erstellung einer JSP-Datei im Wurzelverzeichnis von Apache Tomcat führt und den vom Angreifer angegebenen Code in diese Datei schreibt. Die erstellte Datei wird für direkte Anfragen verfügbar und kann als Web-Shell verwendet werden. Um eine anfällige Anwendung in der Umgebung von Apache Tomcat zu attackieren, reicht es aus, eine Anfrage mit bestimmten Parametern über das Tool curl zu senden. curl -v -d „class.module.classLoader.resources.context.parent.pipeline.first.pattern=code_einfügen_in_datei &class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp &class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT &class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar &class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=“ http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-SNAPSHOT/rapid7

Das vorliegende Problem in Spring Core sollte nicht mit den kürzlich entdeckten Schwachstellen CVE-2022-22963 und CVE-2022-22950 verwechselt werden. Das erste Problem betrifft das Paket Spring Cloud und wurde in den Versionen 3.1.7 und 3.2.3 behoben. Das zweite Problem ist in Spring Expression vorhanden und wurde in Spring Framework 5.3.17 behoben. Dies sind grundsätzlich andere Schwachstellen. Zu der neuen Schwachstelle haben die Entwickler des Spring Framework noch keine Stellungnahme abgegeben und kein Update veröffentlicht.

Als vorübergehende Maßnahme zum Schutz wird empfohlen, in dem Code eine schwarze Liste unzulässiger Anfrageparameter zu verwenden: import org.springframework.core.Ordered; import org.springframework.core.annotation.Order; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.annotation.ControllerAdvice; import org.springframework.web.bind.annotation.InitBinder; @ControllerAdvice @Order(10000) public class BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String[] denylist = new String[]{„class.“, „Class.“, „.class.“, „.Class.“}; dataBinder.setDisallowedFields(denylist); } }

Quelle: opennet.ru