Привет, Хабр! Сегодня мы хотим рассказать об уязвимости 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, а также посмотреть презентацию с прошедшего вебинара.
