Джен Истерли, директор CISA, говорит, что Log4j — худшее, что она видела, и что они будут работать еще долгие годы.

log4j

Директор КИСА, Джен Истерли говорит, что уязвимость в безопасности Log4j — худшая из тех, что она видела в его карьере y los специалисты по безопасности столкнутся с последствиями от ошибки в течение длительного времени.

Если оставить без исправления главный недостаток безопасности, обнаруженный месяц назад в библиотеке протоколирования Java Apache Log4j создает риски для больших секторов Интернета, хакеры могут использовать уязвимость широко используемого программного обеспечения для захвата компьютерных серверов, подвергая риску кибератаки все, от бытовой электроники до правительственных и корпоративных систем.

9 декабря было обнаружено уязвимость в лог-библиотеке Apache log4j. Эта библиотека широко используется в проектах разработки приложений Java/J2EE, а также поставщиками стандартных программных решений на основе Java/J2EE.

Log4j включает механизм поиска, который можно использовать для запроса через специальный синтаксис в строке формата. По умолчанию все запросы делаются с префиксом java:comp/env/*; нО ТЕМ НЕМЕНЕЕ, авторы реализовали возможность использования пользовательского префикса используя символ двоеточия в ключе. Вот здесь и кроется уязвимость: если в качестве ключа используется jndi:ldap://, запрос идет на указанный LDAP-сервер. Другие протоколы связи, такие как LDAPS, DNS и RMI, также могут использоваться.

Таким образом, удаленный сервер, контролируемый злоумышленником, может вернуть объект на уязвимый сервер, что может привести к выполнению произвольного кода в системе или утечке конфиденциальных данных. Все, что нужно сделать злоумышленнику, — это отправить специальную строку через механизм, который записывает эту строку в файл журнала и, следовательно, управляется библиотекой Log4j.

Это можно сделать с помощью простых HTTP-запросов, например, отправленных через веб-формы, поля данных и т. д., или с помощью любого другого типа взаимодействия с использованием реестра на стороне сервера.

  • Версия 2.15.0 не решила другую проблему, CVE-2021-45046, которая позволяла удаленному злоумышленнику управлять картой контекста потока (MDC) для подготовки вредоносной записи с использованием шаблона поиска JNDI. Результатом может быть удаленное выполнение кода, к счастью, не во всех средах.
  • Версия 2.16.0 устранила эту проблему. Но это не исправило CVE-2021-45105, которую Apache Software Foundation описывает следующим образом:

«Версии Apache Log2.0j1 от 2.16.0-alpha4 до 2 не защищали от неконтролируемого повторения самореферентного поиска. Если в конфигурации реестра используется макет шаблона, отличный от используемого по умолчанию, с контекстным поиском (например, $$ {ctx: loginId}), злоумышленники, контролирующие входные данные Thread Context Map (MDC), могут создавать данные для входа.Вредоносная запись, содержащая рекурсивный поиск . , который генерирует StackOverflowError, завершающий процесс. Это также известно как атака типа «отказ в обслуживании» (DOS).

Независимая от поставщиков программа поощрения ошибок Zero Day Initiative описала недостаток следующим образом:

«Когда вложенная переменная заменяется классом StrSubstitutor, он рекурсивно вызывает класс подстановки (). Однако когда вложенная переменная ссылается на заменяемую переменную, рекурсия вызывается с той же строкой. Это приводит к бесконечной рекурсии и состоянию DoS на сервере».

Еще одна критическая ошибка удаленного выполнения кода теперь отслеживается как CVE-2021-44832 была обнаружена в той же библиотеке журналов Apache Log4j.. Это четвертая уязвимость в библиотеке Log4j.

Уязвимость, оцененная как «умеренная» по степени серьезности с оценкой 6,6 по шкале CVSS, связана с отсутствием дополнительных средств управления доступом JDNI в log4j.

Команда безопасности Apache выпустила еще одну версию Apache Log4J (версия 2.17.1), в котором исправлена ​​недавно обнаруженная ошибка удаленного выполнения кода CVE-2021-44832. Это еще одна плохая ситуация для большинства пользователей, но опять же настоятельно рекомендуется обновить вашу систему, чтобы исправить эту критическую проблему.

Ни одно федеральное агентство США не было скомпрометировано из-за уязвимости, сказала журналистам Джен Истерли. Кроме того, в Соединенных Штатах не было зарегистрировано никаких крупных кибератак, связанных с ошибкой, хотя о многих атаках не сообщается, сказал он.

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

«Мы надеемся, что Log4Shell будет использоваться для вторжений в будущем», — сказал Истерли. Он отметил, что утечка данных Equifax в 2017 году, в результате которой была скомпрометирована личная информация почти 150 миллионов американцев, произошла из-за уязвимости в программном обеспечении с открытым исходным кодом.

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

источник: https://www.cnet.com


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

Комментарий, оставьте свой

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

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

*

*

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

  1.   Люкс сказал

    Это из-за чрезмерной инженерии. Каждый компонент должен делать только одну вещь и делать это хорошо. Но у разработчиков есть плохая привычка размещать слои и еще больше слоев и ненужных функций, которые не делают его более сложным и подверженным такого рода сбоям.. Я сказал..