No módulo Spring Core, incluído no framework Spring Framework, foi identificada uma vulnerabilidade crítica 0-day que permite a um atacante remoto não autenticado executar seu código no servidor. Ainda não está claro quão catastróficas podem ser as consequências do problema identificado e se os ataques serão tão massivos quanto no caso da vulnerabilidade no Log4j 2. A vulnerabilidade foi batizada de Spring4Shell, mas ainda não foi atribuído um identificador CVE. No Spring Framework, o problema permanece não corrigido, e já estão disponíveis na rede vários protótipos funcionais de exploits (1, 2, 3, 4). A situação é agravada pelo fato de que muitas aplicações Java corporativas baseadas no Spring Framework são executadas com privilégios de root, e a vulnerabilidade permite comprometer completamente o sistema.
Estima-se que o módulo Spring Core seja usado em 74% das aplicações Java. O perigo da vulnerabilidade é atenuado pelo fato de que apenas as aplicações que utilizam a anotação "@RequestMapping" ao conectar manipuladores de solicitações e a vinculação de parâmetros de formulários web no formato "name=value" (POJO, Plain Old Java Object) estão vulneráveis, em vez de usar JSON/XML.
Ainda não está claro quais aplicações e frameworks Java estão sujeitos ao problema. A vulnerabilidade bloqueia a adição à lista negra dos campos "class", "module" e "classLoader", ou o uso de uma lista branca explícita de campos permitidos. A exploração da vulnerabilidade é possível apenas quando se utiliza Java/JDK 9 ou uma versão mais recente. O problema é causado pela possibilidade de contornar a proteção da vulnerabilidade CVE-2010-1622, corrigida no Spring Framework em 2010 e relacionada à execução do manipulador classLoader ao analisar os parâmetros da solicitação.
A exploração do exploit consiste no envio de uma solicitação com os parâmetros "class.module.classLoader.resources.context.parent.pipeline.first.*", cujo processamento resulta na criação de um arquivo jsp no ambiente raiz do Apache Tomcat e na gravação do código especificado pelo invasor nesse arquivo. O arquivo criado torna-se acessível para solicitações diretas e pode ser usado como um shell web. Para atacar uma aplicação vulnerável no ambiente Apache Tomcat, é suficiente enviar uma solicitação com parâmetros específicos usando a ferramenta curl. curl -v -d "class.module.classLoader.resources.context.parent.pipeline.first.pattern=código_para_inserir_no_arquivo &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
O problema em discussão no Spring Core não deve ser confundido com as vulnerabilidades recentemente identificadas CVE-2022-22963 e CVE-2022-22950. O primeiro problema afeta o pacote Spring Cloud e foi corrigido nas versões 3.1.7 e 3.2.3. O segundo problema está presente no Spring Expression e foi solucionado no Spring Framework 5.3.17. Trata-se de vulnerabilidades fundamentalmente diferentes. Os desenvolvedores do Spring Framework ainda não se pronunciaram sobre a nova vulnerabilidade nem publicaram uma correção.
Como uma medida provisória de proteção, é recomendável usar um blacklist de parâmetros de consulta inválidos no código: 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); } }
Fonte: opennet.ru
