FlawOpen

flawopen.com/Incidents/log4shell-jndi-injection-december-2021

● Apache Software Foundation · CVE-2021-44228 · December 2021 · CVSS 10.0 · Критический
Исследования · FlawOpen

Log4Shell (CVE-2021-44228): причина и исправление

CVE-2021-44228 позволяла данным в журнале запускать lookup Log4j 2 и загрузку классов через JNDI. Обновите Log4j и найдите встроенные копии.[1], [2], [4]

💡 Простыми словами (ELI5)

В офисе работает клерк, чья единственная обязанность — записывать, что говорят посетители. Кто-то обнаруживает: если посетитель произнесёт определённую фразу, клерк перестаёт писать, идёт по указанному в ней адресу, забирает у незнакомца запечатанный конверт и выполняет инструкции из него. А ведь клерк должен был только записывать.[1]

Ключевые понятия и термины

Lookup в сообщениях
Функция Log4j 2, заменявшая выражения ${...} в сообщениях журнала значениями в момент записи. До 2.15.0 это распространялось и на данные внутри сообщения, а не только на заданный шаблон.[1]
JNDI
Java Naming and Directory Interface — API для поиска объектов в службах каталогов вроде LDAP. JNDI-lookup к удалённому серверу мог вернуть класс, который JVM загружала.[1]
Внедрение выражений (CWE-917)
Недоверенные данные попадают в вычислитель выражений, и текст, переданный как данные, исполняется как инструкция.[1]
Транзитивная зависимость
Библиотека, попавшая в приложение только потому, что от неё зависит другая библиотека. Многие случаи уязвимости к Log4Shell происходили из копий Log4j, которых никто не учитывал.[4]
Спецификация ПО (SBOM)
Машиночитаемый перечень всех компонентов и версий в сборке, позволяющий быстро ответить на вопрос «где у нас работает Log4j 2.14?».[4], [3]

Связи со стандартами

Хронология инцидента

2021-11-24

Чэнь Чжаоцзюнь из Alibaba Cloud Security конфиденциально сообщает об уязвимости в Apache.[1]

2021-12-09

Уязвимость становится публичной; выходит Log4j 2.15.0, и за считаные часы начинается массовое сканирование.[1], [4]

2021-12-17

CISA издаёт Emergency Directive 22-02, обязывающую федеральные ведомства США найти и нейтрализовать Log4j.[3]

2021-12-28

Log4j 2.17.1 исправляет CVE-2021-44832 — последнюю из трёх CVE, выявленных после 2.15.0 (вместе с CVE-2021-45046 и CVE-2021-45105).[1]

Пошаговый сценарий атаки

Шаг 1

Текст злоумышленника попадает в вызов журнала

Любое значение, которое приложение пишет в журнал — имя пользователя, заголовок, поисковый запрос, — может содержать выбранное злоумышленником lookup-выражение.[1]

Шаг 2

Log4j вычисляет выражение

Уязвимые версии обрабатывают lookup внутри записываемых данных, поэтому выражение вычисляется, а не записывается как текст.[1], [2]

Шаг 3

JNDI выходит в сеть

JNDI-lookup заставляет сервер подключиться к указанной в выражении службе каталогов, часто на инфраструктуре злоумышленника.[1], [4]

Шаг 4

Выполняется удалённый код

Удалённый каталог может указать JVM класс для загрузки, который затем выполняется с правами приложения. Там, где исходящие соединения были закрыты, этот шаг не удавался.[1], [2]

Исходный код: Уязвимый vs Защищённый вариант

Иллюстративная конфигурация Maven. Импорт log4j-bom приводит все модули Log4j, включая копии, подтянутые другими библиотеками, к одной актуальной версии. Правило enforcer проваливает сборку, если хоть какой-то log4j-core старше 2.17.1 остаётся достижим, в том числе транзитивно, — так новая зависимость не вернёт уязвимый код незаметно. Настоящее исправление — обновление; блокировка исходящих LDAP и RMI с серверов приложений — эшелонированная защита, которая срывала эксплуатацию даже там, где с патчами опаздывали.

УЯЗВИМАЯ РЕАЛИЗАЦИЯ
<!-- pom.xml: a direct dependency pinned to a vulnerable release -->
<dependencies>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>
  </dependency>
</dependencies>
<!-- Nothing stops another library from pulling in an older log4j-core transitively. -->
БЕЗОПАСНЫЙ ИСПРАВЛЕННЫЙ ВАРИАНТ
<!-- pom.xml: one version for every Log4j module, and a build that fails on old ones -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-bom</artifactId>
      <version>2.24.3</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-enforcer-plugin</artifactId>
      <version>3.5.0</version>
      <executions>
        <execution>
          <id>ban-vulnerable-log4j</id>
          <goals><goal>enforce</goal></goals>
          <configuration>
            <rules>
              <bannedDependencies>
                <searchTransitive>true</searchTransitive>
                <excludes>
                  <exclude>org.apache.logging.log4j:log4j-core:[2.0-beta9,2.17.1)</exclude>
                </excludes>
              </bannedDependencies>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Чек-лист по защите системы для инженеров

Источники