Detecção e mitigação da vulnerabilidade CVE-2025-24813 no Apache Tomcat
Resumo executivo
Em 10 de março de 2025, uma vulnerabilidade de equivalência de caminho no Apache Tomcat (identificada como CVE-2025-24813) foi divulgada publicamente, juntamente com um patch para correção.
Embora a vulnerabilidade possa permitir execução remota de código (RCE), o Apache a classificou como de gravidade moderada, já que requer pré-requisitos específicos e não padrão para ser explorada.
Pouco depois da divulgação, a Akamai começou a observar tentativas iniciais de exploração, com sondagens em servidores potencialmente vulneráveis.
Nesta publicação no blog, os pesquisadores da Akamai fornecem detalhes sobre a vulnerabilidade, técnicas de exploração e estratégias de detecção.
Uma regra rápida do mecanismo de segurança adaptável da Akamai fornece proteção automaticamente para os clientes do Akamai App e do API Protector.
Também fornecemos uma consulta do Akamai Guardicore Segmentation Insight para detecção.
- Os clientes do Akamai Hunt que foram afetados já receberam mapeamento detalhado de ativos vulneráveis.
O que é a CVE-2025-24813?
Em 10 de março de 2025, uma vulnerabilidade de equivalência de caminho no Apache Tomcat, um popular servidor web de código aberto e contêiner de servlets Java amplamente utilizado para hospedar aplicações baseadas em Java, foi anunciada juntamente com o patch correspondente. A falha foi identificada como CVE-2025-24813. A falha afeta especificamente a forma como o servidor processa os caminhos de arquivos internamente. Poucos dias após a divulgação pública de uma prova de conceito, atacantes já estavam tentando explorá-la ativamente, seguindo uma tendência preocupante que temos observado recentemente: o tempo entre a divulgação da vulnerabilidade e sua exploração está diminuindo cada vez mais.
O Apache classificou a CVE-2025-24813 como uma vulnerabilidade de gravidade moderada, devido aos requisitos específicos para sua exploração. Um servidor vulnerável precisa atender a um conjunto específico de pré-requisitos, o que torna a exploração menos provável. No entanto, independentemente desses pré-requisitos, como a falha pode resultar em execução remota de código (RCE) sem autenticação, é fundamental aplicar o patch imediatamente.
A vulnerabilidade foi corrigida nas versões 11.0.3, 10.1.35 e 9.0.99 do Apache Tomcat, mas os servidores que executam as versões 11.0.0-M1 a 11.0.2, 10.1.0-M1 a 10.1.34 e 9.0.0-M1 to 9.0.98 ainda podem estar vulneráveis.
O que é a CVE-2025-24813?
Quando o servlet padrão do Apache Tomcat é configurado para permitir a funcionalidade de escrita, o que vem desabilitado por padrão, um invasor pode causar um impacto significativo explorando a vulnerabilidade CVE-2025-24813. Quando isso é combinado com o comportamento padrão do servidor de permitir requisições PUT parciais, o invasor pode fazer o upload de um arquivo de sessão serializado e especialmente manipulado, por exemplo, em um diretório com permissão de escrita. Uma vez que o arquivo é enviado, uma requisição HTTP subsequente pode forçar o Tomcat a desserializar o conteúdo, o que dispara a execução da carga maliciosa incorporada.
A exploração dessa vulnerabilidade pode resultar em execução remota de código (RCE), vazamento grave de informações, injeção de conteúdo malicioso, que também pode corromper arquivos críticos de configuração do servidor. As versões afetadas do Apache Tomcat incluem 11.0.0‑M1 a 11.0.2, 10.1.0‑M1 a 10.1.34 e 9.0.0‑M1 a 9.0.98.
Exploração da CVE-2025-24813
O resultado final da exploração é bastante grave, mas atingir o RCE através desta vulnerabilidade requer um conjunto robusto de pré-requisitos:
o servlet padrão deve ter o recurso de gravação explicitamente habilitado
Solicitações PUT parciais devem ser permitidas
A aplicação da Web deve usar persistência de sessão baseada em arquivo com local de armazenamento padrão (fornecendo um diretório de destino gravável para a carga útil mal-intencionada serializada)
Uma biblioteca vulnerável à desserialização deve estar presente ou em uso pela aplicação (permitindo que a execução da carga útil ocorra por meio de um ataque de desserialização)
Além disso, um invasor deve ter conhecimento das convenções de nomenclatura de arquivos internos usadas pela aplicação e da estrutura de diretórios do sistema de arquivos do destino
Embora a maioria dos pré-requisitos possa estar em vigor, o mais crítico, o recurso de gravação de servlet padrão, é desativado por padrão.
Tráfego de ataque analisado
O Akamai Security Intelligence Group (SIG) identificou o tráfego de ataque logo após a vulnerabilidade ser divulgada. A maioria das cargas úteis de ataque observadas são sondas de vulnerabilidade projetadas para ajudar os invasores a determinar se o servidor de destino é vulnerável. Uma variante de ataque comum tem como alvo especificamente caminhos de arquivo .session , que seguem um esquema de nomenclatura randomizado, uma base de seis caracteres anexada à extensão de arquivo .session (Figura 1).
Fig. 1: Examples of .session attack variant
A carga útil mais popular incluiu um arquivo .session como o corpo da solicitação, que consistia em objetos Java serializados mal-intencionados. Na maioria dos casos, o objeto mal-intencionado usará o objeto java.net.URL para "call home" depois que este arquivo session carregado for desserializado pelo Apache Tomcat (Figura 2).
Fig. 2: Attempted .session payload in request body
Detecção de aplicações vulneráveis
Identificar cada instância vulnerável do Apache Tomcat em uma rede pode ser um desafio. As equipes de segurança devem avaliar uma ampla gama de ativos, pois o Apache Tomcat é integrado em vários locais, incluindo aplicações nas quais as bibliotecas estão sendo usadas que os defensores desconhecem.
Semelhante à recente vulnerabilidade do Apache Camel , esta biblioteca pode estar presente como uma dependência indireta, o que significa que não está explicitamente incluída no código-fonte, mas é introduzida por meio de outro pacote de software. Isso adiciona uma camada de complexidade para detecção e, é claro, mitigação.
O Apache Tomcat pode ser instalado por conta própria no Windows e no Linux, ou ser parte de aplicações Kava. Ele pode ser detectado por meio da verificação recursiva de diretórios para arquivos JAR (Java Archive) chamados tomcat-api.jar. Depois que um arquivo JAR relacionado ao Tomcat é localizado, seu arquivo de manifesto pode ser examinado para determinar a versão em uso.
Com a versão extraída, as equipes de segurança podem fazer referência cruzada com o aviso de segurança do Apache e avaliar possíveis vulnerabilidades. As seguintes versões são afetadas:
- Apache Tomcat 11.0.0-M1 a 11.0.2
- Apache Tomcat 10.1.0-M1 a 10.1.34
- Apache Tomcat 9.0.0.-M1 a 9.0.98
Automatização da detecção
Para clientes do Akamai Guardicore Segmentation , criamos uma consulta de Insight que pode identificar ativos vulneráveis. A consulta retornará todos os caminhos e hashes disponíveis para tomcat-api.jar. O JAR retornado pode ser verificado no VirusTotal via hash ou através do arquivo de manifesto dentro do JAR para chegar à versão correta.
Windows – Apache Tomcat nas aplicações
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Linux – Apache Tomcat nas aplicações
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '../%/%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '../%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%/%/tomcat-api.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Windows – Apache Tomcat instalado
SELECT name, version
FROM programs
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Linux – Apache Tomcat instalado
SELECT name, version
FROM deb_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
UNION
SELECT name, version
FROM rpm_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Mitigação com o Akamai App & API Protector
Muitas tentativas de exploração são mitigadas pelas regras existentes do Adaptive Security Engine, incluindo aquelas que detectam tentativas de desserialização do Java (Figura 3).
3000072 – Ataque de desserialização detectado
Fig. 3: Adaptive Security Engine rule 3000072 detecting CVE-2025-24813 exploit attempt
Em 19 de março de 2025, a equipe de pesquisa de ameaças da Akamai também implantou uma regra rápida do Adaptive Security Engine para clientes do App & API Protector para fornecer cobertura completa (Figura 4).
3000957 – Ataque de execução remota de código Apache Tomcat detectado (CVE-2025-24813)
Fig. 4: Adaptive Security Engine Rapid Rule provides full coverage
A versão 1 da regra rápida tem uma ação padrão definida como Alerta. Para bloquear as tentativas de ataque, os clientes devem definir a ação da regra como Negar após analisar os acionadores para eliminar quaisquer falsos positivos.
Resumo
O Akamai SIG continuará a monitorar, relatar e criar mitigações para ameaças como essas para nossos clientes e para a comunidade de segurança em geral. Para acompanhar as notícias mais recentes do Grupo de inteligência de segurança da Akamai, confira nossa página de pesquisa e siga nossas redes sociais.