Критическая уязвимость Apache Log4j открывает путь к атакам типа man-in-the-middle

Команда Apache Logging Services недавно раскрыла информацию о критической уязвимости в Apache Log4j Core, которая ставит под угрозу корпоративные приложения, создавая возможности для перехвата конфиденциальных данных логирования. Эта уязвимость, получившая идентификатор CVE-2025-68161, затрагивает широко используемый фреймворк логирования и открывает возможности для изощренных атак типа man-in-the-middle на потоки логов.

Суть уязвимости: CVE-2025-68161

Apache Log4j Core, один из наиболее распространенных фреймворков логирования в экосистеме Java, содержит критическую уязвимость в компоненте Socket Appender, которая подрывает безопасность зашифрованных коммуникаций при передаче логов. Уязвимость затрагивает широкий диапазон версий — от 2.0-beta9 до 2.25.2 включительно, что делает её серьезной проблемой для организаций по всему миру.

Socket Appender предназначен для отправки событий логирования по сетевым соединениям удаленным приемникам логов, часто используя шифрование Transport Layer Security (TLS) для защиты конфиденциальных данных логов во время передачи. Однако недавно обнаруженная уязвимость показывает, что даже когда администраторы явно включают проверку имени хоста TLS через настройки конфигурации, Socket Appender не выполняет должную валидацию имени хоста в сертификатах партнеров.

Эта недоработка создает критический пробел в безопасности, который злоумышленники могут использовать, чтобы встроиться между клиентами логирования и приемниками логов, перехватывая или перенаправляя конфиденциальный трафик логирования без обнаружения. Команда безопасности Apache Logging Services присвоила этой уязвимости оценку CVSS 4.0 равную 6.3, классифицируя её как среднюю по степени опасности, хотя потенциальное воздействие на организации, работающие с конфиденциальными данными, требует немедленного внимания.

Технические аспекты эксплуатации

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

Во-первых, злоумышленник должен занять позицию в сети, где он может перехватывать трафик между клиентом логирования (приложение, генерирующее логи) и приемником логов (сервер, собирающий и хранящий логи). Такое позиционирование обычно достигается через атаки на сетевом уровне, такие как ARP-спуфинг, перехват DNS или компрометация компонентов сетевой инфраструктуры.

Во-вторых, злоумышленник должен предъявить серверный сертификат, выданный центром сертификации, которому доверяет клиент логирования. Это требование может показаться значительным барьером, но на практике многие организации настраивают свои приложения так, чтобы они доверяли сертификатам от крупных публичных центров сертификации или внутренних корпоративных ЦС. Если хранилище доверенных сертификатов Socket Appender включает эти центры, атака становится осуществимой.

Критический сбой происходит, когда Socket Appender, несмотря на настройку проверки имен хостов, принимает сертификат злоумышленника без валидации того, что имя хоста в сертификате соответствует предполагаемому имени хоста приемника логов. Это позволяет злоумышленнику предъявить валидный сертификат для другого домена, который он контролирует, эффективно выдавая себя за легитимный приемник логов.

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

Чувствительность данных в логах

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

Рассмотрим, что могут содержать типичные логи приложений:

• События аутентификации пользователей, раскрывающие имена пользователей и паттерны аутентификации
• Идентификаторы сессий, которые могут способствовать перехвату сессий
• API-ключи или токены, случайно залогированные во время отладки
• Персональные данные (PII), обрабатываемые приложением
• Параметры запросов к базам данных, которые могут раскрыть структуры данных
• Внутренние IP-адреса и информацию о топологии сети
• Детали бизнес-транзакций и финансовые данные
• Сообщения об ошибках, содержащие конфиденциальные детали конфигурации
• Отладочную информацию, раскрывающую логику приложения и потенциальные уязвимости

Когда злоумышленники получают доступ к этому потоку логирования через уязвимость CVE-2025-68161, они по сути получают окно в реальном времени в работу приложения, поведение пользователей и потенциально конфиденциальные бизнес-данные.

Исторический контекст: путь Log4j в области безопасности

Для тех, кто знаком с ландшафтом кибербезопасности, имя Apache Log4j имеет особое значение после печально известной уязвимости Log4Shell (CVE-2021-44228), обнаруженной в декабре 2021 года. Та критическая уязвимость удаленного выполнения кода вызвала шоковую волну в индустрии, затронув миллионы приложений по всему миру и потребовав масштабных усилий по исправлению практически во всех секторах.

Хотя CVE-2025-68161 принципиально отличается от Log4Shell и не позволяет удаленное выполнение кода, её раскрытие служит важным напоминанием о том, что широко развернутые фреймворки, такие как Log4j, остаются привлекательными целями как для исследователей безопасности, так и для злоумышленников.

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

Идентификация уязвимых систем в вашей инфраструктуре

Организациям необходимо быстро определить, используют ли они уязвимые версии Log4j Core. Диапазон затронутых версий обширен, охватывая от 2.0-beta9 до 2.25.2. Этот диапазон включает многочисленные production-релизы, которые были развернуты в бесчисленных приложениях на протяжении нескольких лет.

Для идентификации уязвимых систем команды безопасности должны провести комплексную инвентаризацию приложений, использующих Log4j. Этот процесс обычно включает:

• Сканирование манифестов зависимостей приложений (таких как Maven pom.xml файлы, Gradle build файлы или конфигурации управления зависимостями)
• Проверку развернутых JAR-файлов на наличие библиотек Log4j
• Анализ документации приложений и записей развертывания
• Консультации с командами разработки об использовании фреймворков логирования
• Использование инструментов анализа состава программного обеспечения (SCA), которые могут автоматически обнаруживать уязвимые зависимости

Стоит отметить, что транзитивные зависимости могут внедрить Log4j в приложения, даже если он не указан напрямую как зависимость. Многие Java-фреймворки и библиотеки включают Log4j как зависимость, что означает, что приложения могут быть уязвимы, даже если разработчики явно не добавляли Log4j в свои проекты.

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

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

Злоумышленник должен достичь позиции man-in-the-middle на сетевом пути между клиентом логирования и приемником логов. В традиционных, хорошо сегментированных сетях с надлежащими средствами контроля безопасности такое позиционирование может быть сложным. Однако несколько реальных сценариев делают это более достижимым, чем может показаться изначально:

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

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

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

Среды, где данные логирования пересекают недоверенные сети, такие как логирование во внешние облачные сервисы через интернет, значительно расширяют поверхность атаки.

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

Комплексные стратегии митигации

Apache выпустила Log4j Core версии 2.25.3, которая полностью устраняет проблему проверки имени хоста TLS. Обновление до этой версии представляет собой наиболее прямую и эффективную стратегию митигации. Организациям следует приоритизировать это обновление для всех приложений, использующих затронутые версии.

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

Временные защитные меры

Для организаций, не способных обновиться немедленно, Apache и практики безопасности предлагают несколько временных защитных мер:

Ограничение конфигураций хранилища доверенных сертификатов: Следуя рекомендациям NIST SP 800-52 Rev. 2, администраторы должны настроить хранилища доверенных сертификатов так, чтобы они содержали только абсолютно необходимые сертификаты центров сертификации, требуемые для конкретной области коммуникаций. Вместо доверия широким наборам публичных ЦС, организации должны:

• Внедрить частные или корпоративные центры сертификации для внутренней инфраструктуры логирования
• Обеспечить, чтобы хранилища доверенных сертификатов приложений включали только эти внутренние ЦС
• Для приложений, которые должны взаимодействовать с внешними сервисами логирования, явно закрепить ожидаемые сертификаты

Сетевая сегментация: Развернуть сетевую сегментацию для изоляции трафика логирования в выделенных сетевых сегментах с строгим контролем доступа. Это снижает вероятность того, что злоумышленники смогут занять позицию для перехвата трафика.

Мониторинг сети: Внедрить надежный сетевой мониторинг для обнаружения аномальных паттернов трафика, которые могут указывать на атаки типа man-in-the-middle. Неожиданные изменения сертификатов, необычные сетевые пути для трафика логирования или подозрительные паттерны соединений должны вызывать немедленное расследование.

Взаимная TLS-аутентификация: Рассмотрите возможность внедрения взаимной TLS-аутентификации, где и клиент, и сервер предъявляют сертификаты. Эта двунаправленная аутентификация добавляет дополнительный уровень защиты от атак подмены.

Расширенные практики безопасности логирования

Помимо устранения этой конкретной уязвимости, организации должны принять комплексные практики безопасности для своей инфраструктуры логирования:

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

Санитизация данных логов: Приложения должны очищать конфиденциальные данные перед логированием. Пароли, номера кредитных карт, номера социального страхования и другие высококонфиденциальные данные никогда не должны появляться в логах.

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

Поддержание целостности логов: Внедрите механизмы для обнаружения фальсификации данных логов. Цифровые подписи, логирование на основе блокчейна или хранилища типа write-once-read-many (WORM) могут помочь обеспечить, чтобы логи оставались надежными доказательствами системной активности.

Регулярные аудиты безопасности: Периодически проверяйте конфигурации логирования, контроль доступа и практики безопасности.

Мониторинг аномальных паттернов логирования: Неожиданные изменения в объеме логирования, необычные источники логов или подозрительные паттерны в содержимом логов могут указывать на проблемы безопасности.

Более широкие последствия для корпоративной безопасности

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

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

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

Таблица технических характеристик уязвимости

Параметр	Значение
CVE ID	CVE-2025-68161
Компонент	Apache Log4j Core (Socket Appender)
Затронутые версии	2.0-beta9 — 2.25.2
Исправленная версия	2.25.3
CVSS 4.0 Score	6.3 (Medium)
Тип уязвимости	Недостаточная проверка имени хоста TLS
Вектор атаки	Man-in-the-Middle (MITM)
Требуемые привилегии	Позиционирование в сети
Взаимодействие пользователя	Не требуется

Немедленные шаги для вашей организации

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

1. Инвентаризация развертываний Log4j: Идентифицируйте все приложения и системы, использующие Apache Log4j Core. Не упускайте из виду тестовые среды, унаследованные приложения и стороннее ПО.
2. Определите номера версий: Для каждого развертывания Log4j определите конкретную используемую версию.
3. Оцените ваш профиль риска: Оцените вероятность успешной эксплуатации в вашей среде.
4. Спланируйте путь обновления: Разработайте приоритизированный план обновления до Log4j Core 2.25.3.
5. Внедрите временные меры защиты: Во время планирования обновлений примените рекомендованные временные меры митигации.
6. Проверьте практики логирования: Используйте эту уязвимость как возможность для комплексного пересмотра ваших практик безопасности логирования.

Индикаторы компрометации

При расследовании возможной эксплуатации этой уязвимости обратите внимание на следующие признаки:

• Неожиданные изменения в сертификатах, используемых для соединений логирования
• Аномальные сетевые пути или промежуточные узлы в трафике логирования
• Несоответствия между ожидаемыми и фактическими IP-адресами приемников логов
• Необычные паттерны в метаданных TLS-соединений
• Предупреждения о сертификатах или ошибки проверки в системных логах
• Неожиданные задержки или прерывания в доставке логов

Рекомендации по обнаружению

Для обнаружения попыток эксплуатации рекомендуется:

Анализ сетевого трафика: Используйте системы обнаружения вторжений (IDS/IPS) для мониторинга TLS-соединений к приемникам логов. Настройте алерты на:

• Соединения с неожиданными сертификатами
• Изменения в цепочках сертификатов
• Несоответствия между SNI (Server Name Indication) и фактическим сертификатом

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

Baseline мониторинг: Установите базовую линию нормального поведения для инфраструктуры логирования, чтобы легче обнаруживать аномалии.

Заключение

Обнаружение CVE-2025-68161 в Apache Log4j Core служит важным напоминанием о том, что уязвимости безопасности могут появиться в любом компоненте нашей технологической инфраструктуры. Хотя эта уязвимость может не вызвать того же уровня паники, что и Log4Shell, она требует серьезного внимания от профессионалов в области безопасности и системных администраторов.

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

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