{"id":103660,"date":"2022-03-31T09:36:38","date_gmt":"2022-03-31T07:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kriticheskaya-0-day-uyazvimost-v-spring-framework-primenyaemom-vo-mnogih-java-proektah"},"modified":"2022-03-31T09:36:38","modified_gmt":"2022-03-31T07:36:38","slug":"kriticheskaya-0-day-uyazvimost-v-spring-framework-primenyaemom-vo-mnogih-java-proektah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/kriticheskaya-0-day-uyazvimost-v-spring-framework-primenyaemom-vo-mnogih-java-proektah","title":{"rendered":"Vulnerabilit\u00e0 critica 0-day in Spring Framework, utilizzato in molti progetti Java","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nel modulo Spring Core, incluso nel framework Spring Framework, \u00e8 stata identificata una vulnerabilit\u00e0 critica zero-day che consente a un attaccante remoto non autenticato di eseguire codice sul server. Non \u00e8 ancora chiaro quanto gravi possano essere le conseguenze della vulnerabilit\u00e0 identificata e se gli attacchi saranno altrettanto massicci come nel caso della vulnerabilit\u00e0 in Log4j 2. La vulnerabilit\u00e0 \u00e8 stata soprannominata Spring4Shell, ma non \u00e8 stata ancora assegnata un'identificazione CVE. Nel Spring Framework il problema rimane irrisolto e gi\u00e0 circolano diversi prototipi funzionanti di exploit (1, 2, 3, 4). A rendere la situazione pi\u00f9 grave \u00e8 il fatto che molte applicazioni Java aziendali basate su Spring Framework vengono eseguite con privilegi di root e la vulnerabilit\u00e0 consente di compromettere completamente il sistema. <\/p>\n
Secondo alcune stime, il modulo Spring Core \u00e8 utilizzato nel 74% delle applicazioni Java. Il rischio di vulnerabilit\u00e0 \u00e8 mitigato dal fatto che solo le applicazioni che utilizzano l'annotazione @RequestMapping per connettersi ai gestori delle richieste e il binding dei parametri delle web form nel formato \"name=value\" (POJO, Plain Old Java Object) sono vulnerabili, invece di usare JSON\/XML. <\/p>\n
Quali specifiche applicazioni e framework Java siano colpiti dal problema non \u00e8 ancora chiaro. La vulnerabilit\u00e0 blocca l'aggiunta ai blacklist dei campi \"class\", \"module\" e \"classLoader\" o l'uso di una whitelist esplicita dei campi consentiti. L'exploitation della vulnerabilit\u00e0 \u00e8 possibile solo con Java\/JDK 9 o versioni pi\u00f9 recenti. Il problema \u00e8 causato dalla possibilit\u00e0 di eludere le protezioni della vulnerabilit\u00e0 CVE-2010-1622, corretta nel Spring Framework nel 2010, legata all'esecuzione del gestore classLoader durante l'analisi dei parametri della richiesta. <\/p>\n
Il funzionamento dell'exploit si riduce all'invio di una richiesta con i parametri \"class.module.classLoader.resources.context.parent.pipeline.first.*\", la cui elaborazione porta alla creazione di un file jsp nell'ambiente radice di Apache Tomcat e alla scrittura nel file del codice specificato dall'attaccante. Il file creato diventa accessibile per richieste dirette e pu\u00f2 essere utilizzato come web shell. Per attaccare un'applicazione vulnerabile in un ambiente Apache Tomcat, \u00e8 sufficiente inviare una richiesta con parametri specifici utilizzando lo strumento curl. curl -v -d \"class.module.classLoader.resources.context.parent.pipeline.first.pattern=codice_da_inserire_nel_file &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 <\/p>\n
Il problema considerato nel Spring Core non deve essere confuso con le vulnerabilit\u00e0 recentemente scoperte CVE-2022-22963 e CVE-2022-22950. Il primo problema riguarda il pacchetto Spring Cloud ed \u00e8 stato corretto nelle versioni 3.1.7 e 3.2.3. Il secondo problema \u00e8 presente in Spring Expression ed \u00e8 stato risolto in Spring Framework 5.3.17. Si tratta di vulnerabilit\u00e0 fondamentalmente diverse. Gli sviluppatori di Spring Framework non hanno ancora rilasciato alcuna dichiarazione sulla nuova vulnerabilit\u00e0 e non hanno pubblicato alcuna correzione. <\/p>\n
Come soluzione temporanea per la protezione, si consiglia di utilizzare nel codice una blacklist di parametri di richiesta non validi: 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); } } \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"