This post is also available in: Português
No final de 2021, a internet passou por momentos complicados e intensos com a divulgação de uma vulnerabilidade extremamente severa que afetava a ferramenta Apache Log4j, usada em milhões de projetos das mais diversas áreas pelo mundo todo, apelidada de Log4Shell.
Ontem dia 30/03/22 um pesquisador de segurança chinês divulgou em seu twitter o código de um PoC que supostamente se explora uma vulnerabilidade que afeta o Spring – um dos frameworks mais utilizados no mundo para desenvolvimento de aplicações em Java- conseguindo atingir a execução remota de código não autenticado (0-click RCE).
As informações iniciais sobre a vulnerabilidade não foram claras, deixando uma séria de dúvidas, incluindo, versões que tinham sido afetadas, os métodos de exploração utilizados e os reais impactos gerados pela vulnerabilidade.
Outro fator que contribuiu para a confusão ao redor dessa vulnerabilidade foi o fato de que um dos primeiros blogs a divulgarem o vazamento, CyberKendra, acabou repassando informações sobre um commit que não possuía relação com esta vulnerabilidade, mas sim sobre outra vulnerabilidade descoberta durante o mesmo período e que afeta não o Spring Framework, mas sim o Spring Cloud Function (CVE-2022-22963).
Hoje, dia 31 de março no site oficial do Framework Spring, foram confirmadas não só a vulnerabilidade reportada pelo pesquisador chinês que afeta o Spring Core (CVE-2022-22965), mas também a vulnerabilidade que afeta o Spring Cloud Function (CVE-2022-22963).
Com a confirmação da vulnerabilidade pelos times de desenvolvimento, já temos patches oficiais e alguns workarounds que podem ser rapidamente aplicados nos serviços vulneráveis, que vão desde configurar regras para banir certas strings em WAFs até modificar o código fonte das funções/classes utilizadas na exploração da mesma.
A vulnerabilidade descoberta pelo pesquisador, após muitas discussões entre profissionais da área de segurança, foi analisada e deve ter um score CVSS v3.0 de 9.8 devido a facilidade de exploração e os impactos causados, ganhando assim o apelido de Spring4Shell. (mesmo sem relação alguma com a biblioteca log4j ou a vulnerabilidade log4shell).
Quem é afetado?
Até então, aplicações com as versões do Spring inferiores a 5.2.20/5.3.18 E usando o JDK versão 9 ou superior estão potencialmente vulneráveis.
Qualquer componente que atenda as condições acima E esteja usando @RequestMapping e parâmetros POJO são consideradas de fato vulneráveis e correm risco da exploração.
Aplicações atendendo os dois pontos acima E rodando Tomcat, são as com maior risco de serem exploradas, pois já existem exploits com certo grau de maturidade que funcionam contra aplicações rodando o Tomcat e as condições causadas pela nova vulnerabilidade facilitam a exploração.
Guia de Mitigação/Workarounds
Dia 31/03/22 foram lançadas as versões 5.3.18 e 5.2.20 do Spring Framework que corrigem a vulnerabilidade da CVE-2022-22965.
Usuários rodando versões vulneráveis dos serviços devem começar os esforços/patches em aplicações expostas a internet, que correm o maior risco de serem exploradas on-the-wild por scanners em massa, que logo nas primeiras horas da divulgação já foram detectados por organizações de Thread Intel pelo mundo todo. Caso a atualização não seja realizada de imediato, é possível mitigar até certo nível o risco de aplicações rodando atrás de WAFs utilizando filtros e restrições com as seguintes strings: “class.”, “Class.”, “.class.”, “.Class.”
Lembrando que caso sejam adicionadas essas regras, as aplicações devem ser testadas em um ambiente de desenvolvimento para garantir que o bloqueio dessas strings não interfira no funcionamento nominal das mesmas.
This post is also available in: Português
