spring-shell-vuln

Spring4Shell: vulnerabilidade de RCE no Spring core

---

A Spring confirmou a RCE no Spring Framework. A equipa acabou de publicar a declaração juntamente com os guias de mitigação para o problema. Agora, esta vulnerabilidade pode ser rastreada como CVE-2022-22965.

Existem algumas informações sobre a vulnerabilidade Spring4Shell e partilhámos os detalhes no artigo Spring4Shell: Details and Exploit. Além disso, a equipa de segurança da Praetorian confirmou que o Spring Core no JDK9+ é vulnerável a execução remota de código devido a um bypass para CVE-2010-1622.

Inicialmente, tudo começou a 30 de março; a primeira notificação da vulnerabilidade foi indiciada pelo líder da equipa KnownSec 404, Heige. Ele tweetou com a mensagem de aviso "Spring core RCE （JDK >=9" juntamente com a imagem do PoC.

À medida que divulgamos a história da vulnerabilidade, Heige desapareceu do Twitter. Não sabemos o motivo, mas pode haver algo relacionado.

Eventos

No final de 2021, a internet estava em alvoroço com a divulgação de uma zero-day, uma vulnerabilidade de execução remota de código também conhecida como Log4Shell, no Apache Log4j2. A vulnerabilidade foi encontrada pela equipa de segurança da Alibaba Cloud.

- Esta vulnerabilidade NÃO é tão grave quanto a Log4Shell. Todos os cenários de ataque são mais complexos devido à natureza dos ataques de manipulação de Class Loader em Java. A exploração do Spring4Shell exige conhecimento profundo de Java para obter um POC funcional. A manipulação de Class Loader é mais complicada de entender do que a vulnerabilidade Log4Shell.

Hoje, os investigadores encontraram outra vulnerabilidade gravíssima que pode causar danos severos. O bug está agora a ser rastreado como CVE-2022-22965, podendo chamar-se Spring4Shell. A vulnerabilidade existe no Spring core com versão do JDK maior ou igual a 9.0.

Spring Framework e frameworks derivados, ficheiros spring-beans-*.jar ou CachedIntrospectionResults.class

Todos os detalhes abaixo estão agora confirmados. Não me responsabilizo por qualquer dano causado.

Detalhes da vulnerabilidade e investigação

Sendo um dos frameworks open-source leves mais populares do mundo para Java, o Spring permite que os programadores se concentrem na lógica de negócio e simplifica o ciclo de desenvolvimento de aplicações empresariais Java.

A exploração requer um endpoint com DataBinder ativado (por exemplo, um pedido POST que descodifica automaticamente dados do corpo do pedido) e depende fortemente do contentor de servlets da aplicação. Por exemplo, quando o Spring é implantado no Apache Tomcat, o WebAppClassLoader fica acessível, o que permite a um atacante chamar getters e setters para, em última análise, escrever um ficheiro JSP malicioso no disco. No entanto, se o Spring for implantado usando o Embedded Tomcat Servlet Container, o classloader é um LaunchedURLClassLoader, que tem acesso limitado.

No entanto, na versão JDK9 (e superior) do Spring Framework, um atacante remoto pode obter o objeto AccessLogValve e valores de campos maliciosos através da função de ligação de parâmetros do framework, desde que determinadas condições sejam cumpridas.

• Atualmente, sabe-se que acionar esta vulnerabilidade requer duas condições básicas:
• Usar o framework Spring MVC e JDK9 ou superior

(1). Verificar o número da versão do JDK

No servidor em execução do sistema da organização, execute o comando "java -version" para verificar a versão do JDK em execução. Se o número da versão for menor ou igual a 8, o sistema não é afetado pela vulnerabilidade.

(2). Verificar a utilização do framework Spring

1. Se o projeto do sistema da organização for implantado na forma de um pacote war, siga os passos abaixo para avaliar.

• Descompacte o pacote war: altere o sufixo do ficheiro war para .zip e descompacte o ficheiro zip.
• Procure um ficheiro jar no formato spring-beans-*.jar (por exemplo, spring-beans-5.3.16.jar) no diretório de descompressão. Se existir, significa que o sistema de negócio é desenvolvido usando o framework Spring.
• Se o ficheiro spring-beans-*.jar não existir, procure a existência do ficheiro CachedIntrospectionResuLts.class no diretório de descompressão. Se existir, significa que o sistema de negócio é desenvolvido usando o framework Spring.

2. Se o projeto do sistema da organização for executado direta e independentemente na forma de um pacote jar, avalie de acordo com os seguintes passos.

• Descompacte o pacote jar: altere o sufixo do ficheiro jar para .zip e descompacte o ficheiro zip.
• Procure um ficheiro jar no formato spring-beans-*.jar (por exemplo, spring-beans-5.3.16.jar) no diretório de descompressão. Se existir, significa que o sistema de negócio é desenvolvido usando o framework Spring.
• Se o ficheiro spring-beans-*.jar não existir, procure a existência do ficheiro CachedIntrospectionResuLts.class no diretório de descompressão. Se existir, significa que o sistema de negócio é desenvolvido usando o framework Spring.

(3) Investigação abrangente

Depois de concluir os dois passos de verificação anteriores, as duas condições seguintes devem ser cumpridas em simultâneo para determinar que o sistema é afetado por esta vulnerabilidade:

1. O número da versão do JDK é 9 ou superior;
2. É usado o framework Spring ou um framework derivado.

Guias de correção da vulnerabilidade

Agora, a equipa do Spring corrigiu a vulnerabilidade e lançou as versões mais recentes do Spring Boot 2.6.6 e 2.5.12, que dependem do Spring Framework 5.3.18.

Proteção WAF

Em dispositivos de proteção de rede, como WAF, implemente a filtragem de regras para strings como "class.", "Class.", ".class." e ".Class.", de acordo com o tráfego real dos serviços implantados. Após filtrar as regras, teste a operação do negócio para evitar impacto adicional.

Medidas temporárias de correção

A correção temporária da falha deve ser realizada nos seguintes dois passos, em simultâneo:

1. Procure globalmente a anotação @InitBinder na aplicação para ver se o método dataBinder.setDisallowedFields é chamado no corpo do método. Se a introdução deste trecho de código for encontrada, adicione {"class.","Class.", ".class.", ".Class."} à lista negra original. (Nota: se este trecho de código for muito utilizado, precisa de ser acrescentado em todos os locais.)

2. Crie a seguinte classe global no pacote do projeto do sistema da aplicação e garanta que esta classe seja carregada pelo Spring (recomenda-se adicioná-la no pacote onde o Controller está localizado). Depois de adicionar a classe, o projeto precisa de ser recompilado e empacotado, testado para verificação funcional e republicado. import org.springframework.core.annotation.Order;

   root@kitploit:~

    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 GlobalControllerAdvice{ 
   
         @InitBinder
   
         public void setAllowedFields(webdataBinder dataBinder){
   
         String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};
   
         dataBinder.setDisallowedFields(abd);
   
         }
   
    }
   

A partir do repositório Git dos projetos Spring, parece que os programadores do Spring estão a trabalhar numa correção para a vulnerabilidade de execução remota de código, mas temos de esperar pela confirmação oficial.