Критическая уязвимость DoS в Apache Struts 2

Критическая уязвимость DoS в Apache Struts 2

Apache Software Foundation раскрыла две связанные критические уязвимости типа Denial of Service, затрагивающие практически все версии фреймворка Apache Struts. Эти уязвимости позволяют неаутентифицированным злоумышленникам исчерпать дисковое пространство сервера посредством специально сформированных запросов загрузки файлов, что может привести к полной недоступности системы. Организации, использующие Apache Struts, должны немедленно принять меры для оценки своего риска и реализации мер по устранению угрозы.

Apache Struts 2 — один из наиболее популярных Java-фреймворков для создания веб-приложений — оказался уязвим к сложной атаке типа Denial of Service. Уязвимости, отслеживаемые как CVE-2025-64775 и CVE-2025-66675, связаны с некорректной обработкой multipart-запросов: механизм загрузки файлов создает временные файлы, но не удаляет их после обработки.

Когда злоумышленник отправляет специально сформированные multipart-запросы (с загрузкой файлов или с большими полями формы), Apache Struts создает временные файлы на локальной файловой системе сервера. Из-за дефекта в процессе очистки класса JakartaMultiPartRequest, эти временные файлы не удаляются. Они накапливаются, занимают всё доступное дисковое пространство, приводя к постепенной деградации работоспособности, а затем — к полной остановке сервера.

Когда диск переполняется, система теряет возможность:
— записывать данные,
— формировать новые логи,
— обслуживать сессии,
— выполнять критические операции ввода-вывода.

Это приводит к полной недоступности сервисов и требует ручного вмешательства. 2.3.x и 2.5.x — они больше не поддерживаются и не получают исправлений безопасности.

Масштаб воздействия

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

• Apache Struts 2.0.0 — 6.7.4
• Apache Struts 7.0.0 — 7.0.3

Почти все организации, использующие Struts, попадают в зону риска.

Наибольшую угрозу несут устаревшие внедрения Struts 2.3.x и 2.5.x, которые не поддерживаются и больше не получают патчи безопасности. Они содержат не только описанные уязвимости, но и целый набор иных критических дефектов.

Детали уязвимости и технический анализ

Понимание CVE-2025-64775 и CVE-2025-66675

Оба CVE описывают разные аспекты одной и той же фундаментальной проблемы — утечки файлов из multipart-обработчика Struts.

• CVE-2025-64775 — первичное раскрытие (1 декабря 2025)
• CVE-2025-66675 — расширение и исправление диапазона затронутых версий (10 декабря 2025), включая 6.7.4

Таблица различий

Почему два CVE?

Потому что исходная заявка не включала версию 6.7.4, которая также оказалась уязвимой. Второе CVE расширяет и уточняет охват уязвимости.

Первопричина — утечка файлов в JakartaMultiPartRequest

Уязвимость возникает в классе:

org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest

Особенно — в методе cleanUp(), который должен удалять временные файлы, созданные в процессе обработки multipart-запросов.

Но реализация удаляет только файлы, связанные с фактической загрузкой файлов, игнорируя временные файлы, созданные для обычных полей формы, если они превышают допустимый порог размера.

Таблица компонентов

Пример уязвимого шаблона кода

public void cleanUp() {
    for (FileItem item : fileItems) {
        if (item.isFormField()) {
            // ОШИБКА: временные файлы для больших полей формы не удаляются
            continue;
        }
        item.delete(); // удаляет только файлы загрузки
    }
}

Каждый multipart-запрос может оставлять мусорные временные файлы.
Многократные запросы → лавинообразное накопление файлов → исчерпание носителя.

Механика атаки и сценарий эксплуатации

Усложнённости минимальны — это делает DoS особенно опасным.

Сценарий атаки

Низкий барьер эксплуатации

Не требуется:

• аутентификация,
• привилегии,
• социальная инженерия,
• взаимодействие пользователя.

Используются обычные инструменты:

• curl
• Python-скрипты
• Burp Intruder
• любой HTTP-генератор

Оценка воздействия и рисков

