Уязвимость Log4j, известная как Log4Shell, позволяла удаленно выполнить произвольный код на системах с уязвимыми версиями Apache Log4j 2. Проблема получила идентификатор CVE-2021-44228 и стала одной из самых опасных в истории из-за масштаба распространения библиотеки и простоты эксплуатации.
Log4j встроен в большое число приложений, серверов и облачных сервисов. По этой причине исправление одной библиотеки быстро превратилось в долгую работу по всей цепочке поставки программного обеспечения.
Содержание статьи
Почему Log4Shell считают критической уязвимостью
Log4Shell открывала путь к удаленному запуску кода без предварительной авторизации. Для атакующего это означало возможность заставить целевую систему загрузить и выполнить вредоносный код.
Уязвимость обнаружили в конце ноября 2021 года, а уже в декабре началась массовая эксплуатация. Проблема затронула Apache Log4j 2 до версии 2.15.0, прежде всего ветки 2.0-beta9–2.14.1, где присутствовала опасная обработка JNDI-запросов.
Высокий риск объяснялся сразу несколькими факторами. Библиотека использовалась повсеместно. Эксплуатация не требовала редких условий. Уязвимый компонент часто находился глубоко внутри чужих зависимостей, поэтому многие компании не могли быстро понять, затронуты ли их системы.
Что такое Log4j
Log4j — это библиотека журналирования для Java-приложений. Она записывает события работы программы: ошибки, служебные сообщения, действия пользователя и другие данные, которые нужны для диагностики и сопровождения.
Проект развивает Apache Software Foundation. Разработчики используют Log4j как готовый компонент, чтобы не писать систему логов с нуля.
Именно эта удобная модель и привела к широкому распространению. Библиотека попадала в приложения напрямую и через сторонние пакеты. В результате один дефект в популярной зависимости затронул огромный пласт программ.
Какие версии затронула уязвимость
Основная уязвимость Log4Shell относится к Apache Log4j 2 до версии 2.15.0. Наибольшее внимание получили версии до 2.14.1 включительно, где проблема позволяла удаленное выполнение кода.
Все версии Apache Log4j 1 не подпадали под CVE-2021-44228, хотя сама первая ветка имела другие известные риски и давно считалась устаревшей. После первых исправлений выяснилось, что тема не закрыта: за Log4Shell последовали дополнительные CVE, связанные с неполным устранением проблемы.
| Компонент | Статус |
| Apache Log4j 2 до 2.15.0 | Уязвим к Log4Shell |
| Apache Log4j 2.15.0 | Первое исправление, затем выявлены новые проблемы |
| Apache Log4j 2.16.0 | Дополнительное исправление, позже найден еще один дефект |
| Apache Log4j 2.17.0 | Закрыта часть рисков, затем выявлен еще один CVE |
| Apache Log4j 2.17.1 и новее | Линейка исправлений для этой серии завершена |
| Apache Log4j 1 | Не затронут CVE-2021-44228 |
Как работала эксплуатация Log4Shell
Проблема возникала из-за обработки JNDI-запросов в старых версиях Log4j 2. Если в журнал попадала специально сформированная строка, библиотека могла обратиться к внешнему серверу и загрузить оттуда данные или код.
JNDI означает Java Naming and Directory Interface. Это интерфейс Java для доступа к внешним ресурсам. В обычной разработке такой механизм применяют для поиска объектов и служб, но в случае Log4Shell он создал опасный путь для внедрения команды извне.
Схема атаки выглядела просто. Атакующий размещал вредоносный объект на своем сервере, затем передавал в приложение строку, которая попадала в логи. После обработки этой строки уязвимый Log4j обращался к серверу злоумышленника и запускал полученное содержимое.
Почему обычное поле ввода могло стать точкой входа
Любое место, где приложение записывало пользовательский ввод в журнал, могло использоваться в атаке. Под угрозой оказывались формы входа, поля поиска, заголовки HTTP-запросов, окна чата и другие каналы ввода.
Опасность была в том, что пользовательский текст сам по себе не выглядел как исполняемый файл. Он лишь попадал в лог. Дальше срабатывала внутренняя логика библиотеки, и уже она делала внешний запрос.
Почему уязвимость получила максимальную оценку
Log4Shell получила 10 баллов из 10 по шкале CVSS. Такая оценка отражает сочетание простоты атаки, тяжести последствий и огромного числа затронутых систем.
- На момент обнаружения это была уязвимость нулевого дня: публичного исправления еще не было.
- Log4j применялся в веб-приложениях, корпоративных системах, облачных сервисах и пользовательском ПО.
- Во многих случаях библиотека присутствовала как косвенная зависимость, поэтому ее было трудно быстро найти.
- Эксплуатация могла начинаться без учетной записи и без специальных прав.
- После успешного запуска кода атакующий получал широкий контроль над системой.
В декабре 2021 года публикация демонстрационного кода резко упростила задачу злоумышленникам. После этого атаки пошли волной и затронули как крупные сервисы, так и обычные корпоративные сети.
Какие последствия вызывала Log4Shell
Главное последствие — удаленное выполнение произвольного кода. На практике это позволяло устанавливать вредоносные программы, красть данные, открывать постоянный доступ и использовать систему как опорную точку для дальнейшего проникновения.
В первые недели после раскрытия уязвимости исследователи фиксировали кампании с ботнетами и майнерами. Позднее через ту же дыру распространяли программы-вымогатели и безфайловые сценарии для Windows и Linux.
Под ударом оказывались не только отдельные серверы. Если уязвимый компонент имел связь с другими сервисами, атакующий мог продвигаться дальше по инфраструктуре. Из-за этого даже один забытый экземпляр Log4j создавал риск для соседних систем.
Как развивалось исправление Log4j
Первое обновление вышло быстро, но оказалось неполным. После релиза Apache пришлось выпускать еще несколько версий, поскольку по ходу анализа находили новые связанные дефекты.
10 декабря 2021 года вышла версия 2.15.0. Затем обнаружили CVE-2021-45046, из-за чего 14 декабря появилась версия 2.16.0. Позже нашли CVE-2021-45105, после чего выпустили 2.17.0. Финальным шагом для этой линии стала версия 2.17.1, где закрыли CVE-2021-44832.
Эта цепочка хорошо показала типичную проблему кризисного исправления. При массовом инциденте сначала закрывают самый опасный сценарий, а потом уже вычищают соседние риски, которые становятся заметны после первого патча.
Почему Log4Shell оставалась актуальной спустя месяцы
Даже после выхода исправлений уязвимость не исчезла из практики. Причина была в том, что Log4j присутствовал глубоко внутри программных зависимостей, а часть систем так и не получила обновления.
У организаций часто не было полной карты используемых библиотек. Команда могла обновить собственное приложение, но пропустить сторонний компонент с уязвимой сборкой. Были и повторные появления проблемы: после очередной сборки или обновления в систему снова попадала старая версия Log4j.
Отдельный риск описывали и регуляторы по кибербезопасности. Атакующий мог использовать Log4Shell для проникновения, а затем закрыть уязвимый путь или дождаться, пока это сделает владелец системы. Внешне узел выглядел исправленным, но злоумышленник уже закрепился внутри.
Как проверить и снизить риск Log4Shell
Базовая мера защиты — найти все экземпляры Log4j и обновить их до безопасной версии. Если обновление нельзя выполнить сразу, нужно выявлять попытки эксплуатации и ограничивать путь к внешним серверам, которые могут использоваться в атаке.
- Собрать перечень приложений и сервисов, где используется Log4j напрямую или через зависимости.
- Проверить версии библиотеки в каждой системе и контейнере.
- Обновить уязвимые экземпляры до исправленных релизов.
- Пересобрать приложения, если библиотека встроена внутрь пакета.
- Настроить сканирование уязвимостей и контроль интернет-доступных узлов.
- Проверить журналы на признаки эксплуатации и внешние обращения к подозрительным LDAP-серверам.
- Изучить следы закрепления после возможного взлома, даже если библиотека уже обновлена.
Для наблюдения за такими рисками применяют сканеры уязвимостей, средства управления внешней поверхностью атаки и системы обнаружения на конечных узлах. Также полезны правила в межсетевых экранах, IDS и IPS, которые умеют замечать типичные шаблоны попыток эксплуатации Log4Shell.
Чем Log4Shell отличается от обычной ошибки в библиотеке
Log4Shell стала системной проблемой цепочки поставки ПО. Ошибка находилась в популярной библиотеке общего назначения, поэтому один дефект затронул сразу множество независимых продуктов.
В обычной ситуации разработчик исправляет свой код и выпускает обновление. Здесь такой подход работал лишь частично. Нужно было не просто установить новый Log4j, а сначала понять, где именно он скрыт: в собственном приложении, в стороннем сервере, в контейнере, в агенте мониторинга или во внутреннем сервисе, о котором давно забыли.
Краткая хронология Log4Shell
Ключевые события уложились в несколько недель конца 2021 года, но последствия растянулись на годы. Ниже — основные даты, которые показывают, как быстро локальная уязвимость превратилась в глобальный инцидент.
- 18 июля 2013 года: в Log4j 2.0-beta9 появилась поддержка JNDI-плагина.
- 24 ноября 2021 года: исследователи Alibaba сообщили Apache об уязвимости.
- 9 декабря 2021 года: в открытом доступе появился демонстрационный код эксплуатации.
- 10 декабря 2021 года: вышел первый патч 2.15.0.
- 14 декабря 2021 года: выпущено исправление для CVE-2021-45046 в версии 2.16.0.
- 17 декабря 2021 года: выпущено исправление для CVE-2021-45105 в версии 2.17.0.
- 28 декабря 2021 года: выпущена версия 2.17.1, закрывшая CVE-2021-44832.
- В 2022 и 2023 годах: уязвимость продолжала встречаться в эксплуатации из-за неустраненных или повторно появившихся экземпляров.
Что нужно запомнить о Log4j vulnerability
Log4j vulnerability, или Log4Shell, — это критическая уязвимость в Apache Log4j 2, позволявшая удаленно выполнить код через специально сформированные строки, попадавшие в журналы. Ее опасность определили три вещи: массовое распространение библиотеки, простая эксплуатация и плохая видимость зависимостей внутри программных продуктов.
С точки зрения защиты главный вывод предельно практичный. Нужно контролировать состав зависимостей, проверять версии библиотек после каждой сборки и расследовать следы эксплуатации даже после установки патча.
