Инциденты и уязвимости
Log4Shell (CVE-2021-44228) — ночь, когда мир боялся бага, наличие которого не мог даже подтвердить
В декабре 2021 года в Log4j была RCE уровня CVSS 10.0. Настоящий ужас: быть затронутым через библиотеку, об использовании которой вы не знали (транзитивные зависимости). Как логирование стало вектором атаки, и уроки: SBOM, машинный мониторинг, быстрый патчинг.
Возвращаемся к знаковому событию — не чтобы воспроизвести атаку, а ради уроков, которые всё ещё применимы к вашей эксплуатации.
Что произошло — пассивный путь становится вектором атаки
Log4j занимался обыденной задачей записи логов и был практически везде в мире Java. Уязвимость: библиотека интерпретировала определённый шаблон внутри логируемых строк как нечто, что нужно «разрешить, обратившись наружу», и в итоге выполняла указанный извне код.
Так злоумышленник, подсунувший сформированную строку в «куда-то, что логируется» (имя пользователя, заголовок), мог добраться до выполнения кода. Шок от того, что пассивное действие вроде логирования стало путём атаки, был глубоким.
Почему «затронуты ли мы?» было так трудно ответить
Большинство приложений никогда не устанавливали Log4j напрямую. Его подтягивал фреймворк или SDK — транзитивная зависимость: зависимость зависимости зависимости. Без вашей «ведомости материалов» вы не могли даже определить, затронуты ли вы.
Самым страшным было «вы не можете определить»
Когда вы «не можете определить, используете ли вы это», вы не можете даже приоритизировать реагирование. Была ли у вас ведомость материалов (SBOM) решало, как прошла та ночь.
Хронология
2021-12-09–10
Уязвимость становится широко известной; мир спешно проверяет «затронуты ли мы?».сразу после
Развёртываются экстренный патчинг и временные меры; всплеск попыток эксплуатации.впоследствии
Публикуется несколько последующих CVE (исправления к исправлению) — «исправлено один раз» не было концом.
Уроки, которые всё ещё применимы
Имейте SBOM (ведомость материалов)
Сделайте видимым, что ваше приложение использует внутри — npm ls / lock-файлы / инструменты SBOM показывают, что реально работает. Смотреть только на «что вы установили напрямую» недостаточно.
Машинно мониторьте зависимости
В момент выхода CVE автоматически узнавайте, применим ли он (Dependabot / osv-scanner) — включая транзитивные зависимости. Ручные обходы всегда что-то упускают.
Делайте патчинг быстрым
Держите натренированной мышцу «обновить, проверить, выкатить» для экстренных случаев. См. построение мониторинга зависимостей.
Отслеживайте последующие CVE
После Log4Shell появились исправления к исправлению. Не останавливайтесь на «исправлено один раз» — отслеживайте продолжения.
Читать дальше
- Глоссарий: Что такое RCE · Что такое CVE
- Защита: Встройте мониторинг зависимостей в эксплуатацию
- Инцидент: Запущенный известный CVE привёл к утечке 147M
- Инцидент: Heartbleed — критическая уязвимость OpenSSL
FAQ
QЧто было «нового» в страхе перед Log4Shell?
Он обнажил опасность транзитивных зависимостей в глобальном масштабе: быть уязвимым через библиотеку, используемую внутри другой библиотеки, даже без прямой установки. Не зная свой SBOM, вы не могли даже определить, затронуты ли вы.
QПочему логирование стало вектором атаки?
Log4j интерпретировал определённый текст внутри логируемых строк как нечто, что нужно «разрешить, обратившись наружу». Злоумышленнику оставалось лишь подсунуть сформированную строку туда, где она будет залогирована (имя пользователя, HTTP-заголовок), превратив пассивный путь логирования в выполнение кода.
QКак избежать повторения?
Три вещи: машинно мониторить зависимости (Dependabot/osv-scanner), генерировать SBOM, чтобы видеть, что вы реально используете, и вести процесс обновления достаточно быстрый, чтобы оперативно патчить — и отслеживать последующие CVE (исправления к исправлению).