{"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\/es\/blog\/news\/kriticheskaya-0-day-uyazvimost-v-spring-framework-primenyaemom-vo-mnogih-java-proektah","title":{"rendered":"Una vulnerabilidad cr\u00edtica de d\u00eda cero en Spring Framework, utilizado en muchos proyectos de Java","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En el m\u00f3dulo Spring Core, proporcionado como parte del marco Spring Framework, se ha identificado una vulnerabilidad cr\u00edtica de d\u00eda cero que permite a un atacante remoto no autenticado ejecutar su c\u00f3digo en el servidor. A\u00fan no est\u00e1 claro cu\u00e1n catastr\u00f3ficas pueden ser las consecuencias del problema identificado y si los ataques ser\u00e1n tan masivos como en el caso de la vulnerabilidad de Log4j 2. La vulnerabilidad ha sido apodada Spring4Shell, pero a\u00fan no se ha asignado un identificador CVE. En el Spring Framework, el problema permanece sin soluci\u00f3n y ya hay varios prototipos de exploits funcionales disponibles en la red (1, 2, 3, 4). El problema se agrava debido a que muchas aplicaciones empresariales de Java basadas en Spring Framework se ejecutan con privilegios de root y la vulnerabilidad permite comprometer completamente el sistema. <\/p>\n
Seg\u00fan algunas estimaciones, el m\u00f3dulo Spring Core se utiliza en el 74% de las aplicaciones Java. El riesgo de vulnerabilidad se reduce ya que solo las aplicaciones que utilizan la anotaci\u00f3n '@RequestMapping' al conectar manejadores de solicitudes y enlazar par\u00e1metros de formularios web en el formato 'name=value' (POJO, Plain Old Java Object), en lugar de utilizar JSON\/XML, est\u00e1n expuestas. <\/p>\n
No est\u00e1 claro qu\u00e9 aplicaciones y marcos de Java est\u00e1n afectados por este problema. La vulnerabilidad impide a\u00f1adir a la lista negra los campos 'class', 'module' y 'classLoader', o usar una lista blanca expl\u00edcita de campos permitidos. La explotaci\u00f3n de la vulnerabilidad solo es posible si se utiliza Java\/JDK 9 o una versi\u00f3n m\u00e1s reciente. El problema es causado por una v\u00eda de escape a la protecci\u00f3n contra la vulnerabilidad CVE-2010-1622, corregida en Spring Framework ya en 2010 y relacionada con la ejecuci\u00f3n del manejador classLoader al analizar los par\u00e1metros de la solicitud. <\/p>\n
El funcionamiento del exploit consiste en enviar una solicitud con los par\u00e1metros 'class.module.classLoader.resources.context.parent.pipeline.first.*', cuyo procesamiento lleva a la creaci\u00f3n de un archivo jsp en el entorno ra\u00edz de Apache Tomcat y la escritura en ese archivo del c\u00f3digo especificado por el atacante. El archivo creado se vuelve accesible para solicitudes directas y puede ser utilizado como un web shell. Para atacar una aplicaci\u00f3n vulnerable en el entorno de Apache Tomcat, es suficiente enviar una solicitud con ciertos par\u00e1metros utilizando la utilidad curl. curl -v -d 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=c\u00f3digo_para_insertar_en_archivo&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
El problema en cuesti\u00f3n en Spring Core no debe confundirse con las vulnerabilidades detectadas recientemente, CVE-2022-22963 y CVE-2022-22950. El primer problema afecta al paquete Spring Cloud y ha sido solucionado en las versiones 3.1.7 y 3.2.3. El segundo problema est\u00e1 presente en Spring Expression y se corrigi\u00f3 en Spring Framework 5.3.17. Se trata de vulnerabilidades fundamentalmente diferentes. Los desarrolladores de Spring Framework a\u00fan no han hecho declaraciones sobre la nueva vulnerabilidad ni han publicado correcciones. <\/p>\n
Como medida temporal de protecci\u00f3n, se recomienda utilizar en el c\u00f3digo una lista negra de par\u00e1metros de solicitud no permitidos: 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 Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"