Log4Shell: завершаем январский аудит и считаем хвосты

Новый год не обнулил Log4Shell. Пока большинство уходило на праздники, сканеры по всему миру продолжали долбить порты в поисках уязвимых приложений. 2 января CISA официально выпустила директиву BOD 22-02 - федеральные агентства обязаны закрыть CVE-2021-44228 до 24 декабря (что уже прошло) и ещё несколько связанных CVE в ближайшие недели. Для нас это лишнее подтверждение: работа не закончена.

Первые две недели января мы закрываем то, что не успели в декабре. Точнее - то, что выяснилось только в декабре: оказывается, у ряда клиентов есть Java-приложения, о которых никто особо не думал как о «живых сервисах».

Что нашли в процессе

Декабрьский аудит инвентаря компонентов показал картину, которую мы не ожидали увидеть в таком объёме. Несколько типовых находок января:

• Внутренние утилиты на Log4j 2.x. Самописные инструменты для интеграции с 1С, конвертеры форматов, небольшие ETL-пайплайны - всё это работало годами, никто не держал это в голове как «Java-приложение с зависимостями». Никакого реестра, никакого SBOM. Обнаруживались grep-ом по файловой системе серверов и через поиск jar-файлов в /opt, /srv, /home.

• Сторонние продукты с bundled log4j. Несколько коммерческих решений российских вендоров шли с log4j внутри, версии 2.x. Часть вендоров уже выпустила патчи, часть - молчит. Мы пишем письма вручную, ждём ответов.

• Заброшенные инстансы. Пара серверов с веб-приложениями, которые «уже не используются, но пусть стоят». На них оказались уязвимые версии log4j. Решение простое - остановить и выключить, что и сделали. Но факт: они были доступны снаружи.

Почему аудит затянулся

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

Кто владелец этого сервиса? Кто обновляет зависимости? Есть ли вообще список того, что запущено на этих серверах?

Ответы были предсказуемо размытыми. Никаких SBoM, никаких актуальных реестров компонентов - только устные «да там Spring Boot крутится, стандартный набор». Spring Boot, да. С какой версией Log4j внутри - это уже другой вопрос.

Что помогает сканировать

Инструментально ничего революционного - те же syft и grype для анализа файловой системы и образов, плюс log4j-detector от Mergebase для поиска jar-ов с уязвимыми классами внутри uber-jar-ов. Последнее важно: log4j может быть упакован внутрь fat jar приложения, и простой grep по имени файла его не найдёт.

Схема работы:

1. Инвентаризация хостов (что вообще запущено)
2. Поиск jar/war/ear файлов на файловой системе
3. log4j-detector по найденным архивам
4. syft для образов в [container registry](/blog/terms/docker-registry/)
5. grype для сопоставления с CVE базой
6. Ручная проверка сторонних продуктов

Всё это не ракетостроение, но требует времени и доступа. А доступ надо согласовывать.

SBOM - не роскошь

Главный вывод декабря, который январь только подтверждает: если бы у клиентов был актуальный SBOM хотя бы по критичным системам, время реакции сократилось бы в разы. Мы это проверили на себе в декабре - там, где реестр был, первичный скан занял часы. Там, где его не было, работа растянулась на недели.

Это не абстрактный тезис из документации NIST. Это конкретные дни потерянного времени и нервов в новогодние праздники.

Сейчас по итогам аудита мы предлагаем нескольким клиентам выстроить процесс ведения компонентного реестра - пусть даже в минимальном варианте: список сервисов, язык/рантайм, ключевые зависимости и версии. Ничего автоматизированного, просто живой документ, который кто-то отвечает за обновление. Начать с малого.

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