Версия сайта для слабовидящих
В начале декабря 2021 года мир ИТ взволновала новость о критической уязвимости CVE-2021-44228 в библиотеке Apache Log4j. Разбираемся, что это такое и чем опасно для систем хранения и аналитики больших данных на Apache Hadoop, Kafka, Spark, Elasticsearch и Neo4j.
Критическая уязвимость в библиотеке Apache Log4j: чем опасна CVE-2021-44228
9 декабря была обнаружена и опубликована критическая уязвимость CVE-2021-44228 в библиотеке Apache Log4j. Опасность этой угрозы, называемой Log4Shell или LogJam, оценивается на 10 баллов по 10-бальной шкале в cybersecurity и представляет собой потенциальную возможность удаленного выполнения кода злоумышленником. Поскольку библиотека Apache Log4j широко распространена в Java-приложениях: она логирует данные о событиях и ошибках. Например, в веб-приложениях Log4j собирает сведения об устройствах и браузерах пользователей, а в десктопных программах и мобильных устройствах следит за активностью и подсчитывает время пользования.
Библиотека Log4j имеет механизм Lookup для выполнения запросов по окружению Java. Например, при указании в качестве ключа JNDI (Java Naming and Directory Interface), Lookup-механизм в Log4j будет использовать этот набор Java API, организованный в виде службы каталогов, который позволяет Java-клиентам открывать и просматривать данные и объекты по их именам. По умолчанию все запросы осуществляются с префиксом java:comp/env/, но есть возможность указания собственного префикса, если в ключе поставить символ двоеточия. Это и есть уязвимость: указав в качестве ключа jndi:ldap://, можно осуществить запрос на обозначенный LDAP-сервер. Аналогично можно задать другие протоколы взаимодействия: LDAPS, DNS, RMI.
Эта уязвимость позволяет злоумышленнику выполнить произвольный код и потенциально получить полный контроль над удаленной системой, что чревато нарушением работы приложения или утечкой конфиденциальных данных. Хакеру достаточно всего лишь отправить запрос через доступный механизм, что приведет к попытке записи строки в лог, где она будет обрабатываться библиотекой Log4j. Для этого подойдут самые обычные HTTP-запросы, отправляемые через поля веб-формы на сайте и прочие виды взаимодействий с логированием на стороне сервера.
Таким образом, если любая система использует уязвимую версию библиотеки Log4j с 2.0-beta9 и до 2.14.1 с поставляемым JNDI-модулем, то вероятность эксплуатации CVE-2021-44228 очень высока. Далее рассмотрим, как чем это опасно для Big Data систем на Apache Hadoop, Kafka, Spark, Elasticsearch и Neo4j, а также каким образом можно предотвратить данную угрозу.
Угроза Log4Shell для Apache Hadoop, Spark, Kafka и Neo4j
Elasticsearch не подвержен удаленному выполнению кода с уязвимостью CVE-2021-44228 из-за использования Java Security Manager. Elasticsearch на JDK8 или ниже подвержен утечке информации через DNS, что устраняется простым изменением свойств JVM. Разработчики Elasticsearch планируют в ближайшее время выпустить новую версию системы, которая содержит свойство JVM по умолчанию и удаляет потенциально уязвимые компоненты Log4j. В облачном решении Elastic тестирование безопасности не выявило возможности для удаленного выполнения злонамеренного кода. Но пользователям версий до 7.2 рекомендуется перезапустить развертывания, чтобы получить обновленные настройки. А вот другой популярный продукт ELK-стека, Kibana, оказался совершенно не подвержен угрозе Log4Shell.
Системы на Apache Kafka, использующие библиотеку Log4j версии 1.x, могут быть уязвимы для Log4Shell, только если конфигурации JMS (Java Message Service) TopicBindingName или TopicConnectionFactoryBindingName установлены так, что JNDI может обрабатывать заданные пользователем протоколы и порты. Иначе CVE-2021-44228 не грозит системам на базе Kafka, т.к. по умолчанию там используется 1-я версия библиотеки Log4j. Тем не менее, в версии 3.2.0, вышедшей в мае 2022 года, библиотеки log4j и slf4j-log4j12 заменены на reload4j и slf4j-reload4j, о чем мы рассказываем здесь.
Spark 2.4.2 уязвим для атаки Log4shell, если использует ее версию Log4j 2.x для логирования. По умолчанию применятся версия библиотеки 1.x. Можно настроить ее, чтобы обеспечить безопасность, добавив файл log4j.properties в каталог conf, скопировав существующий файл log4j.properties.template.
Hadoop 3.3.1 уязвим для атаки Log4shell, если использует ее версию 2.x. Вообще по умолчанию Hadoop использует версию 1.x, записывая сообщения в Log4j. Библиотека Log4j позволяет настроить пути к классам в файле log4j.properties, который определяет, что и где регистрируется. Для приложений корневым регистратором по умолчанию является «INFO, console»: он записывает все сообщения на уровне INFO и выше в stderr-консоли. Серверы регистрируются в «INFO, DRFA», который записывается в ежедневно обновляемый файл. Файлы логов называются $HADOOP_LOG_DIR/hadoop-$HADOOP_IDENT_STRING-<server>.log. Для разработчиков Hadoop бывает удобно получить дополнительное логирование от определенных классов. Например, при работе с TaskTracker, пригодится log4j.logger.org.apache.hadoop.mapred.TaskTracker=DEBUG в файле log4j.properties.
Уязвимыми для CVE-2021-44228 являются Apache Flink, Hive, HBase, Greenplum PXF и множество других платформ, включая облачные решения. На многие из них уже выпущены обновления и «заплатки», которые устраняют возможность угрозы. Самым популярным способом устранить угрозу стало обновление библиотеки Log4j до последней версии 2.16.0, в которой устранена уязвимость CVE-2021-44228. В частности, именно это рекомендуется сделать для Neo4j версии 4.2 и новее. А если обновление невозможно, пользователям этой графовой NoSQL-СУБД рекомендуется выполнить следующие шаги:
- отключить lookup-механизм в свойствах системы через конфигурацию dbms.jvm.additional = —Dlog4jformatMsgNoLookups = true
- внести изменения в конфигурацию, установив ведение логов в формате JSON
для Neo4j версии 4.2
unsupported.dbms.logs.format = JSON_FORMAT
dbms.logs.http.enabled = false
Для Neo4j версий 4.3 и 4.4:
dbms.logs.default_format = JSON
dbms.logs.http.enabled = false
Для чтения и применения изменений свойств конфигурации потребуется перезапуск, что может вызвать небольшой простой. Для кластерных сред изменение можно применить с помощью последовательного перезапуска отдельного узла за раз, чтобы сократить влияние на пользователей. О том, как визуализировать графы в Neo4j, включая анализ кибербезопасности, читайте в нашей новой статье. А о том, почему в т.ч. из-за Log4Shell разработчики NiFi решили под конец года выпустить новый релиз этого фреймворка, смотрите здесь.
Узнайте больше про администрирование и эксплуатацию Apache AirFlow для эффективной по организации ETL/ELT-процессов в аналитике больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Администрирование кластера Kafka
- Безопасность озера данных Hadoop на платформе CDP
- Основы Apache Spark для разработчиков
- Графовые алгоритмы. Бизнес-приложения
Источники
