Как исправить уязвимость log4j

Время на прочтение
4 мин

Количество просмотров 20K

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

Уязвимость Log4j является одной из самых смертоносных проблем безопасности в современных системах.

Логирование является ключевой функцией в современных приложениях, и библиотека логирования Log4j является лидером в этой области.

Эта библиотека используется в большинстве приложений, сервисов и систем.

Следовательно, все те приложения, в которых используется Log4j, подвержены этой уязвимости Log4j, обнаруженной в прошлом году.

В связи с растущими проблемами кибербезопасности во всем мире организации и частные лица предпринимают шаги по защите своих приложений, систем и данных.

И когда эта уязвимость была обнаружена, это еще больше напрягло профессионалов и бизнесменов.

Следовательно, обнаружение уязвимости Log4j и ее устранение крайне важно, если вы хотите защитить свои данные, сеть, репутацию и доверие клиентов.

В этой статье мы расскажем о том, что такое уязвимость Log4j, а также о шагах по ее обнаружению и устранению.

Давайте начнем с понимания Log4j и того, зачем он вам нужен.

Что такое Log4j?

Log4j – это утилита ведения логов с открытым исходным кодом, написанная на языке Java, которая в основном используется для хранения, форматирования и публикации записей журналов, создаваемых приложениями и системами, а затем проверки на наличие ошибок.

Записи могут быть различных типов, от веб-страницы и данных браузера до технических данных системы, в которой работает Log4j.

Вместо того чтобы писать код с нуля, разработчики могут использовать библиотеку Log4j, интегрируя ее код в свои приложения.

Используя Log4j, разработчики могут отслеживать все события, связанные с их приложениями, с помощью точной информации журнала.

Это помогает им контролировать работу приложений, вовремя обнаруживать проблемы и устранять их до того, как они превратятся в большую проблему с точки зрения производительности и/или безопасности.

Эта библиотека на базе Java была написана Чеки Гюльцю и выпущена в 2001 году под лицензией Apache License 2.0.

Она использует службы Java naming and Directory Interface (JNDI), чтобы позволить приложениям взаимодействовать с другими приложениями, такими как LDAP, DNS, CORBA и т.д., и получить функциональность каталога и именования для Java-приложений.

Log4j, по сути, является одной из самых известных библиотек протоколирования в Интернете и используется организациями из различных отраслей и стран.

Они интегрировали эту библиотеку протоколирования во множество приложений, включая лучшие облачные сервисы Google, Microsoft, Apple, Cloudflare, Twitter и др.

Ее разработчик, Apache Software Foundation, разработал Log4j 2 – обновление Log4j для устранения проблем, обнаруженных в предыдущих версиях.

В прошлом году в Log4j была обнаружена уязвимость, которая, если ее не устранить, может позволить злоумышленникам взламывать приложения и системы, красть данные, заражать сеть и выполнять другие вредоносные действия.

Давайте разберемся в этом подробнее.

Как работает Log4Shell?

Чтобы понять серьезность проблемы и то, какой вред может нанести Log4Shell, необходимо узнать, как работает эта уязвимость Log4j.

Уязвимость Log4Shell позволяет злоумышленнику удаленно внедрить произвольный код в сеть и получить полный контроль над ней.

Последовательность кибератаки начинается с того, что библиотека протоколирования, например Log4j, собирает и хранит информацию журнала.

Если нет библиотеки протоколирования, то все данные с сервера будут архивироваться сразу же после сбора.

Но если вы хотите проанализировать эти данные или вам нужно предпринять какие-то действия на основе конкретной информации журнала, вам потребуется библиотека протоколирования для разбора данных журнала перед их архивацией.

Как уязвимость Log4j может навредить пользователям?

Уязвимость Log4j вызывает опасения, поскольку она используется в широком спектре программных приложений и систем.

Поскольку протоколирование является важной функцией в большинстве программных приложений, а Log4j является ведущим решением в этой области, Log4j находит применение в различных программных системах.

Среди популярных сервисов и приложений, использующих Log4j, – Minecraft, AWS, iCloud, Microsoft, Twitter, интернет-маршрутизаторы, инструменты разработки программного обеспечения, средства безопасности и так далее.

Таким образом, злоумышленники могут атаковать большое количество приложений, сервисов и систем домашних пользователей, разработчиков кода, поставщиков услуг и других специалистов и частных лиц.

