Log4J-Mitigation-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

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

Обновление - 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:

jndiarch

Меры по смягчению для различных сред:

Обновление - 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

 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, это поведение отключено по умолчанию.

В релизах >=2.10**, это поведение можно смягчить, установив либо системное свойство log4j2.formatMsgNoLookups, либо переменную окружения LOG4J_FORMAT_MSG_NO_LOOKUPS в значение true. Для релизов >=2.7 и <=2.14.1 все паттерны PatternLayout можно изменить, указав конвертер сообщений как %m{nolookups} вместо просто %m.

Для релизов >=2.0-beta9 и <=2.10.0 смягчение заключается в удалении класса JndiLookup из classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

2.Исправление в pom.xml:

Обновите зависимость в pom.xml и замените её на последнюю доступную версию в секции dependencies: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

Ссылка: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3.Azure App Service (Windows и Linux):

По возможности клиентам следует обновить Log4j до версии v2.15.0 и повторно развернуть приложения. Это основная рекомендуемая мера. Если вы не можете повторно развернуть приложение, то в версиях Log4j 2.10 и новее можно смягчить это поведение, установив системное свойство «-Dlog4j2.formatMsgNoLookups=true». В App Service вы можете установить это свойство, создав параметр приложения с именем JAVA_OPTS и значением «-Dlog4j2.formatMsgNoLookups=true». Параметр приложения JAVA_OPTS передаётся вашему Java-приложению при его запуске. Если параметр JAVA_OPTS уже установлен, просто добавьте «-Dlog4j2.formatMsgNoLookups=true» к существующему значению. Если вы используете Log4J версии 2.9 или ниже, это смягчение через системное свойство не сработает, и вам следует обновиться до v2.15.0.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4.Контейнеризированные приложения

Для контейнеризированных приложений, если версия Log4j 2, которую вы используете, — 2.10.0 или новее, вы можете использовать переменную окружения или параметр командной строки Java для отключения небезопасного поведения подстановки. Вы можете добавить строку:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
Ссылка на Dockerfile: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
В ваш Dockerfile, либо вы можете добавить эквивалентный флаг «-Dlog4j.formatMsgNoLookups=true» к команде, которую запускаете в контейнере, например:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
Вы также можете настроить переменную окружения во время выполнения — это может быть проще; например, для Kubernetes вы можете добавить эти строки в свою конфигурацию.
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5.Azure Functions:

Настройка системного свойства будет зависеть от выбранного варианта хостинга: выделенный (dedicated), premium или consumption (бессерверный). Напоминаем: основная рекомендуемая мера — обновление Log4J до 2.15.0 и повторное развёртывание приложения. Если вы по какой-либо причине не можете этого сделать, вы можете применить системное свойство.

- Выделенные (Dedicated) и Premium Functions:

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

- Consumption Functions (бессерверные):

Linux: создайте параметр приложения с именем «languageWorkers__java__arguments» и значением «-Dlog4j2.formatMsgNoLookups=true». Windows: создайте параметр приложения с именем «languageWorkers:java:arguments» и значением «-Dlog4j2.formatMsgNoLookups=true». **Обратите внимание, что обновление параметра приложения приведёт к перезапуску ваших Web и Function приложений, что может повлиять на производительность холодного старта. Если вы используете Log4J версии 2.9 или ниже, это смягчение через системное свойство не сработает, и вам следует обновиться до v2.15.0.

6.Hotpatch для Apache Log4j

Как это работает? Этот инструмент внедряет Java-агент в работающий JVM-процесс. Агент пытается пропатчить метод lookup() всех загруженных экземпляров org.apache.logging.log4j.core.lookup.JndiLookup, чтобы безусловно возвращать строку «Patched JndiLookup::lookup()». Это предназначено для устранения уязвимости удалённого выполнения кода CVE-2021-44228 в Log4j без перезапуска Java-процесса.

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

GitHub: https://github.com/corretto/hotpatch-for-apache-log4j2

7.Как Defender for Cloud находит машины, затронутые уязвимостями Log4j

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

Инвентаризация программного обеспечения

Результаты оценки уязвимостей

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8.Обнаружение в журналах Azure Sentinel и WAF:

Охота на Azure WAF Log4j CVE-2021-44228

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Сопоставление Azure WAF для уязвимости Log4j (CVE-2021-44228)

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9.Конфигурация Maven plug-in для запрета уязвимых версий log4j2 в будущих сборках:

Конфигурация Maven plug-in для добавления в ваш родительский POM, чтобы избежать любых использований устаревших версий log4j2, некоторые из которых подвержены RCE CVE-2021-44228

(«Log4Shell»), CVE-2021-45046 и CVE-2021-45105).

Ссылка: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

Участие в разработке:

Будем рады получить вклад от сообщества. Рекомендации по внесению вклада:

-->Пожалуйста, создайте PR.

-->Пожалуйста, обязательно укажите ссылку на источник для дополнительного контекста

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

Ссылки:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay