FlawOpen

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

● Apache Software Foundation · CVE-2021-44228 · December 2021 · CVSS 10.0 · Kritisch
Sicherheitsforschung · FlawOpen

Log4Shell (CVE-2021-44228): Ursache und Fix

CVE-2021-44228 ließ Logdaten Lookups in Log4j 2 und das Nachladen von Klassen über JNDI auslösen. Log4j aktualisieren, eingebettete Kopien suchen.[1], [2], [4]

💡 Einfache Erklärung (ELI5)

Ein Büro hat einen Angestellten, dessen einzige Aufgabe es ist, aufzuschreiben, was Besucher sagen. Jemand findet heraus: Sagt ein Besucher einen bestimmten Satz, hört der Angestellte auf zu schreiben, geht zu einer darin genannten Adresse, holt bei einem Fremden einen versiegelten Umschlag und befolgt die Anweisungen darin. Dabei sollte er nur mitschreiben.[1]

Kernkonzepte & Begriffe

Message-Lookups
Eine Log4j-2-Funktion, die ${...}-Ausdrücke in Logmeldungen beim Schreiben durch Werte ersetzte. Vor 2.15.0 galt das auch für Daten in der Meldung, nicht nur für das konfigurierte Muster.[1]
JNDI
Java Naming and Directory Interface, eine API zum Nachschlagen von Objekten in Verzeichnisdiensten wie LDAP. Ein JNDI-Lookup bei einem entfernten Server konnte eine Klasse liefern, die die JVM lud.[1]
Ausdrucks-Injection (CWE-917)
Nicht vertrauenswürdige Daten erreichen einen Ausdrucksauswerter, sodass als Daten gelieferter Text als Anweisung ausgeführt wird.[1]
Transitive Abhängigkeit
Eine Bibliothek, die Ihre Anwendung nur enthält, weil eine andere Bibliothek sie braucht. Viele Log4Shell-Expositionen stammten von Log4j-Kopien, die niemand erfasst hatte.[4]
Software-Stückliste (SBOM)
Eine maschinenlesbare Liste aller Komponenten und Versionen in einem Build, mit der sich „Wo läuft bei uns Log4j 2.14?“ schnell beantworten lässt.[4], [3]

Framework-Zuordnungen

Vorfall-Zeitstrahl

2021-11-24

Chen Zhaojun von Alibaba Cloud Security meldet die Lücke vertraulich an Apache.[1]

2021-12-09

Die Lücke wird öffentlich; Log4j 2.15.0 erscheint, und binnen Stunden beginnen Massenscans.[1], [4]

2021-12-17

Die CISA erlässt die Emergency Directive 22-02, die US-Bundesbehörden verpflichtet, Log4j aufzuspüren und abzusichern.[3]

2021-12-28

Log4j 2.17.1 behebt CVE-2021-44832, die letzte von drei Folge-CVEs nach 2.15.0 (neben CVE-2021-45046 und CVE-2021-45105).[1]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Angreifertext erreicht einen Log-Aufruf

Jeder Wert, den eine Anwendung loggt – etwa ein Benutzername, ein Header oder ein Suchbegriff –, kann einen vom Angreifer gewählten Lookup-Ausdruck enthalten.[1]

Schritt 2

Log4j wertet den Ausdruck aus

Verwundbare Versionen verarbeiten Lookups in geloggten Daten, sodass der Ausdruck aufgelöst statt als Text geschrieben wird.[1], [2]

Schritt 3

JNDI geht ins Netz

Ein JNDI-Lookup lässt den Server einen im Ausdruck genannten Verzeichnisdienst kontaktieren, oft auf der Infrastruktur des Angreifers.[1], [4]

Schritt 4

Fremdcode läuft

Das entfernte Verzeichnis kann der JVM eine zu ladende Klasse nennen, die dann mit den Rechten der Anwendung läuft. Wo ausgehende Verbindungen gesperrt waren, scheiterte dieser Schritt.[1], [2]

Quellcode: Verwundbar vs. Sicher

Illustrative Maven-Konfiguration. Der Import von log4j-bom sorgt dafür, dass alle Log4j-Module – auch von anderen Bibliotheken mitgebrachte Kopien – auf eine aktuelle Version aufgelöst werden. Die Enforcer-Regel lässt den Build scheitern, wenn noch irgendein log4j-core älter als 2.17.1 erreichbar ist, auch transitiv, damit eine neue Abhängigkeit den verwundbaren Code nicht still wieder einschleppt. Das Update ist die eigentliche Korrektur; ausgehendes LDAP und RMI auf Anwendungsservern zu sperren, war die Defense in Depth, die die Ausnutzung auch dort unterbrach, wo das Patchen hinterherhinkte.

VERWUNDBARE IMPLEMENTIERUNG
<!-- 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. -->
GEHÄRTETER SICHERHEITS-PATCH
<!-- 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>

Checkliste für Engineering & Systemsicherheit

Quellen