Кроме того, уязвимость Log4j чрезвычайно легко эксплуатировать злоумышленнику.

Для осуществления атаки в целом требуется небольшое количество навыков, но не экспертного уровня.

Именно поэтому количество атак, использующих эту уязвимость, растет.

Обратите внимание, что все версии Log4j до Log4j 2.17.0. подвержены воздействию; следовательно, вы должны обновить регистратор, если вы его используете.

Кроме того, известными поставщиками, на которых распространяется эта уязвимость Log4j, являются Adobe, AWS, IBM, Cisco, VMware, Okta, Fortinet и др.

Если вы используете любого из них, постоянно контролируйте свои приложения и используйте системы безопасности для устранения проблем, как только они возникают.

Как обнаружить Log4j и устранить проблемы

Уязвимость Log4Shell имеет 10 баллов по шкале CVSS.

Следовательно, все проблемы в Log4j еще не исправлены.

Но есть вероятность, что вы или ваш сторонний поставщик можете использовать Log4j, который вы использовали в своем приложении.

Поэтому, если вы хотите защитить свои данные, системы и сеть, выполните несколько шагов по устранению проблем.

#1. Обновите версию Log4j

Обновление текущей версии Log4j до Log 4j 2.17.1 является наиболее эффективным методом устранения уязвимости, если вы хотите защитить свое устройство и приложения от атак, вызванных уязвимостью Log4j.

Log4Shell – это тип атаки нулевого дня, которая потенциально может повлиять на вашу экосистему программного обеспечения.

Apache исправил некоторые уязвимости в последних версиях, но если ваша система была скомпрометирована до обновления, вы все еще находитесь в зоне риска.

Поэтому, исходя из этого, вы должны не только обновить версию, но и немедленно начать процедуры реагирования на инциденты, чтобы убедиться в отсутствии уязвимостей в ваших системах и приложениях и смягчить последствия атак.

Вы также должны просмотреть все журналы сервера, чтобы найти индикаторы компрометации (IOC), и постоянно контролировать свои системы и сеть.

#2. Используйте новейшие брандмауэры и системы безопасности

Брандмауэры, такие как Web Application Firewall (WAF) и брандмауэры нового поколения, помогают защитить периметр вашей сети от злоумышленников, сканируя входящие и исходящие пакеты данных и блокируя подозрительные.

Поэтому используйте в своей сети новейшие брандмауэры и установите строгие правила исходящих пакетов на своих серверах, чтобы предотвратить атаки, связанные с уязвимостью Log4j.

Хотя злоумышленники могут обходить брандмауэры, вы все равно получите определенную степень безопасности с брандмауэрами, которые могут блокировать запросы злоумышленников.

Кроме того, обновите все свои системы безопасности, такие как системы обнаружения вторжений (IDS), системы предотвращения вторжений (IPS) и т.д., с последними сигнатурами и правилами.

Эти системы помогут блокировать или фильтровать трафик RMI и LDAP от подключения к вредоносному серверу LDAP.

#3. Внедрите MFA

Установка многофакторной аутентификации (MFA) в ваших приложениях и системах обеспечит лучшую защиту от злоумышленников.

Она обеспечит второй уровень безопасности, даже если злоумышленнику удастся взломать первый уровень.

Для этого можно использовать биометрические данные, такие как отпечатки пальцев, сканирование радужной оболочки глаза и т.д., задать секретный вопрос или включить секретный PIN-код.

Использование MFA увеличит трудности и время злоумышленников для проведения полномасштабной атаки.

В то же время, он может немедленно сообщить вам об инциденте, чтобы вы могли предпринять необходимые шаги по устранению последствий, когда у вас еще есть время.

Кроме того, для уменьшения утечек данных вы должны применять строгую политику VPN.

Это позволит пользователям получить безопасный доступ к вашим системам из любого места, не опасаясь злоумышленников.

#4. Изменить системные свойства

В случае если вы не можете обновить библиотеку Log4j до последней версии, необходимо немедленно изменить системные свойства java, если вы используете версию от Log4j 2.10 до Log4j 2.14.1.

Вы должны настроить его таким образом, чтобы предотвратить поиск, который злоумышленники используют для обнаружения уязвимостей и последующего поиска способов их использования.

#5. Удалите JNDI

