thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228: Шпаргалка по смягчению
Обновление - 28-Dec-2021
CVE-2021-44832: Apache Log4j2 уязвим к RCE через JDBC Appender, когда атакующий контролирует конфигурацию.
Исправлено в Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) и 2.3.2 (Java 6)
Обновление - 17-Dec-2021
За ночь Apache раскрыл, что версия Log4j 2.16 также уязвима к атаке типа «Отказ в обслуживании», последствием которой является полный крах приложения; серьёзность этой проблемы классифицирована как Высокая (7.5). Был выпущен CVE-2021-45105, и Apache опубликовал новую исправленную версию (2.17), до которой рекомендуется обновиться.
Предыстория:
В интернет-обсуждениях активно обсуждалась 0-day уязвимость (позволяющая удалённое выполнение кода) в популярной библиотеке логирования Log4J для Java. Эта конкретная уязвимость, отслеживаемая как CVE-2021-44228 с максимальным «критическим» показателем CVSS 10, находится в механизме поиска (lookup) Log4J в сочетании с JNDI (Java Naming and Directory Interface). Эта проблема широко распространена, потому что многие разработчики не знали, что Log4J опасен при использовании с нефильтрованным вводом.
Наиболее значимое последствие заключается в том, что атакующий может добиться попадания строки в логгер, которая при обработке Log4J выполняет произвольный код. Первые примеры использовали путь ${jndi:ldap}, который мог привести к загрузке произвольного кода с удалённого URL. Этот путь частично нейтрализуется использованием новых сред выполнения Java, которые по умолчанию блокируют загрузчик классов на основе URL. К сожалению, современной версии Java может быть недостаточно для предотвращения эксплуатации, поскольку само приложение может предоставлять классы, которые можно использовать для выполнения произвольного кода.
Архитектура JNDI:
Меры по смягчению для различных сред:
Обновление - 17-Dec-2021
Уязвимость безопасности CVE-2021-45105
Подробности:
Версии Apache Log4j2 с 2.0-alpha1 по 2.16.0 не защищали от неконтролируемой рекурсии из самоссылающихся lookup-запросов. Когда конфигурация логирования использует нестандартный
Pattern Layout с Context Lookup (например, $${ctx:loginId}), атакующие, контролирующие входные данные Thread Context Map (MDC), могут создать вредоносные входные данные, содержащие
рекурсивный lookup, что приводит к StackOverflowError, завершающему процесс. Это также известно как атака DOS (Denial of Service).
Смягчение:
Начиная с версии 2.17.0 (для Java 8), рекурсивно раскрываются только строки lookup в конфигурации; в любом другом
случае разрешается только lookup верхнего уровня, а вложенные lookup-запросы не разрешаются.
В предыдущих релизах эту проблему можно смягчить, убедившись, что ваша конфигурация логирования делает следующее:
В PatternLayout в конфигурации логирования замените Context Lookups вида ${ctx:loginId} или $${ctx:loginId} на паттерны Thread Context Map (%X, %mdc или %MDC).
В противном случае удалите из конфигурации ссылки на Context Lookups вида ${ctx:loginId} или $${ctx:loginId} там, где они поступают из источников, внешних по отношению к приложению, таких как HTTP-заголовки или пользовательский ввод.
Обновление - 13-Dec-2021
** Log4j(релиз 2.16.0 – 2021-12-13) имеет два улучшенных функционала:**
---------------!!Настоятельно рекомендуется обновиться до последней доступной версии, поскольку message lookups отключены по умолчанию.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
Отключение JNDI по умолчанию. Требуется установить log4j2.enableJndi в значение true, чтобы разрешить JNDI.
Полное удаление поддержки Message Lookups
Новое обновление:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern и Context Lookup Pattern уязвимы к атаке типа «отказ в обслуживании».
Смягчение:
Смягчение для Log4j 1.x: Log4j 1.x не затронут этой уязвимостью.
Смягчение для Log4j 2.x: Примените одну из приведённых ниже техник смягчения.
Пользователям Java 8 (или новее) следует обновиться до релиза 2.16.0. Пользователям, которым требуется Java 7, следует обновиться до релиза 2.12.2, когда он станет доступен (работа в процессе, ожидается в ближайшее время).
В противном случае удалите класс JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Обратите внимание, что этой уязвимостью затронут только JAR-файл log4j-core. Приложения, использующие только JAR-файл log4j-api без JAR-файла log4j-core, не затронуты этой уязвимостью.
------------------CVE-2021-44228-------------------
Смягчение
Смягчение для Log4j 1.x: Log4j 1.x не имеет Lookups, поэтому риск ниже. Приложения, использующие Log4j 1.x, уязвимы для этой атаки только при использовании JNDI в своей
конфигурации. Для этой уязвимости был оформлен отдельный CVE (CVE-2021-4104). Для смягчения: проверьте вашу конфигурацию логирования, чтобы убедиться, что в ней не настроен JMSAppender.
Конфигурации Log4j 1.x без JMSAppender не затронуты этой уязвимостью.
Смягчение для Log4j 2.x: Примените одну из приведённых ниже техник смягчения.
Пользователям Java 8 (или новее) следует обновиться до релиза 2.16.0.
Пользователям, которым требуется Java 7, следует обновиться до релиза 2.12.2, когда он станет доступен (работа в процессе, ожидается в ближайшее время).
В противном случае удалите класс JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Обратите внимание, что этой уязвимостью затронут только JAR-файл log4j-core. Приложения, использующие только JAR-файл log4j-api без JAR-файла log4j-core, не затронуты этой уязвимостью.
1. Apache Log4j:
В релизах >=2.10** и
Для релизов >=2.0-beta9 и <=2.10.0
2. Исправление в pom.xml:
3. Azure App Service (Windows и Linux):
4. Контейнеризированные приложения:
5. Azure Functions:
6. Hotpatch для Apache Log4j
7. Как Defender for Cloud находит машины, затронутые уязвимостями Log4j
8. Обнаружение в журналах Azure Sentinel и Azure WAF
9. Конфигурация Maven plug-in для запрета уязвимых версий log4j2 в будущих сборках
1. Apache Log4j:
CVE-2021-44228: функции JNDI в Apache Log4j2 не защищают от управляемых атакующим конечных точек LDAP и других связанных с JNDI конечных точек.
Затронутые версии: все версии log4j-core >=2.0-beta9 и <=2.14.1 Функции JNDI Apache Log4j <=2.14.1, используемые в конфигурации, сообщениях журнала и параметрах, не защищают от управляемых атакующим конечных точек LDAP и других связанных с JNDI конечных точек. Атакующий, который может контролировать сообщения журнала или их параметры, может выполнить произвольный код, загруженный с LDAP-серверов, когда включена подстановка message lookup. Начиная с log4j 2.15.0, это поведение отключено по умолчанию.