0
0
Equipes de segurança de todo o mundo tiveram outro choque na quinta-feira, quando a notícia da divulgação de um PoC para uma vulnerabilidade não autenticada de RCE zero-day no Spring Core, uma estrutura massivamente popular para a construção de aplicativos corporativos modernos baseados em Java, começou a circular online.
Graças a muitos pesquisadores de segurança, a situação é um pouco mais clara hoje em dia e ainda não há necessidade de pânico: ao contrário do Log4Shell, essa nova falha – sem CVE oficial e atualmente apelidada de Spring4Shell – parece ser explorável apenas em determinadas configurações.
O que sabemos sobre Spring4Shell até agora
Em primeiro lugar: o Spring4Shell não é a vulnerabilidade rce recentemente corrigida na biblioteca Spring Cloud Function (CVE-2022-22963).
De acordo com pesquisadores da Pretorian, o Spring4Shell é um bypass de um patch incompleto para cve-2010-1622, uma antiga vulnerabilidade de injeção de código no Spring Core Framework, e afeta o Spring Core na versão 9 ou posterior do Java Development Kit (JDK).
A existência da vulnerabilidade foi tornada pública quando um pesquisador de língua chinesa lançou o código de exploração poc para ele no GitHub e contou ao mundo sobre isso no Twitter (o post e os tweets foram excluídos logo depois).
Vários PoCs para Spring4Shell apareceram online desde então, e a eficácia de alguns deles foram confirmados.
“Em certas configurações, a exploração desse problema é simples, pois requer apenas que um invasor envie uma solicitação HTTP criada para um sistema vulnerável. No entanto, a exploração de diferentes configurações exigirá que o invasor faça pesquisas adicionais para encontrar cargas que serão eficazes”, observaram os pesquisadores pretorianos.
“A exploração requer um ponto final com o DataBinder ativado (por exemplo, uma solicitação POST que decodifica os dados do órgão de solicitação automaticamente) e depende muito do recipiente de servlet para a aplicação. Por exemplo, quando o Spring é implantado no Apache Tomcat, o WebAppClassLoader é acessível, o que permite que um invasor chame getters e setters para finalmente escrever um arquivo JSP malicioso em disco. No entanto, se o Spring for implantado usando o Embedded Tomcat Servlet Container, o carregador de classe é um LaunchedURLClassLoader que tem acesso limitado.”
Praetorian divulgou detalhes completos de sua exploração para a equipe de segurança da Primavera, e estão adiando a publicação de mais informações até que um patch esteja no lugar.
O que as equipes de segurança devem fazer?
Enquanto isso – e até que um patch seja fornecido e aplicativos vulneráveis sejam descobertos – LunaSec, Rapid7, Pretorian, Contrast Security e SANS ISC compartilharam análises da exploração poc, recursos para testá-lo (por exemplo, um aplicativo de teste vulnerável) e orientação de mitigação de riscos.
A Equipe de Ataque da Randori Security também lançou uma solicitação não-maliciosa que pode ser usada para testar a suscetibilidade à vulnerabilidade.
“Quando explorações de zero dias como o Spring4Shell vêm à tona, as organizações imediatamente são empurradas para o modo de pânico, lutando para determinar o raio potencial de explosão da vulnerabilidade. Dado o amplo uso do Apache Tomcat pelos desenvolvedores, esta vulnerabilidade de execução remota de código tem um enorme impacto potencial. As equipes de segurança precisam entender imediatamente quais softwares e dispositivos podem ser afetados e identificar se há dispositivos vulneráveis em seu ambiente. Isso pode ser extremamente desafiador porque muitas organizações lutam para manter um inventário atualizado de dispositivos, muito menos possuir a capacidade de detectar tipos de software e versões em execução nesses dispositivos”, diz Jeff Costlow, CISO da ExtraHop.
“Sabemos neste momento que a vulnerabilidade de execução remota de código está presente no quadro Java Spring, mas também pode estar presente em outras aplicações Java. Afeta o Tomcat, um conector muito comum que une um servidor web e o aplicativo Java. Suspeitamos que possa haver outras aplicações vulneráveis, mas estamos focando nos ataques que estão na natureza. Temos relatos de digitalização já para essa vulnerabilidade, então é apenas uma questão de tempo até que um PoC totalmente armado seja alavancado.”
ATUALIZAÇÃO (1º de abril de 2022, 01:00 a.m. PT):
Para obter mais notícias atualizadas sobre essa situação em evolução, confira este vídeo help net security – Spring4Shell: Novas informações e correções (CVE-2022-22965).
FONTE: HELPNET SECURITY