Последствия затрагивают практически все аспекты ИТ-операций:

Отраслевые факторы риска

Разные индустрии испытывают различную степень воздействия, исходя из зависимости от Struts и чувствительности к простоям.

Стратегии обнаружения и идентификации уязвимости

Методология оценки уязвимостей

Организация должна оперативно определить:

1. есть ли Struts-приложения в среде,
2. какие из них используют уязвимые версии,
3. являются ли они доступными из интернета,
4. содержат ли функциональность загрузки файлов или больших форм.

Таблица процесса оценки

Команды для обнаружения уязвимых версий

Проверка jar-файла:

jar -tf application.war | grep struts2-core
unzip -l application.war | grep struts2-core

Maven:

mvn dependency:tree | grep struts

Поиск библиотек Struts:

find / -name "struts2-core*.jar" 2>/dev/null

Проверка запущенных процессов:

ps aux | grep java
jps -v | grep struts

Проверка зависимостей в web-приложении:

ls -la WEB-INF/lib/ | grep struts

Мониторинг и обнаружение атак

Даже до патча необходимо развернуть мониторинг на уровне инфраструктуры и приложения.

Что нужно отслеживать

Примеры команд для мониторинга

Уровень диска:

df -h
watch -n 5 'df -h | grep -E "/tmp|/var"'

Поиск временных файлов:

du -sh /tmp /var/tmp
find /tmp -type f -mtime -1 | wc -l
find /tmp -name "*.tmp" -o -name "struts*" -o -name "upload_*"

Логи HTTP:

grep -i "multipart" /var/log/apache2/access.log | tail -100

Стратегии устранения и смягчения (Remediation & Mitigation)

Требования немедленного патчинга

Apache Foundation выпустила исправления:

Почему особенно опасны старые версии?

• нет патчей
• устаревший код
• известные эксплуатационные цепочки
• легко автоматизируемые атаки

Поэтапное внедрение патчей

Компенсирующие меры (если патч невозможен)

Важно: Единственное исправление — обновление Struts.

Обнаружение и подтверждение атаки

Если организация подозревает, что уязвимость уже эксплуатируется, необходимо быстро подтвердить факт атаки и оценить масштаб ущерба. Основной индикатор — аномальный рост количества временных файлов и быстрое заполнение дискового пространства.

Команды для быстрой диагностики

1. Проверить дисковое пространство:

df -h
du -sh /tmp /var/tmp /upload-directory

2. Найти утекшие временные файлы:

find /tmp -name "upload_*" -o -name "struts*" -o -name "*.tmp"
ls -lah /tmp | grep $(date +%Y-%m-%d)

3. Найти подозрительные multipart-запросы в HTTP-логах:

grep -i "multipart" /var/log/apache2/access.log | tail -100
grep -i "Content-Type: multipart" /var/log/httpd/access_log

4. Мониторинг использования диска в реальном времени:

watch -n 5 'df -h | grep -E "/tmp|/var"'

5. Определить процессы, удерживающие удалённые файлы (часто признак DoS):

lsof +L1 | grep deleted

Этапы реагирования на инцидент

Организация должна применять системный и документированный подход.

1. Изоляция поражённых систем

Цель: предотвратить дальнейшую эксплуатацию и остановить рост временных файлов.

Действия:

• заблокировать входящий трафик на уязвимое приложение;
• отключить внешние интерфейсы;
• запретить доступ злоумышленнику к сервису упреждающе;
• сохранить форензические артефакты до вмешательства.

Важно:

Это может привести к простою, поэтому решение требует согласования с бизнесом.

2. Очистка временных файлов и восстановление дискового пространства

Действия:

• идентифицировать временные файлы по маске (upload_*, *.tmp, struts*);
• сохранить образцы для анализа;
• удалить лишние файлы вручную или автоматизированно;
• временно расширить объём хранилища (LVM resize / cloud volume extend).

Риски:

• возможное удаление файлов, которые приложение ещё использует.

3. Развертывание экстренных WAF-правил

Правила могут включать:

