0-day в библиотеке Log4j представляет угрозу для множества приложений и серверов

Разработчики Apache Software Foundation выпустили экстренное обновление безопасности, исправляющее 0-day уязвимость (CVE-2021-44228) в популярной библиотеке журналирования Log4j, входящей в состав Apache Logging Project. Патч вышел в рамках релиза 2.15.0, пишет Хакер.

Упомянутая уязвимость получила название Log4Shell и набрала 10 баллов из 10 возможных по шкале оценки уязвимостей CVSS. Баг допускает удаленное выполнение произвольного кода (RCE). Проблема усугубляется тем, что вчера ИБ-исследователь p0rz9 уже опубликовал в Twitter PoC-эксплоит, а использовать уязвимость можно удаленно, причем для этого не нужны особые технические навыки.

Принцип работы Log4Shell описывают специалисты компании LunaSec: уязвимость вынуждает приложения и серверы на основе Java, где используется библиотека Log4j, журналировать определенную строку в своих внутренних системах. Когда приложение или сервер обрабатывают такие логи, строка может заставить уязвимую систему загрузить и запустить вредоносный скрипт из домена, контролируемого злоумышленником. Итогом станет полный захват уязвимого приложения или сервера.

Исходно проблема была обнаружена во время поиска багов на серверах Minecraft, но Log4j присутствует практически в любых корпоративных приложениях и Java-серверах. К примеру, библиотеку можно найти почти во всех корпоративных продуктах, выпущенных Apache Software Foundation, включая Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo и так далее. Также Log4j активно применяют в различных опенсорсных проектах, включая Redis, ElasticSearch, Elastic Logstash, Ghidra и других.

Таким образом, компании, использующие любой из этих продуктов, тоже косвенно уязвимы перед атаками на Log4Shell, но могут даже знать об этом. ИБ-специалисты уже сообщают, что перед Log4Shell могут быть уязвимы решения таких гигантов, как Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase и, вероятно, тысячи других компаний.

Вчера p0rz9 писал, что эксплуатация CVE-2021-44228 возможна лишь в том случае, если для параметра log4j2.formatMsgNoLookups установлено значение false. Издание The Record сообщает, что, по информации компании KnownSec 404 Team, в релизе Log4j 2.15.0 для этого параметра установлено значение true, специально для предотвращения атак. Это означает, что пользователи Log4j, которые обновились до версии 2.15.0, а затем установили флаг на значение false, вновь будут уязвимы для атак. Причем пользователи Log4j, которые не обновились, но установили флаг на значение true, все равно смогут блокировать атаки даже на более старых версиях.

К сожалению, также это значит, что в опасности находятся все старые версии, где для этого параметра по умолчанию установлено значение false. То есть уязвимы все предыдущие выпуски Log4j, начиная с 2.10.0.

По данным специалистов Bad Packets и Greynoise, несколько злоумышленников уже сканируют сеть в поисках приложений, которые могут быть уязвимы перед Log4Shell, то есть времени на установку исправлений уже практически не осталось.