В ночь на 10 декабря по сети разошёлся PoC-эксплойт для уязвимости в Apache Log4j 2 – библиотеке логирования, которая встроена в тысячи Java-приложений. Уязвимость получила идентификатор CVE-2021-44228 и имя Log4Shell. Оценка по CVSS – 10.0, максимальная. Это не теоретический риск: атаки в дикой природе уже идут, а эксплуатация тривиальна. Если в вашем контуре есть Java-сервисы, считайте, что вы в зоне поражения, пока не доказали обратное.

Чем грозит

Log4j при логировании обрабатывает подстановки вида ${...}. Через механизм JNDI lookup строка ${jndi:ldap://...} заставляет приложение обратиться к внешнему серверу и загрузить произвольный Java-класс. Итог – удалённое выполнение кода (RCE) без аутентификации.

Опасность в способе доставки. Атакующему достаточно, чтобы вредоносная строка попала в любой лог. Подходят User-Agent, заголовок X-Forwarded-For, поле формы, имя файла, чат-сообщение, тема письма. Уязвимы не только серверы у периметра – внутренние сервисы, которые логируют данные, пришедшие извне через несколько звеньев, тоже под ударом.

Затронуты версии Log4j 2 с 2.0-beta9 по 2.14.1. Проблема в том, что библиотека редко стоит явно – она тянется транзитивной зависимостью внутри Elasticsearch, Kafka, Solr, Spring-приложений, корпоративных продуктов на Java. Для госсектора это вдвойне критично: компрометация системы, обрабатывающей персональные данные, – это уже не только инцидент ИБ, но и нарушение требований к защите персональных данных по 152-ФЗ.

Что делать прямо сейчас

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

1. Найдите Log4j. Просканируйте артефакты и образы на наличие log4j-core. Проверяйте не только прямые зависимости – стройте дерево транзитивных (mvn dependency:tree, gradle dependencies). Не забудьте про работающие процессы: библиотека может быть в развёрнутом приложении, но отсутствовать в исходниках.

2. Обновитесь. Целевая версия – Log4j 2.16.0. Она убирает поведение JNDR lookup полностью. Промежуточный релиз 2.15.0 закрывал основной вектор, но уже выявлены способы обхода, поэтому ориентируйтесь сразу на 2.16.0.

3. Если обновиться нельзя сегодня – примените смягчение. Установите системное свойство log4j2.formatMsgNoLookups=true или переменную окружения LOG4J_FORMAT_MSG_NO_LOOKUPS=true для версий 2.10 и выше. Это временная мера, а не замена патчу.

4. Закройте периметр. Настройте WAF на блокировку строк с jndi:, ldap:, rmi: в заголовках и теле запросов. Ограничьте исходящие соединения с серверов наружу – без них загрузка вредоносного класса не отработает.

5. Проверьте, не скомпрометированы ли вы. Изучите логи на подозрительные ${jndi: и аномальный исходящий трафик к незнакомым LDAP/RMI-хостам.

Системный вывод

Log4Shell обнажил типовую слабость – отсутствие учёта зависимостей. Когда инфраструктура описана кодом, а сборка воспроизводима, найти и пропатчить уязвимый компонент во всём парке – вопрос часов, а не недель. Если вы ещё не перешли на инфраструктуру как код, этот инцидент – повод начать. То же касается прозрачности облака: подход FinOps и контроль облачных ресурсов дают актуальную карту того, что и где у вас запущено.

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