• блокировку multipart-запросов большого размера,
• ограничение скорости POST-запросов,
• блокировку подозрительных IP, генерирующих аномальный трафик.

Недостаток:

WAF — это временная защита, не исправление.

4. Сбор криминалистических данных

Потребуется, если возможна юридическая, регуляторная или внутренняя проверка.

Необходимо сохранить:

• журналы HTTP-доступа (до очистки),
• системные логи,
• содержимое временных файлов (образцы),
• снимки дисков,
• сетевые дампы.

Обоснование:

• помогает определить источник атаки,
• подтверждает или исключает утечку данных,
• позволяет скорректировать меры защиты.

5. Уведомление заинтересованных сторон

Это шаг организационного уровня:

• уведомить руководителей ИБ и ИТ,
• сообщить владельцам бизнес-процессов,
• уведомить клиентов (если требуется регуляторикой),
• подготовить внешнее заявление при длительном простое.

6. Экстренный патчинг

Если эксплуатация подтверждена — откладывать обновление Struts нельзя.

Требования:

• внеплановое окно изменений,
• тестирование основных функций,
• проверка безопасности после обновления.

Форензика и анализ инцидента

Цели форензики:

1. Определить источник атаки.
2. Установить временную шкалу.
3. Выявить потенциально украденные данные.
4. Установить повторяющиеся паттерны запросов.
5. Проверить, не внедрены ли закладки или бэкдоры.

Ключевые артефакты:

Процедуры восстановления

После остановки атаки и очистки диска — нужно корректно восстановить систему.

1. Проверка целостности данных

Потому что:

• база могла записать неполные или повреждённые транзакции,
• журналы транзакций могли быть нарушены,
• резервные копии могли не создаться из-за отсутствия места.

Проверить:

• транзакционные логи,
• очереди сообщений,
• работу фоновых задач,
• историю ошибок приложений.

2. Перезапуск сервисов

После восстановления пространства многие сервисы не восстановятся автоматически.

Требуется:

• перезапуск Java-приложений,
• перезапуск контейнеров,
• пересборка индексов (если требовалось),
• проверка работоспособности Nginx / Apache.

3. Перепроверка мониторинга

Необходимо подтвердить:

• восстановлена ли ротация логов,
• корректно ли работает сбор метрик,
• восстановились ли алертинг и уведомления.

Долгосрочные улучшения безопасности

Уязвимость Struts показала слабые места не только в приложениях, но и в процессах.

1. Улучшение управления уязвимостями

Проблема: реактивный подход, патчи не ставятся вовремя.

Решение:

• определить SLA для критических патчей (1–3 дня),
• автоматизировать сканирование уязвимостей,
• еженедельно анализировать зависимость Struts во всех проектах.

2. Улучшение отслеживания зависимостей

Проблема: команда не знает, где используется какая версия Struts.

Решение:

• внедрить Software Bill of Materials (SBOM),
• интегрировать dependency-check в CI/CD,
• автоматически блокировать деплой уязвимых версий.

3. Интеграция тестов безопасности

Включить в CI/CD:

• SAST,
• DAST,
• зависимости-проверки,
• тесты на DoS.

4. Управление фреймворками

Проблема: разные версии Struts в разных сервисах.

Решение:

• создать корпоративный стандарт версий,
• запретить деплой устаревших библиотек.

5. Управление устаревшими системами

Это главная проблема, ведущая к атакам.

Решение:

• определить все 2.3.x и 2.5.x,
• составить план миграции,
• назначить ответственных за модернизацию.

6. Улучшение мониторинга

Мониторинг должен быть:

• многоуровневым (диск, приложение, сеть),
• с порогами и алертами,
• интегрирован в SIEM.

Построение устойчивых практик безопасности

Инцидент с уязвимостью Apache Struts наглядно демонстрирует критическую необходимость проактивного и зрелого управления безопасностью. Даже один пропущенный патч или недосмотр в обработке multipart-запросов способен привести к полному отказу сервисов, нарушению бизнеса, финансовым потерям и серьёзным репутационным рискам.