Причина этой критической уязвимости безопасности кроется в ее дизайне. Плагин JNDI Lookup имеет недостаток в конструкции, через который злоумышленники могут осуществить атаку.

JNDI используется для выполнения кода на основе входных данных в его журнале, которыми любой может легко манипулировать, поскольку журнал принимает любой запрос без проверки.

Исследователи безопасности обнаружили, что этот плагин с момента своего выпуска в 2013 году всегда принимал непарсифицированные данные и отправлял их в библиотеку Log4j.

Таким образом, уязвимость Log4j может быть использована с помощью простой инъекции строки. Как только злоумышленник введет ее, логгер примет операцию, запрошенную в строке, и выполнит ее мгновенно без проверки.

Поэтому, если вы хотите защитить свои системы и приложения, вы должны отключить класс JndiLookup. Это не позволит регистратору предпринимать действия на основе данных журнала.

На самом деле, поиск JNDI уже отключен в Log4j 2.16.0 по умолчанию в попытке обезопасить ваши приложения и системы.

Поэтому, если вы используете версию Log4j ниже 2.16.0, убедитесь, что вы отключили JNDI Lookup.

#6. Поговорите с вашими поставщиками

Если у вас все в порядке, брандмауэры и системы безопасности обновлены, версия Log4j обновлена, JNDI Lookup отключен и т.д., не расслабляйтесь.

Даже если вы не используете уязвимую версию Log4j в своих приложениях, ее могут использовать ваши сторонние поставщики. Таким образом, вы никогда не узнаете, как ваше приложение или система были взломаны, потому что на самом деле проблема была в интеграции со сторонними поставщиками.

Поэтому поговорите со своими поставщиками и убедитесь, что они тоже обновили Log4j до последней версии и внедрили другие методы обеспечения безопасности, о которых говорилось выше.

#7. Используйте сканер уязвимостей Log4j

На рынке представлено множество инструментов для сканирования уязвимостей Log4j, которые облегчают обнаружение уязвимостей Log4j в ваших системах и приложениях.

Поэтому, когда вы ищете такие инструменты, проверьте их точность, поскольку многие из них генерируют ложные срабатывания. Кроме того, найдите инструмент, способный удовлетворить ваши потребности, поскольку он может быть ориентирован на выявление уязвимости Log4j, сообщение об обнаружении и устранение уязвимости.

Так, если ваша цель – обнаружение, найдите сканер уязвимостей Log4j, который может обнаружить проблему, или используйте тот, который может обнаружить и устранить проблему.

Заключение

Уязвимость Log4j является критической проблемой безопасности.

Поскольку эта библиотека протоколирования широко используется в различных приложениях и системах, уязвимость Log4j получила широкое распространение, позволяя злоумышленникам использовать широкий спектр систем и приложений.

Поэтому, если вы хотите защитить свои системы и приложения от этой уязвимости, убедитесь, что вы обновили библиотеку Log4j до последней версии и применили лучшие практики безопасности, рассмотренные выше.

В начале недели эксперт по кибербезопасности Alibaba Чен Жаожун обнаружил критическую уязвимость в Java-библиотеке Log4j, которая используется в сотнях тысяч приложений по всему миру. Уязвимость позволяет получить удаленный доступ к серверу, на котором хранится приложение, и запустить на нем произвольный код. Вместе с экспертами разбираемся, почему библиотека так популярна, в чем суть уязвимости и как ее можно устранить.

Что такое Log4j и почему она так популярна

Log4j — часть проекта Apache Logging Project. Это библиотека для логирования, которая помогает анализировать поток выполняющихся инструкций на продакшене или в тестовом окружении. С ее помощью можно пометить все вызовы текстовыми инструкциями — это сильно упрощает процесс локализации проблем.

Библиотеку используют сотни тысяч программ, игр, облачных серверов и корпоративных приложений, в том числе от Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla и Twitter. В целом пользователей Log4j можно описать как очень крупные компании, которые по тем или иным причинам не используют актуальные версии Java. Чаще всего это энтерпрайз-сегмент, где любое обновление языка, фреймворка или библиотеки — большая проблема.

В энтерпрайз-сегменте наиболее популярны приложения, разработанные на технологии JavaEE/JakartaEE, а также с использованием Spring. В экосистеме Spring особую популярность последнее время получил фреймворк Boot, в котором в качестве дефолтной библиотеки логирования используется LogBack. Для компаний, которые используют Spring Boot (если не брать в расчет кастомное подключение Log4j2), уязвимость не грозит.

