В начале недели эксперт по кибербезопасности Alibaba Чен Жаожун обнаружил критическую уязвимость в Java-библиотеке Log4j, которая используется в сотнях тысяч приложений по всему миру. Уязвимость позволяет получить удаленный доступ к серверу, на котором хранится приложение, и запустить на нем произвольный код. Вместе с экспертами разбираемся, почему библиотека так популярна, в чем суть уязвимости и как ее можно устранить.
Log4j — часть проекта Apache Logging Project. Это библиотека для логирования, которая помогает анализировать поток выполняющихся инструкций на продакшене или в тестовом окружении. С ее помощью можно пометить все вызовы текстовыми инструкциями — это сильно упрощает процесс локализации проблем.
Библиотеку используют сотни тысяч программ, игр, облачных серверов и корпоративных приложений, в том числе от Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla и Twitter. В целом пользователей Log4j можно описать как очень крупные компании, которые по тем или иным причинам не используют актуальные версии Java. Чаще всего это энтерпрайз-сегмент, где любое обновление языка, фреймворка или библиотеки — большая проблема.
В энтерпрайз-сегменте наиболее популярны приложения, разработанные на технологии JavaEE/JakartaEE, а также с использованием Spring. В экосистеме Spring особую популярность последнее время получил фреймворк Boot, в котором в качестве дефолтной библиотеки логирования используется LogBack. Для компаний, которые используют Spring Boot (если не брать в расчет кастомное подключение Log4j2), уязвимость не грозит.
Уязвимость CVE-2021-44228 (или Log4Shell) относится к классу Remote Code Execution и присутствует только в версиях Log4j с 2.0-beta9 до 2.14.1.
Log4Shell для подключения к серверу использует JNDI (Java Naming and Directory Interface). Это API, которое предоставляет единообразный механизм взаимодействия Java-программы с различными службами имен и каталогов. Зная JNDI-имя LDAP-сервера, базы данных или месседж-брокера, можно получить доступ к ним, используя операцию lookup.
Еще одно уязвимое место касается безопасности строк. Часто бывает так, что переменные раскрываются не только в конфигурационном файле, важном звене взаимодействия с библиотекой логирования, но и в строках. В ситуации с небезопасными строками библиотека сканирует сообщения пользователей и если видит в них исходный код, исполняет его. После этого хакер может загрузить вредоносный код на сервер — исследователи из SecurityLab описывают случаи, когда Log4Shell использовали для майнинга криптовалют или для DDoS-атак.
Составьте свое первое резюме: Вы можете бесплатно опубликовать свое резюме в нашем сервисе «Хекслет-CV» и получить советы по его улучшению от разработчиков и HR-менеджеров
Лучший совет, который можно дать в сложившейся ситуации — обновить Log4j до версии 2.15 или Java до версии 11. Если обновление — это проблема, есть несколько альтернативных решений:
Несколько более сложных решений описаны здесь.
Большинство уязвимостей возникают в старых версиях языков, библиотек и фреймворков, поэтому нужно стараться регулярно обновлять их. Для больших компаний это непозволительная роскошь, но безопасные и не подверженые уязвимостям приложения требуют регулярного повышения версий.
Кроме того, полезно периодически (раз в три-шесть месяцев) проводить аудит безопасности систем, которые эксплуатируются в продакшене. Не менее важно следовать рекомендациям, которые содержатся в отчетах службы безопасности. Это помогает выявлять общие проблемы и справляться со срочными изменениями (правда, с некоторыми ограничениями).
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях