Eles descobriram uma vulnerabilidade no Spring Framework

Recentemente, a notícia de que foi detectada uma vulnerabilidade crítica do tipo zero day no módulo Spring Core enviado como parte do Spring Framework, que permite que um invasor remoto não autenticado execute seu código no servidor.

Por algumas estimativas, o módulo Spring Core usado em 74% dos aplicativos Java. O perigo de vulnerabilidade é reduzido pelo fato de que apenas aplicativos que use a anotação "@RequestMapping" paraAo conectar manipuladores de solicitação e usar a ligação de parâmetro de formulário da Web no formato “name=value” (POJO, Plain Old Java Object), em vez de JSON/XML, eles são suscetíveis a ataques. Ainda não está claro quais aplicativos e estruturas Java são afetados pelo problema.

Essa vulnerabilidade, chamada "Spring4Shell", aproveita a injeção de classe que leva a um RCE completo e é muito séria. O nome "Spring4Shell" foi escolhido porque Spring Core é uma biblioteca onipresente, semelhante ao log4j que gerou a infame vulnerabilidade Log4Shell.

Acreditamos que os usuários que executam o JDK versão 9 e posterior são vulneráveis ​​a um ataque RCE. Todas as versões do Spring Core são afetadas.

Existem estratégias para mitigar o ataque e acreditamos que nem todos os servidores Spring são necessariamente vulneráveis, dependendo de outros fatores discutidos abaixo. Dito isso, atualmente recomendamos que todos os usuários apliquem mitigações ou atualizem se estiverem usando o Spring Core.

A exploração da vulnerabilidade só é possível ao usar Java/JDK 9 ou uma versão mais recente. A vulnerabilidade bloqueia a lista negra dos campos "class", "module" e "classLoader" ou o uso de uma lista branca explícita de campos permitidos.

O problema é devido à capacidade de contornar a proteção contra a vulnerabilidade CVE-2010-1622, Corrigido no Spring Framework em 2010 e associado à execução do manipulador classLoader ao analisar parâmetros de solicitação.

A operação do exploit é reduzida ao envio de um pedido ccom os parâmetros "class.module.classLoader.resources.context.parent.pipeline.first.", cujo processamento, ao utilizar "WebappClassLoaderBase", leva a uma chamada à classe AccessLogValve.

A classe especificada permite configurar o logger para criar um arquivo jsp arbitrário no ambiente raiz do Apache Tomcat e gravar o código especificado pelo invasor nesse arquivo. O arquivo criado está disponível para solicitações diretas e pode ser usado como um web shell. Para atacar um aplicativo vulnerável no ambiente Apache Tomcat, basta enviar uma solicitação com determinados parâmetros usando o utilitário curl.

O problema em consideração no Spring Core não deve ser confundido com vulnerabilidades recém-identificadas CVE-2022-22963 e CVE-2022-22950. O primeiro problema afeta o pacote Spring Cloud e também permite a execução remota de código (exploit). O CVE-2022-22963 foi corrigido nas versões Spring Cloud 3.1.7 e 3.2.3.

O segundo problema CVE-2022-22950 está presente no Spring Expression, pode ser usado para lançar ataques DoS e foi corrigido no Spring Framework 5.3.17. Essas são vulnerabilidades fundamentalmente diferentes. Os desenvolvedores do Spring Framework ainda não fizeram nenhuma declaração sobre a nova vulnerabilidade e não lançaram uma correção.

Como medida de proteção temporária, é recomendável usar uma lista negra de parâmetros de consulta inválidos em seu código.

Ainda não está claro quão catastróficas as consequências podem ser do problema identificado e se os ataques serão tão massivos quanto no caso da vulnerabilidade no Log4j 2. A vulnerabilidade recebeu o codinome Spring4Shell, CVE-2022-22965, e as atualizações do Spring Framework 5.3.18 e 5.2.20 foram lançadas para lidar com a vulnerabilidade.

Um patch já está disponível a partir de 31 de março de 2022 nas últimas versões lançadas do Spring 5.3.18 e 5.2.20. Recomendamos que todos os usuários atualizem. Para aqueles que não podem atualizar, as seguintes mitigações são possíveis:

Com base na postagem de Praetorian confirmando a presença de um RCE no Spring Core, a abordagem atualmente recomendada é corrigir o DataBinder adicionando uma lista negra de padrões de campo vulneráveis ​​necessários para exploração.

Enfim sim você está interessado em saber mais sobre isso sobre a nota, você pode verificar os detalhes no link a seguir.


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.