В чем опасность

Уязвимость CVE-2021-44228 (или Log4Shell) относится к классу Remote Code Execution и присутствует только в версиях Log4j с 2.0-beta9 до 2.14.1.

Log4Shell для подключения к серверу использует JNDI (Java Naming and Directory Interface). Это API, которое предоставляет единообразный механизм взаимодействия Java-программы с различными службами имен и каталогов. Зная JNDI-имя LDAP-сервера, базы данных или месседж-брокера, можно получить доступ к ним, используя операцию lookup.

Еще одно уязвимое место касается безопасности строк. Часто бывает так, что переменные раскрываются не только в конфигурационном файле, важном звене взаимодействия с библиотекой логирования, но и в строках. В ситуации с небезопасными строками библиотека сканирует сообщения пользователей и если видит в них исходный код, исполняет его. После этого хакер может загрузить вредоносный код на сервер — исследователи из SecurityLab описывают случаи, когда Log4Shell использовали для майнинга криптовалют или для DDoS-атак.

Составьте свое первое резюме:
Вы можете бесплатно опубликовать свое резюме в нашем сервисе «Хекслет-CV» и получить советы по его улучшению от разработчиков и HR-менеджеров

Что делать с уязвимостью

Лучший совет, который можно дать в сложившейся ситуации — обновить  Log4j до версии 2.15 или Java до версии 11. Если обновление — это проблема, есть несколько альтернативных решений:

• Если приложение использует Log4j и запускается через команду java -d, можно выставить параметру system property значение true: java -Dlog4j2.formatMsgNoLookups=true.
• Еще один вариант — подтянуть текущую настройку из переменных окружения (LOG4J_FORMAT_MSG_NO_LOOKUPS=true). Во втором случае никакие дополнительные параметры выставлять не нужно, они автоматически подтянутся из окружения.

Несколько более сложных решений описаны здесь.

Выводы

Большинство уязвимостей возникают в старых версиях языков, библиотек и фреймворков, поэтому нужно стараться регулярно обновлять их. Для больших компаний это непозволительная роскошь, но безопасные и не подверженые уязвимостям приложения требуют регулярного повышения версий.

Кроме того, полезно периодически (раз в три-шесть месяцев) проводить аудит безопасности систем, которые эксплуатируются в продакшене. Не менее важно следовать рекомендациям, которые содержатся в отчетах службы безопасности. Это помогает выявлять общие проблемы и справляться со срочными изменениями (правда, с некоторыми ограничениями).

Никогда не останавливайтесь:
В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

Интернет-уязвимость Log4Shell недавно затронула миллионы машин. Log4j, малоизвестная, но почти вездесущая часть программного обеспечения, вызывает это.

Log4j используется для регистрации всех действий, происходящих за кулисами в различных компьютерных системах.

Он основан на библиотеке журналов с открытым исходным кодом, которая используется предприятиями и даже государственными организациями в большинстве приложений.

Поскольку это одна из самых серьезных дыр в кибербезопасности, когда-либо обнаруженных, крайне важно защитить ваши системы от этой уязвимости. Но как?

Давайте подробно рассмотрим уязвимость Log4j и все возможные решения для ее устранения.

Что такое Log4j?

Log4j — это с открытым исходным кодом фреймворк ведения журналов, который позволяет разработчикам программного обеспечения записывать различные данные в своих приложениях. Это компонент проекта Apache Logging Services, которым управляет Apache Software Foundation.

Сотни веб-сайтов и приложений используют Log4j для выполнения важных операций, таких как регистрация данных для отладки и других целей.

Когда вы вводите или нажимаете на плохую онлайн-ссылку и получаете уведомление об ошибке 404, это частый пример работы Log4j. Веб-сервер, на котором работает домен веб-ссылки, к которой вы пытались получить доступ, информирует вас о том, что такой веб-страницы не существует. Он также регистрирует событие в Log4j для системных администраторов сервера.

Во всех программах используются аналогичные диагностические сигналы. Например, в онлайн-игре Minecraft сервер использует Log4j для регистрации таких действий, как общий объем используемой оперативной памяти и инструкции пользователя, отправленные на консоль.

Как проявляется уязвимость?

