Привет, Хабр! Сегодня мы хотим рассказать об уязвимости Apache Log4j, которая стала причиной огромной волны атак на веб-серверы по всему миру на протяжении декабря. В пиковые дни мы наблюдали до нескольких десятков тысяч атак в час! И сегодня наша команда хочет поделиться методами простого устранения уязвимости для разных версий библиотеки. Конкретные рекомендации, а также ссылку на вебинар с подробным обсуждением CVE вы найдете под катом.
Уязвимость Log4J была обнаружена 9 декабря 2021 года. И на протяжении всего декабря являлась серьезной проблемой для ИТ-специалистов во всем мире. Товарищи, которые уже готовились доделывать основные дела под конец года и уходить на праздники (наши к 1 января, а жители западных стран — уже завтра), были вынуждены срочно что-то делать, чтобы решить проблему возникновения потенциальных эксплойтов на базе критически опасной уязвимости.
Эксперты Acronis в области киберзащиты провели информационный вебинар для глобального сообщества Acronis на английском языке (ссылка на него внизу). О новой уязвимости рассказали Кевин Рид (CISO), Тофер Тебоу (Старший исследователь в сфере вредоносного ПО), Джеймс Слэби (Директор по киберзащите) и Коллин Аподак (Менеджер по разработке решений). Мероприятие вышло интересным — несколько сотен человек приняли в нем участие, чтобы разобраться с особенностями уязвимости Log4j и принять меры для ее устранения. Другими словами, защитить системы компании, процессы клиентов и, конечно, свои новогодние/рождественские отпуска от необходимости все бросать и чинить сломанные ИТ-инфраструктуры. :)
Роль Apache Log4j в экосистеме
Если вы не знаете точно, что такое Log4j (или подзабыли, с кем не бывает?) — это библиотека логирования для JVM-языков, разрабатываемая Apache. Она часто используется в инсталляциях, чтобы сторонние приложения могли использовать стандартные функции протоколирования данных, сохраняя их, например, в текстовых файлах. Это очень популярная библиотека, потому что она проста в использовании. Фактически на нее завязаны тысячи приложений, вплоть до Steam, Minecraft, Blender, LinkedIn, VMware и так далее. Тот факт, что библиотеку загрузили с GitHub более чем 400 000 раз говорит сам за себя.
В чем состоит уязвимость Log4j? Как она работает?
Уязвимость Log4j также известна как Log4Shell или CVE-2021-44228. Это критическая брешь в ПО, которая позволяет злоумышленникам запускать неавторизованный удаленный код, просто отправив команду на логирование определенной строки. Эта угроза во многом напоминает ту уязвимость, которую использовали злоумышленники при supply-chain атаках на Kaseya и SolarWinds. Поэтому потенциальная опасность от атаки на Log4j достаточно высока.
Появление самой уязвимости обусловлено архитектурой языка Java, который является полностью объектно-ориентированным. Благодаря некоторым приемам злоумышленники нашли способ передать произвольный код на исполнение…В результате уязвимость может быть использована для кражи данных и подгрузки дополнительного вредоносного кода — установки Ransomware, запуска скрытого крипто-майнинга, подключения компьютера к сети ботнет и так далее. На протяжении некоторых дней декабря эксперты Acronis наблюдали десятки тысяч попыток использовать эту уязвимость со стороны неизвестных каждый час! Так что киберпреступники прекрасно осведомлены о новой возможности.
Что еще хуже, промежуток времени между реальным использованием уязвимости и запуском вредоносного ПО в вашем окружении может быть различным. То есть даже если вы уже разобрались с самой уязвимостью, есть вероятность отложенного запуска вредоносного ПО и фактической эксплуатации бреши в защите. Поэтому одного сканирования инфраструктуры на предмет наличия уязвимости может быть недостаточно.
Реагирование на уязвимость Log4j
Ведущие поставщики решений киберзащиты, тем временем, обеспечивают безопасность для любых продуктов, связанных с Apache. В частности, системы патч-менеджмента, встроенные в комплексные средства защиты, должны обеспечить загрузку новейшего обновления Apache Log4j.
Дело в том, что уязвимость характерна почти для каждой версии Apache Log4j, от 2.0-beta9 до 2.14.1 и некоторых более новых версий. Но новейший релиз 2.17.0, который можно получить из Apache Logging Services, обеспечивает защиту по умолчанию, потому что подобные действия в версии 2.17.0 заблокированы, если вы их не активируете при конфигурировании инструмента.
Но если вы не можете обновить все соответствующие системы по какой-либо причине, все же существует несколько превентивных действий, которые позволят снизить вероятность компрометации софта в ближайшей перспективе (но не избежать!):
Администраторы, использующие версии Log4j 2.10–2.14.1 могут отключить “message lookup substitution”, установив system property log4j2.formatMsgNoLookups или присвоив переменной LOG4J_FORMAT_MSG_NO_LOOKUPS значение “true”.
Те, кто пользуется версиями Log4j 2.0-beta9–2.10.0, следует удалить класс JndiLookup из classpath.
Заблокируйте или настройте мониторинг всех исходящих соединений и запросов DNS с серверов, которые могут потенциально быть вовлечены в атаку.
Узнать больше об уязвимости, вы можете прочитать рекомендацию Security Advisory, а также посмотреть презентацию с прошедшего вебинара.
Комментарии (18)
dopusteam
28.12.2021 20:44+4тау далее
Тот факт, что библиотеку загрузили с GitHub более чем 400 000 раз.
Что? Это полное предложение?
кретическая
Появление самой уязвимости обусловлено архитектурой языка Java, который является полностью объектно-ориентированным. Благодаря некоторым приемам злоумышленники нашли способ передать исполняемый файл на исполнение…а Java при этом просто автоматически запускает его
Что? Вы точно в курсе как там всё работает?
киберазищты
обеспечиюват
Знаю, что для ошибок есть ctrl+enter, но тут совсем жесть какая то местами
Mudrist
28.12.2021 22:04Автора правильно критикуют за ОчЕпЯтки. )) Но советы дельные. Благодарю.
sshikov
28.12.2021 23:32+5Советы устарели недели на две. И поэтому уже просто неверные.
Ivan_2424 Автор
29.12.2021 00:06+2Вы уж извините, но это мой первый текст и хабр неделю его в песочнице держал. Это с одной стороны. А с другой стороны - я же указал в тексте, что эти методы снижают вероятность. Разве нет? Что делать тем, кто не может сделать апдейт до 2.17 прямо сейчас?
sshikov
29.12.2021 09:07+2Не снижают они (ну разве что класс удалить). Они дадут ложное ощущение, что вы что-то исправили.
Неделю в песочнице — ну это вполне понять можно. Но качество текста это не оправдывает ни разу.Появление самой уязвимости обусловлено архитектурой языка Java, который является полностью объектно-ориентированным. Благодаря некоторым приемам злоумышленники нашли способ передать исполняемый файл на исполнение…а Java при этом просто автоматически запускает его
Повторю предыдущего комментатора — у меня тоже полное впечатление, что вы просто вообще не в курсе, как там все работает. И объектно ориентированность тут никаким боком не стояла, и файл не передается (передается java-класс, а это не обязательно файл), и никто его не запускает (выполняется метод класса). Во всяком случае если в таких терминах это все описывать — это описание скорее дезориентирует, чем помогает. И не DNS там может быть, а изначально был LDAP.
wAngel
28.12.2021 23:02+2У вас устаревшие данные и вы вводите людей в заблуждение.
LOG4J_FORMAT_MSG_NO_LOOKUPS недостаточно (https://logging.apache.org/log4j/2.x/security.html)
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
Версия 2.15, которую вы называете "новейшей", на данный момент (28.12.2021) а) уязвима к CVE-2021-45046 б) уж точно не новейшая.
Единственный правильный вариант по исправлению уязвимости в своих приложениях на данный момент - обновление на 2.17.
Ivan_2424 Автор
28.12.2021 23:11Спасибо про информацию о 2.15. Не знал. Поправил на 2.17. Но все остальное хотя бы улучшает ситуацию, если обновление пока невозможно.
BugM
29.12.2021 00:51+1Никак не улучшает. Или у вас есть RCE на серверах или нет. Промежуточного варианта тут нет. Именно этим эта уязвимость и ужастна. От нее фиг защитишься любыми внешними методами.
Можно было бы посоветовать проверить все места где вы логируете пользовательский ввод и не делать этого. Это тоже поможет. Но толку? Это по сути невозможно и точно сложнее обновления версии.
Shaman_RSHU
29.12.2021 12:26Новая RCE-уязвимость в библиотеке Apache Log4j
В открытых источниках опубликована информация об уязвимости в Apache Log4j версии 2.17.0. Уязвимость связана с отсутствием дополнительных элементов управления доступом JDNI в log4j.
CVE-2021-44832 (CVSSv3:6.6, SberCVSS: 5.4; Уровень риска: B) Злоумышленник имеет возможность создать вредоносную конфигурацию с помощью функции JDBC Appenders с источником данных, ссылающимся на URI JNDI, который позволяет выполнять удаленный код. Необходимо, чтобы злоумышленник имел разрешение на изменение файла конфигурации журналирования.
Уязвимые версии: Версии Apache log4j 2.17.0, 2.12.3, 2.3.1
Данной уязвимости подвержен только файл JAR log4j-core. Приложения, использующие только файл JAR log4j-api без файла JAR log4j-core, не подвержены уязвимости CVE-2021-44832.
На момент публикации обновления сообщается об отсутствии эксплойта в открытом или коммерческом доступе.
Для устранения уязвимости CVE-2021-44832 необходимо выполнить обновление log4j до версии 2.17.1(для Java 8 и новее), 2.12.4 (для Java 7), 2.3.2 (для Java 6).
Рекомендации Apache:
https://logging.apache.org/log4j/2.x/security.html
somurzakov
30.12.2021 03:13>>SberCVSS: 5.4
а что такое СберCVSS? Можете рассказать подробнее, как считается?
sergey-b
31.12.2021 17:36https://nvd.nist.gov/vuln/detail/CVE-2021-44832
CVSSv2 score 6.0 Medium
CVSSv3 score 6.6 Medium
остальное - просто привиделось
aleks_pingvin
Простите, но это библиотека логирования для jvm-based языков (kotlin, scala и т. п.) разработанная и поддерживаемая Apache Foundation
Ivan_2424 Автор
Спасибо, поправил