Detecção e mitigação das vulnerabilidades do Apache Camel
Resumo executivo
Em 9 de março de 2025, o Apache Camel divulgou a CVE-2025–27636, uma vulnerabilidade proveniente da filtragem incorreta de cabeçalhos de solicitação que pode levar à execução remota de código.
Essa vulnerabilidade está em uma biblioteca, criando dependência direta e indireta e complicando a detecção e a mitigação.
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.
- ATUALIZAÇÃO: Em 11 de março de 2025, o Akamai Security Intelligence Group (SIG) reportou um desvio para a equipe de segurança Apache Camel. Em 12 de março de 2025, a Apache lançou uma nova CVE: CVE-2025-29891.
Introdução
Em 9 de março de 2025, uma vulnerabilidade foi corrigida no Apache Camel, que é uma biblioteca Java amplamente usada. A vulnerabilidade foi eliminada pelo Apache e está corrigida nas versões 4.10.2, 4.8.5 e 3.22.4. Embora os relatórios iniciais afirmassem que a vulnerabilidade poderia ter um impacto importante, a equipe do desenvolvedor atribuiu a ela um nível moderado de gravidade.
Apesar dessa classificação de gravidade, é altamente recomendável que você aplique o patch o mais rápido possível se seu ambiente executar as versões que são corrigidas. Porém, as aplicações que executam as versões 4.10.0, 4.10.1, 4.8.0 a 4.8.4 e 3.10.0 a 3.22.3 ainda podem ser afetados.
Para ser explorada, a aplicação vulnerável precisa atender a alguns pré-requisitos específicos (que explicaremos mais adiante neste post). Apesar disso, os impactos ainda poderiam ser grandes. A vulnerabilidade é fácil de explorar e pode levar a consequências devastadoras, incluindo a execução remota de código.
A onipresença do Camel, juntamente com a natureza das vulnerabilidades nas bibliotecas, demonstra a gravidade dessa descoberta. Esta postagem de blog tem como objetivo ajudar as organizações com seu processo de resposta.
Examinaremos a vulnerabilidade e explicaremos seu potencial impacto sobre as aplicações, analisaremos sua exploração para criar detecções e lidaremos com o que talvez seja o desafio mais difícil com essa vulnerabilidade e outras que se escondem em bibliotecas, ou seja, identificar as aplicações vulneráveis.
O que é o Apache Camel?
O Apache Camel é uma estrutura de integração de código aberto amplamente usada que permite a troca perfeita de dados entre diferentes sistemas, aplicações e serviços em nuvem. Ele simplifica o roteamento, a transformação e a conectividade de mensagens em diversos ambientes empresariais. Muitas organizações contam com a Camel para fluxos de trabalho comerciais críticos, integrações de API e orquestração de microsserviços.
Analisando a CVE-2025-27636
O Apache Camel usa DefaultHeaderFilterStrategy.java para bloquear cabeçalhos internos para que não sejam encaminhados externamente. Isso impede que os cabeçalhos vazem informações confidenciais de roteamento que podem ser abusadas por invasores. Exemplos desses cabeçalhos incluem:
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
Essa filtragem é aplicada quando os componentes baseados em HTTP processam solicitações, como:
- camel-http and camel-http4 (processamento HTTP padrão)
- camel-rest (tratamento de REST DSL)
- camel-cxf (serviços da Web do Apache CXF)
A vulnerabilidade deriva da filtragem incorreta de cabeçalhos de solicitação do Camel. Antes da correção, o Apache Camel usava uma regra de filtragem que diferencia maiúsculas de minúsculas (Figura 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
Essa lógica só correspondia a cabeçalhos que começavam com Camel ou org.apache.camel (exatamente como mostrado). Se um invasor alterar a capitalização e usar CAmelHttpUri ou cAMELHttpResponseCode, por exemplo, o cabeçalho não seria filtrado.
Isso significa que um invasor pode injetar cabeçalhos arbitrários em nossas solicitações e fazer com que o Camel os encaminhe para componentes internos. É importante observar que, conforme o Apache menciona em seu comunicado, a vulnerabilidade não permite o acesso a métodos internos arbitrários, mas apenas àqueles que estão no mesmo bean declarado no URI do bean. Este é um dos pré-requisitos específicos para exploração, o que significa que simplesmente executar uma versão vulnerável do Apache Camel não torna automaticamente uma aplicação vulnerável.
Como testar a ameaça
Para demonstrar a vulnerabilidade, criamos um exemplo de aplicação vulnerável que poderia ser explorado remotamente. A aplicação escuta na porta HTTP 80 e, ao receber uma solicitação, usa o componente "Exec" do Camel para executar o comando whoami e retornar o resultado ao cliente.
Chamar uma solicitação simples usando curl retorna o resultado esperado: estar exposto à vulnerabilidade (Figura 2).
Fig. 2: Normal application operation that returns the result of the whoami command
Como podemos ver no código, o comando whoami é definido estaticamente, fazendo com que o código pareça relativamente seguro. Os problemas surgem quando inspecionamos possíveis cabeçalhos de mensagens internas suportados pelo comando Exec. Quando examinamos o cabeçalho CamelExecCommandExecutable , vemos que ele substitui o executável definido no URI estático no código (Figura 3).
Fig. 3: Apache Camel Exec component documentation
O Apache Camel filtraria cabeçalhos internos que correspondiam à letra maiúscula, como CamelExecCommandExecutable. No entanto, a CVE-2025–27636 permitiria uma derivação do filtro inserindo CAmelExecCommandExecutable (ou alguma outra diferença de letra de caso) e o faria executar comandos arbitrários no servidor (Figura 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
De maneira semelhante, também podemos especificar o CAmelExecCommandArgs para fornecer parâmetros ao comando executado (Figura 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
Este é um exemplo simples que demonstra como a exploração dessa vulnerabilidade pode ser vista. A capacidade de injetar cabeçalhos internos arbitrários pode permitir que os invasores comprometam uma variedade de aplicações, dependendo dos componentes Camel usados pelo servidor.
Como o Apache Camel lidou com a CVE-2025-27636?
O problema foi resolvido forçando a uniformidade da capitalização. Isso remove a capacidade de um agente de ameaça manipular essa alternativa para burlar o filtro. Por exemplo, CAmelHttpUri torna-se camelhttpuri, que agora corresponde ao filtro e, portanto, seria capturado.
Apresentação do .toLowerCase()
O compromisso do GitHub atualizou a lógica de filtragem de cabeçalho no DefaultHeaderFilterStrategy.java para incluir toLowerCase(Locale.ENGLISH) e garantir que todos os nomes de cabeçalho sejam convertidos em minúsculas antes de aplicar o filtro (Figura 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
Além da proteção contra a injeção, a correção também mantém a eficiência com uma verificação otimizada. A primeira verificação lida com casos normais de "Camel" e "camel" rapidamente. A verificação .toLowerCase() é executada somente se for necessário, evitando custos desnecessários de desempenho.
Detecção de aplicações vulneráveis
Identificar cada instância vulnerável do Apache Camel em uma rede pode ser um desafio. As equipes de segurança devem avaliar uma ampla gama de ativos, pois o Apache Camel está integrado em vários lugares. Isso pode incluir aplicações nas quais as bibliotecas estão sendo usadas que os defensores desconhecem.
A 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 através de outro pacote de software. Isso adiciona uma camada de complexidade para detecção e, é claro, mitigação.
O Apache Camel geralmente pode ser identificado em aplicações Java verificando recursivamente os diretórios para arquivos JAR que contenham "camel" em seus nomes. Depois que um arquivo JAR relacionado ao Camel é 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:
- 4.10.0, — vulnerável antes da 4.10.2,
- 4.8.0, — vulnerável antes da 4.8.5,
- 3.10.0, — vulnerável antes da 3.22.4,
Automatização da detecção
Para facilitar a identificação de aplicações vulneráveis, desenvolvemos os scripts PowerShell e Bash, que varrem diretórios recursivamente, detectam arquivos Apache Camel JAR e geram aplicações potencialmente vulneráveis. Incluímos opções para Windows e Linux. Os clientes afetados do Akamai Hunt já receberam um mapeamento detalhado de seus ativos vulneráveis.
Detecção com o Akamai Guardicore Segmentation
Para clientes do Akamai Guardicore Segmentation , criamos uma consulta de Insight que pode identificar ativos vulneráveis. Nos casos em que o resultado da consulta para a versão do arquivo é "versão não encontrada", o hash retornado pode ser verificado no VirusTotal ou através do arquivo de manifesto dentro do jar para chegar à versão correta.
Windows
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")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.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 || '..\%\camel-core%.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 || '%\%\camel-core%.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 lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
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")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.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 || '/../%/camel-core%.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 || '/%/%/camel-core%.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 lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Mitigação com o Akamai App & API Protector
Na sexta-feira, 7 de março de 2025, a equipe de pesquisa de ameaças da Akamai implantou uma regra rápida do Adaptive Security Engine para clientes do App & API Protector :
3000911 v2 - Apache Camel (CVE-2025-27636) Attack Detected - Default Action: Deny
Os clientes que têm regras rápidas ativadas com a ação padrão definida como "Gerenciado pela Akamai" ficam automaticamente protegidos contra essa ameaça. Os clientes que estão usando Regras rápidas com a ação padrão definida como "Alerta" devem avaliar qualquer acionamento de regra e definir a ação de regra como negar.
A regra rápida 3000911 foi projetada para acionar cabeçalhos que, de outra forma, teriam escapado à lógica de filtragem interna do Camel (Figura 7). A regra não será acionada em cabeçalhos Camel normais para evitar qualquer impacto nas operações legítimas do cliente.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Tráfego de ataque analisado
As cargas úteis de ataque atuais observadas pelo Grupo de inteligência de segurança da Akamai estão tentando confirmar a vulnerabilidade apenas em vez de explorá-la. A maioria das cargas úteis observadas está usando duas estratégias diferentes para confirmar a vulnerabilidade.
Primeiro, vimos o uso do nome do cabeçalho CAmELDestinationOverrideUrl onde a carga útil é um domínio de beaconing fora de banda (OOB). Esse tráfego é originado de um fornecedor de verificação de vulnerabilidade comercial, e o URL da carga útil é direcionado de volta para seu domínio (Figura 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
Em segundo lugar, vimos cargas úteis usarem o cabeçalho CAmelHttpResponseCode em uma tentativa de extrair um código de status de resposta HTTP específico do servidor (Figura 9). Se o payload foi bem-sucedido, o código de status de resposta HTTP retornado do servidor corresponderia ao fornecido no payload.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Por fim, vimos as duas cargas úteis acima tentarem escapar da detecção usando codificação de URL simples, como ca%4d%45%6cHttpResponseCode (Figura 10). No entanto, essas tentativas ainda estão sendo detectadas e bloqueadas pelo Adaptive Security Engine.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
ATUALIZAÇÃO: CVE-2025-29891
A Akamai SIG, em colaboração com a Citi Cyber Security Operations, identificou um vetor de exploração adicional que surgiu do mesmo problema de filtragem que causou a CVE-2025-27636. Ao testar nossa aplicação vulnerável, identificamos que, além de cabeçalhos de solicitação, a string de consulta e os parâmetros de post body também fornecem um caminho de ataque válido.
Na Figura 11, vemos que especificar o parâmetro de consulta CAmelExecCommandExecutable leva à execução de comando arbitrário, assim como o vetor de cabeçalho original.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
A Akamai SIG reportou o desvio para a equipe de segurança do Apache Camel. Ela validou os resultados e criou uma nova CVE: CVE-2025-29891. As correções codificadas no Apache Camel da CVE-2025-27636 também corrigem esse desvio, mas a Akamai precisou lançar uma regra rápida do App & API Protector 3000911 v3 atualizada em 12 de março de 2025, para resolver o problema.
O patch original para corrigir a CVE-2025-27636 também resolve esse problema, de modo que as aplicações que usam versões atualizadas do Apache Camel não estão vulneráveis a esse vetor de exploração.
Atualizamos nossos repositório do GitHub, que agora também contém detalhes sobre a CVE-2025-29891 e sua exploração.
Embora a exploração da vulnerabilidade anterior possa ser detectada inspecionando cabeçalhos de solicitações, esse problema também requer a filtragem de parâmetros de solicitação.
Resumo
As vulnerabilidades dentro das bibliotecas não só têm implicações diretas para as aplicações, mas também podem se esconder em locais desconhecidos, o que torna extremamente difícil sua detecção e mitigação. O Apache Camel é amplamente usado, e um invasor com o conjunto correto de ferramentas pode se aproveitar disso para executar o código remotamente, o que aumenta a gravidade. É recomendável que você siga o curso de ação sugerido pelo Apache e aplique o patch o mais rápido possível no seu ambiente.
O Grupo de inteligência de segurança da Akamai 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.