Поиски — это новая функция, представленная в Log4j 2.0, которая помогает включать дополнительную информацию в записи журнала. Одним из таких поисков является поиск JNDI (Java Naming and Directory Interface), который представляет собой Java API для связи со службой каталогов.

Используя этот подход, внутренние идентификаторы пользователей могут быть сопоставлены с реальными именами пользователей. Этот запрос раскрывает недавно обнаруженную уязвимость RCE, поскольку одним из типов данных, предоставляемых сервером LDAP, является URI, указывающий на класс Java, который затем загружается в память и запускается экземпляром Log4j.

Из-за слабости проверки входных данных библиотеки Log4j можно внедрить произвольный сервер LDAP из ненадежного источника. Поскольку разработчики предполагают, что данные, отправляемые в журналы, будут обрабатываться как обычный текст, дополнительная проверка входных данных не проводится, и в журналы попадают опасные данные пользователя.

Оператор журнала может выглядеть так:

Злоумышленник теперь будет вставлять поиск JNDI, ссылающийся на мошеннический сервер LDAP, в параметре URL. Поиск JNDI будет выглядеть следующим образом:

Затем библиотека Log4j связывается с этим сервером LDAP по адресу Attacker.com, чтобы получить информацию о каталоге, включая значения для Java Factory и Java Codebase.

Эти два значения включают класс Java злоумышленника, который затем загружается в память и выполняется экземпляром Log4j, завершая выполнение кода.

Кто находится под угрозой?

Уязвимость Log4j невероятно широка и затрагивает бизнес-приложения, встроенные устройства и их подсистемы. Затронутые приложения включают Cisco Webex, Minecraft и FileZilla FTP.

Однако это далеко не весь список. Уязвимость затрагивает даже миссию вертолета Ingenuity Mars 2020, которая использует Apache Log4j для записи событий.

Сообщество безопасности составило список уязвимых систем. Важно отметить, что эти списки постоянно обновляются, поэтому, если какая-то программа или система не представлены, не думайте, что это не затронуто.

Воздействие этой уязвимости вполне вероятно, и даже если технический стек не применяет Java, руководители систем безопасности должны ожидать того же от критически важных систем поставщиков, поставщиков SaaS, провайдеров облачного хостинга и провайдеров веб-серверов.

Как проверить уязвимость Log4j?

Первый шаг – определить, имело ли место нападение. Вы можете сделать это, проверив системные журналы на наличие фрагментов полезной нагрузки RCE.

Если поиск по таким терминам, как «jndi», «ldap» или «$::», дает какие-либо журналы, исследователям безопасности следует продолжить исследование, чтобы выяснить, была ли это законная атака или просто снятие отпечатков пальцев.

Было обнаружено много нападений в дикой природе, которые не доставляли никаких вредных полезных нагрузок. Тем не менее, эксперты по безопасности провели их, чтобы определить, сколько приложений уязвимы для этой атаки.

Следующим шагом будет использование библиотеки Log4j для идентификации всех проектов. Если используются версии между 2.0-beta9 и 2.14.1, проект может быть уязвимым.

Учитывая сложность определения того, где существует эта уязвимость, может быть предпочтительнее предположить, что проект уязвим, и что обновление библиотеки — лучший способ устранения опасности выполнения кода.

Проект не уязвим, если используемая версия ниже 2.0-beta 9, хотя библиотеку Log4j все же следует обновить, поскольку версии в диапазоне 1.x устарели и больше не получают обновлений.

Независимо от того, обнаружен ли уязвимый проект, рекомендуется проверить его, чтобы увидеть, содержит ли какая-либо информация, зарегистрированная с помощью Log4j, информацию, которую пользователь может изменить. URL-адреса, параметры запроса, заголовки и файлы cookie являются примерами этих данных. Если один из них зарегистрирован, проект находится под угрозой.

Эти знания могут помочь вам глубже изучить системные журналы и определить, подвергалось ли уже ваше веб-приложение атаке.

Существуют бесплатные онлайн-инструменты, которые могут определить уязвимость веб-приложения. Одна из таких программ Охотница Log4Shell. Он с открытым исходным кодом и доступен на GitHub.

Если обнаружена уязвимая область кода в онлайн-приложении, полезная нагрузка, предоставленная раскрытым инструментом, может быть использована для ее внедрения в веб-приложение. Инструмент тестирования выявит соединения между вашим веб-приложением и их сервером LDAP, если уязвимость будет использована.