Организации, которые:

• поддерживают актуальные версии фреймворков,
• регулярно проводят комплексный мониторинг,
• оперативно внедряют исправления,
• проводят аудиты зависимостей,
• интегрируют тестирование безопасности в CI/CD,

— значительно снижают вероятность подобных инцидентов.

Инвестиции в зрелость процессов безопасности превращают инфраструктуру из реактивной в проактивную, позволяя предотвращать атаки ещё до их начала.

Улучшение процессов и архитектуры (долгосрочная стратегия)

Восстановление после инцидента — это не просто решение текущей проблемы. Это возможность усовершенствовать архитектуру и процессы, чтобы подобные уязвимости в будущем не представляли угрозы.

Ниже — ключевые направления улучшений.

1. Управление уязвимостями (Vulnerability Management)

Проблема: критические версии фреймворков оставались без патчей слишком долго.
Решение:

• формализовать SLA для критических обновлений: 1–3 дня;
• автоматизировать сканирование уязвимостей (Nessus, Qualys, OpenVAS);
• ежемесячно проводить ревизию зависимостей.

2. Контроль зависимостей (Dependency Governance)

Проблема: команды не владеют информацией о версиях Struts во всех приложениях.
Решение:

• внедрить SBOM (Software Bill of Materials);
• автоматизировать проверку зависимостей в CI/CD;
• внедрить политики блокировки уязвимых версий при сборке.

3. Интеграция тестирования безопасности

В каждом релизе должны выполняться:

• SAST (статический анализ кода),
• DAST (динамический анализ),
• Dependency Check,
• нагрузочные тесты на multipart и DoS-чувствительные узлы.

4. Стандартизация фреймворков

Проблема: разные приложения использовали разбросанные версии Struts.
Решение:

• создать внутренний список разрешённых версий;
• описать процесс обновления;
• запретить деплой устаревших библиотек.

5. Управление устаревшими системами (Legacy Management)

Самый критичный фактор риска — существование версий 2.3.x и 2.5.x в проде.

Решение:

• создать план миграции,
• разработать политики end-of-life,
• выделить бюджет на модернизацию приложений.

6. Мониторинг и наблюдаемость

Стратегия мониторинга должна включать:

• отслеживание использования диска,
• мониторинг числа файлов в /tmp,
• WAF-аналитику по multipart-запросам,
• алерты по отклонениям I/O,
• интеграцию в SIEM с корреляцией событий.

Заключение и ключевые выводы

Уязвимости CVE-2025-64775 и CVE-2025-66675 представляют собой серьёзные DoS-проблемы, поражающие один из наиболее распространённых Java-фреймворков — Apache Struts. Ошибка в обработке multipart-запросов приводит к утечке временных файлов, которые не очищаются системой, постепенно заполняя дисковое пространство, вплоть до полного отказа работы приложений.

Почему эти уязвимости критичны:

• эксплуатируются удалённо и без аутентификации;
• требуют минимальных усилий для атаки;
• воздействие — полный отказ сервиса;
• затрагивают огромный диапазон версий;
• легко автоматизируются;
• атаки трудно обнаружить до начала деградации системы.

Организациям необходимо:

1. Немедленно обновиться до Struts 6.8.0+ или 7.1.1+.
2. Внедрить временные меры защиты — WAF, rate limiting, мониторинг.
3. Провести полную инвентаризацию приложений.
4. Удалить устаревшие версии Struts из продакшена.
5. Настроить непрерывное наблюдение за диском, multipart-трафиком и логами.
6. Реализовать долгосрочную программу улучшений безопасности.

Стратегический вывод

Эта уязвимость — напоминание о том, что безопасность веб-приложений определяется не только качеством кода, но и зрело выстроенными процессами:

• управления уязвимостями,
• управления зависимостями,
• мониторинга,
• CI/CD контролей,
• архитектурных стандартов.

Организации, которые используют инцидент как стимул модернизировать эти процессы, смогут значительно снизить риски будущих атак и обеспечить устойчивость своих приложений.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Аудит облачной безопасности.