До дополнения политика Solar appScreener выявляла любые недоверенные данные, которые записывались в журнал и определяла их как уязвимость вида «Подделка файла лога» (Log Forging). Сейчас инструмент анализа кода был обновлен дополнительными правилами, что позволяет отдельно подчеркивать уязвимости Log4Shell в рамках обнаруженных уязвимостей вида «Подделка файла лога».
«Компании во всем мире широко используют уязвимую библиотеку Apache Log4j в разработке Java- продуктов. Если к этому факту добавить невысокую сложность эксплуатации уязвимостей, получаем большое количество уязвимых систем и большое количество злоумышленников, которые, не обладая сложными техническими навыками, могут взломать эти системы, — Даниил Чернов, директор Центра Solar appScreener компании «Ростелеком-Солар». — Проблема усугубляется тем, что во многих организациях не выстроен процесс мониторинга уязвимостей, поэтому несмотря на наличие патчей безопасности и рекомендаций по устранению брешей, некоторые организации до сих пор остаются под угрозой. Наша исследовательская лаборатория следит за уязвимостями Log4Shell, а команда разработчиков оперативно отражает их в базе поиска уязвимостей Solar appScreener».
В базу сканера анализа Solar appScreener были добавлены правила для поиска всех выявленных на текущий момент уязвимостей библиотеки Apache Log4j:
Уязвимость дает возможность в приложениях и серверах на основе Java, в которых используется библиотека Log4j, сохранять определенную строку в логах. Когда приложение или сервер обрабатывают логи, строка может заставить уязвимую систему загрузить и запустить вредоносный код. В результате злоумышленнику удается заполучить полный контроль над уязвимым приложением или сервером. После того атака может развиться дальше.
Разработчики Apache Software Foundation выпустили экстренное обновление безопасности — с версии 2.15.0 проблема была частично устранена. Версия 2.15.0 не учитывает некоторые варианты обработки логов, что оставляет злоумышленникам возможность провести атаку на уязвимую систему.
Исправление 2.15.0 закрывает брешь благодаря отключению lookup JNDI-сообщений. В недефолтных конфигурациях он может быть использован для создания вредоносного input с использованием шаблона JNDI lookup. Это может привести к атаке типа «Отказ в обслуживании» и выполнения произвольного кода. Этому сценарию присвоили отдельный идентификатор CVE-2021-45046.
Эксплуатация CVE-2021-44228 возможна, если для параметра log4j2.formatMsgNoLookups установлено значение false. Для предотвращения атак в патче Log4j 2.15.0 для этого параметра установлено значение true. При обновлении 2.15.0 не следует менять параметр на значение false. Пользователи библиотеки Log4j, которые не обновились, но установили значение true, могут блокировать атаки.
В Log4j версии 2.15.0 было можно проэксплуатировать уязвимость CVE-2021-44228 при определенных пользовательских настройках конфигурации. В ней был отключен лишь один аспект функционала JNDI по поиску сообщений. В обновлении 2.16 по умолчанию была отключена поддержка JNDI, обработка поиска сообщений была полностью удалена.
Уязвимость затрагивает версии Log4j от 2.0-beta9 до 2.16.0. В перечисленных версиях отсутствовала защита от неконтролируемой рекурсии, что позволяло злоумышленнику, проводя манипуляции со значением при подстановке, вызвать зацикливание. Зацикливание приводило к исчерпанию места в стеке и аварийному завершению процесса. Патч выпущен в версии 2.17.0.