Решения для исправления уязвимости Log4j

Первым шагом является обновление Log4j, что вы можете сделать с помощью обычных менеджеров пакетов или загрузив его прямо с этого страница.

Также можно уменьшить вероятность использования уязвимости, установив для переменной среды FORMAT MSG NO LOOKUPS значение true. Однако эта контрмера применима только к версиям Log4j выше или равным 2.10.

Теперь рассмотрим альтернативные варианты.

1. Обходные пути для Log4j версии 2.17.0

Определенно настоятельно рекомендуется использовать Log4j версии 2.15.0 для защиты от Log4Shell, однако, если это невозможно, доступны другие решения.

Версии 2.7.0 и более поздние версии Log4j: Можно защититься от любой атаки, изменив формат регистрируемых событий, используя синтаксис процента m nolookups для данных, предоставленных пользователем. Это обновление требует редактирования файла конфигурации Log4j для создания новой версии программы. В результате перед развертыванием этой новой версии необходимо повторить этапы технической и функциональной проверки.

Log4j версии 2.10.0 и выше: Также можно защититься от любой атаки, установив для параметра конфигурации log4j2.formatMsgNoLookups значение true, например, при запуске виртуальной машины Java с параметром -Dlog4j2». formatMsgNoLookups = true, Другой вариант — удалить класс JndiLookup из аргумента пути к классам, что удалит основной вектор атаки (исследователи не исключают возможности другого вектора атаки).

Amazon Web Services предоставляет исправление, которое «следует использовать на свой страх и риск». Были опубликованы и другие «методы», такие как Logout4Shell, который «использует эту уязвимость против самого себя». Эксперт по безопасности сомневается в законности этого шага, который включает в себя «взлом машины, чтобы починить ее».

2. Проблема решена в Log4j v2.17.0.

Для версий выше 2.10: для Log4j2.formatMsgNoLookups должно быть установлено значение true.

Для версий с 2.0 по 2.10.0: выполните следующую команду, чтобы удалить класс LDAP из Log4j.

Для Log4j2.formatMsgNoLookups в настройках системы должно быть установлено значение true.

Смягчение в JVM

Смягчение с помощью параметров JVM больше не является вариантом. Другие методы смягчения продолжают быть успешными. Обновите Log4j до версии 2.17.0, если это возможно. Существует руководство по миграции для Log4j v1.

Если обновление невозможно, убедитесь, что для компонентов на стороне клиента и на стороне сервера установлено системное свойство -Dlog4j2.formatMsgNoLookups = true.

Обратите внимание, что Log4j v1 достиг конца жизни (EOL) и больше не будет получать исправления ошибок. Другие векторы RCE также восприимчивы к Log4j v1. Поэтому мы настоятельно рекомендуем вам как можно скорее обновиться до Log4j 2.17.0.

3. Меры по смягчению последствий

Текущие эксплойты не могут работать, даже если Log4j в некоторых случаях уязвим, например, если на хост-компьютере установлена ​​версия Java выше 6u212, 7u202, 8u192 или 11.0.2.

Это связано с улучшенной защитой удаленной загрузки классов Java Naming and Directory Interface (JNDI) в текущих версиях, которая необходима для работы атаки.

Кроме того, в версиях Log4j выше 2.10 этой проблемы можно избежать, установив для системного значения formatMsgNoLookups значение true, предоставив аргумент JVM -Dlog4j2.formatMsgNoLookups = true или удалив класс JndiLookup из пути к классам.

Тем временем, пока уязвимые экземпляры не будут исправлены, уязвимость можно устранить с помощью следующих методов:

• Установите для системного свойства log4j2.formatMsgNoLookups значение true для >= 2.10.
• Установите для параметра среды LOG4J FORMAT MSG NO LOOUPS значение true для >=2.10.
• Удалите JndiLookup.class из пути к классам для версий 2.0-beta9 и 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Одна из рекомендуемых передовых практик — ограничить исходящий трафик в Интернет только соответствующими портами.

Хотя большинство атак в этой области осуществляется через HTTP, уязвимость может быть использована через любой протокол, который регистрирует вводимые пользователем данные с помощью Log4j.

Тем не менее, обновление до log4j 2.17.0 — лучшее решение, потому что кто-то может обнаружить дополнительный подход к проблеме. Кроме того, многие издатели и производители объявили об улучшениях своих сервисов или приложений.

