Spring4Shell: o que sabemos sobre a vulnerabilidade de RCE no Java

Já conhece a Spring4Shell? Vá direto para a seção Como corrigir a Spring4Shell deste blog ou leia nossa análise aprofundada da Spring4Shell para entender como funciona a execução remota de código (RCE) de dia zero.

Bem cedo, na manhã de 30 de março (pelo meu horário), meu colega DeveloperSteve publicou uma mensagem no nosso canal do Slack: “Ei, você viu isso?”. Era um “aviso antecipado” sobre uma “provável” execução remota de código (RCE) no popularíssimo framework Java Spring. Depois descobri que, ainda antes disso, a equipe de segurança da Snyk já havia começado a investigar uma possível RCE no Spring, após ver um tuíte que foi apagado desde então.

No início, as informações pareciam pouco confiáveis. Havia um tuíte com capturas de tela que foi apagado. Também havia referências a uma solicitação de pull (PR) que, como descobrimos, foi aberta em 18 de fevereiro, mas só foi integrada em 29 de março.

Vários grupos tentavam fazer o apelido “Spring4Shell” pegar (ou, às vezes, apenas SpringShell), enquanto os mantenedores do Spring Core adicionavam comentários à PR dizendo que não havia nenhuma RCE conhecida.

Então, afinal, o que estava acontecendo e o que está acontecendo agora?

Afinal, o que é Spring4Shell?

Se você já usou a anotação @Autowired ou aproveitou a mágica da injeção por construtor, já teve contato com a injeção de dependência no ecossistema Spring.

Nas versões afetadas, é possível executar código remotamente manipulando o ClassLoader por meio de uma solicitação HTTP POST cuidadosamente elaborada.

Até o momento, sabe-se que a exploração só é possível com uma versão 9 ou superior do Java Runtime Environment (JRE) E uma versão 9 ou superior do Tomcat.

Por precaução e para não agir com base em informações incompletas, os pesquisadores de segurança da Snyk passaram o dia 30 de março analisando a situação.

Até o momento, concluímos que há uma ameaça confiável de RCE no pacote spring-beans do Spring Core. Para o bem ou para o mal, Spring4Shell é o nome oficial. Faz sentido, já que existe um projeto legítimo chamado Spring Shell no ecossistema Spring.

Continuaremos publicando atualizações no nosso banco de dados de vulnerabilidades à medida que a situação evoluir.

Como corrigir a Spring4Shell

Foram lançadas novas versões do Spring Framework que não são afetadas pela exploração atual: 5.2.20e 5.3.18. E, se você trabalha com Spring Boot, foram lançadas hoje as versões 2.5.12 e 2.6.6, que incorporam as alterações ao Spring Framework e ao spring-beans.

Veja as etapas de correção que você pode seguir, em ordem de preferência:

• Se você usa o Spring Framework diretamente, atualize para a versão 5.2.20 ou 5.3.18

• Se você usa Spring Boot, utilize a versão 2.15.12 ou 2.6.6

• Se não puder atualizar sua versão do Spring neste momento, use um JRE versão 8 e/ou um contêiner Tomcat para reduzir o risco

Vale lembrar que provavelmente haverá novas atualizações do Spring à medida que outras vulnerabilidades (e possivelmente diferentes) forem descobertas. Esse costuma ser o caminho quando uma vulnerabilidade de alta gravidade recebe muita atenção (Log4Shell, por exemplo?).

As ferramentas da Snyk já foram atualizadas para avisar você se seu projeto estiver vulnerável!

Acesse Snyk e crie uma conta gratuita. Depois, pela plataforma ou pela linha de comando, você pode testar seu projeto para saber se está vulnerável à Spring4Shell.

Esperamos atualizar esta publicação e criar um repositório de código PoC para demonstrar a RCE nas versões 9 e posteriores do JRE e do Tomcat. Acompanhe aqui as atualizações.

Entenda a confusão inicial em torno da Spring4Shell

Uma das primeiras publicações de blog que nossa equipe recebeu, nas primeiras horas de 30 de março, foi apagada. Ela mencionava um tuíte que também foi apagado. Apesar dos dois apagamentos, havia uma referência verificável a um commit relacionado ao Spring Core e à desserialização (um recurso do Java que já levou a casos de RCE — Log4Shell, por exemplo?).

O comentário neste commit diz:

1Since SerializationUtils#deserialize is based on Java's serialization
2mechanism, it can be the source of Remote Code Execution (RCE)
3vulnerabilities.

Ao longo do dia, aumentaram os rumores (com pouquíssimos fatos verificáveis para sustentá-los) de que poderíamos estar lidando com uma RCE no Spring Core.

Mais adiante nos comentários, um committer do Spring Core confirmou outro comentário, afirmando que esse commit não tinha relação com nenhuma RCE conhecida.

E, de fato, se você consultar a PR resolvida pelo commit, verá que ela foi aberta em 18 de fevereiro.

E aqui está o ponto crucial: enquanto tudo isso acontecia, a internet confundia essa questão em evolução com outro problema conhecido, em um projeto completamente diferente: Spring Cloud Function. Para não aumentar ainda mais a confusão, não vou entrar nos detalhes dessa vulnerabilidade. Basta dizer que, se você está lendo sobre vulnerabilidades no Spring Cloud, está procurando informações sobre a Spring4Shell no lugar errado (por favor, podemos dar outro nome a isso?).

Em resumo

Proteja-se da Spring4Shell seguindo as medidas de correção recomendadas acima. Crie uma conta gratuita da Snyk para começar a corrigir o problema.