4. Исправление уязвимости Log4Shell

Log4j вездесущ, особенно сейчас, когда уязвимость эксплуатируется. Подводя итог, все, что вам нужно сделать, это включить следующие символы в журналы, проверенные Log4j.

И это загрузит и выполнит файл Java, расположенный в конце URL-адреса. Это так же просто, как и драматично.

Как вы знаете, очень важно обновить log4j до версии >= 2.17.0, чтобы устранить эту уязвимость Log4Shell (CVE-2021-44228).

Если это невозможно:

Для приложений, использующих библиотеку Log4j версии 2.10.0 и выше, также можно защититься от любых атак, установив для параметра конфигурации log4j2.formatMsgNoLookups значение true, например, при запуске виртуальной машины Java с параметром -Dlog4j2.formatMsgNoLookups = true вариант.

Другой вариант — удалить класс JndiLookup из аргумента classpath, что удалит основной вектор атаки (исследователи не исключают существования другого вектора атаки).

Внимание

Организации, которые не решаются или не хотят вносить изменения в уязвимые системы (или которые только хотят установить дополнительные меры безопасности), должны подумать о следующем:

• Убедитесь, что весь трафик направляется через iSensor/WAF/IPS. Это может помешать нападению получить доступ к системе.
• Ограничение объема трафика, который может достичь уязвимой системы. Если системе не требуется подключение к Интернету, ограничьте доступ только к необходимым и надежным IPS и диапазонам.
• Уменьшение авторизованного исходящего трафика хоста. Поскольку эта атака осуществляется путем подключения к мошенническому серверу, все лишние IP-адреса и порты должны быть заблокированы брандмауэром.
• Если служба больше не требуется, ее следует отключить до тех пор, пока не будет готово исправление.

Заключение

Недостатки Log4j потрясли наше сообщество и напомнили всем нам, насколько мы зависим от программного обеспечения с открытым исходным кодом.

Log4j уникален. Это не операционная система, не браузер и не программное обеспечение. Скорее это то, что программисты называют библиотекой, пакетом или модулем кода. Он просто служит одной цели, то есть ведет запись того, что происходит на сервере.

Люди, которые пишут код, предпочитают концентрироваться на том, что отличает их программное обеспечение. Они не заинтересованы в том, чтобы изобретать велосипед. В результате они полагаются на множество существующих библиотек кода, таких как Log4j.

Модуль Log4j является производным от Apache, наиболее широко используемого программного обеспечения веб-сервера. Вот почему его можно обнаружить на миллионах серверов. Следовательно, увеличение угроз безопасности.

Я надеюсь, что приведенные выше решения помогут вам защитить ваши устройства.

Оставайтесь с нами на HashDork для получения дополнительной полезной информации из мира технологий.

Since you’re using Log4j 1, the specific vulnerability is not present there. However, note the following from Comments on the log4shell(CVE-2021-44228) vulnerability:

Is log4j 1.x vulnerable?
Given that log4j version 1.x is still very widely deployed, perhaps 10 times more widely than log4j 2.x, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.

As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.

However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j’s configuration file, i.e. log4j.properties or log4j.xml.

An attacker who ALREADY has write access the log4j configuration file will need to add JMSAppender into the configuration poisoned with malicious connection parameters. Note that prior legitimate usage of JMSAppender is irrelevant to the ability of the attacker to mount a successful attack.

Also note that poisoning the configuration file is not enough. The attacker also needs to force log4j to reload its configuration file with the poisoned parameters. Given that log4j 1.x does not offer automatic reloading, the poisoned configuration file will typically only become effective at application restart.

Nevertheless, while not easy, such an attack is not impossible. Thus it makes some sense to make job of the attacker even harder by removing JMSAppender altogether from log4j-1.2.17.jar.

In the absence of a new log4j 1.x release, you can remove JMSAppender from the log4j-1.2.17.jar artifact yourself. Here is the command:

zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

If you do not have access to ‘zip’, you can also use the ‘jar’ command.

#assuming log4j-1.2.17.jar exists in current directory
mkdir tmp
cd tmp
jar xvf ../log4j-1.2.17.jar
rm org/apache/log4j/net/JMSAppender.class
jar cvf ../log4j-1.2.17-patched.jar .

It goes without saying that once log4j-1.2.17.jar is patched, you would need to deploy it.