CVE-2021-44228 (Log4Shell): prüfen und beheben

Zuletzt aktualisiert: 3. November 2026

Log4Shell ist eine Remote-Code-Execution-Lücke in Apache Log4j 2, der Logging-Bibliothek in einem großen Teil der Java-Anwendungen. Wenn eine Anwendung Text protokolliert, den ein Angreifer kontrolliert (eine URL, einen Header, ein Formularfeld), und der Text einen Lookup wie ${jndi:ldap://…} enthält, lädt Log4j Code vom Server des Angreifers und führt ihn aus.

Sie wurde wenige Stunden nach der Veröffentlichung im Dezember 2021 ausgenutzt, und bis heute wird jeden Tag danach gescannt. Die Bibliothek steckt in anderer Software, also besteht die Arbeit darin, jede Kopie auf dem Server zu finden und dann zu aktualisieren.

Auf einen Blick

CVE: CVE-2021-44228
Software: Apache Log4j 2 (log4j-core)
Betroffene Versionen: 2.0-beta9 bis 2.14.1, außer den Sicherheitsreleases 2.3.1 und 2.12.2 oder neuer
Behoben in: 2.15.0 (Java 8), 2.12.2 (Java 7), 2.3.1 (Java 6); aktualisiere auf 2.17.1, 2.12.4 oder 2.3.2 oder neuer
CVSS-Score: 10.0 Kritisch (NVD, CVSS 3.1) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CISA Known Exploited Vulnerabilities: Ja, aufgenommen am 10. Dezember 2021
Von der NVD veröffentlicht: 10. Dezember 2021
Virtueller Patch von InfraFence: vp-cve-2021-44228 (ModSecurity id 9920004)

Was betroffen ist

Betroffen ist nur log4j-core aus Log4j 2, und nur ab 2.0-beta9 bis zum Fix. Log4j 1.x ist von dieser CVE nicht betroffen, hat aber 2015 sein Lebensende erreicht und eigene Lücken. Java-Anwendungen auf Basis von Log4j 2 (Anwendungsserver, Suchmaschinen, eigene Apps) bringen die Bibliothek in ihren eigenen Ordnern mit, oft in einer .war oder einer Fat-.jar, nicht als Systempaket.

Der erste Fix, 2.15.0, war in manchen Konfigurationen unvollständig (CVE-2021-45046), und zwei weitere Probleme folgten (CVE-2021-45105 und CVE-2021-44832). Deshalb ist das Ziel heute 2.17.1 oder neuer auf Java 8, 2.12.4 auf Java 7 und 2.3.2 auf Java 6.

Prüfen, ob ein Server sie enthält

Suche nach log4j-core-Dateien und dann nach Archiven, die sie mitbringen. Die Version steht im Dateinamen:

Jede Linux-Distribution

sudo nice -n 19 ionice -c3 find / -xdev -type f -name 'log4j-core-*.jar' 2>/dev/null

Jede Linux-Distribution (braucht unzip)

sudo nice -n 19 ionice -c3 find / -xdev -type f \( -name '*.jar' -o -name '*.war' -o -name '*.ear' \) 2>/dev/null \
  | while read -r f; do
      unzip -l "$f" 2>/dev/null \
        | grep -qE 'log4j/core/lookup/JndiLookup\.class|log4j-core-[0-9][^/]*\.jar' && echo "$f"
    done

Hinweis: -xdev hält die Suche auf dem Root-Dateisystem. Führe sie für jeden weiteren Mountpunkt mit Anwendungen erneut aus (/opt, /srv), und prüfe Container-Images getrennt: Eine Datei in einem Image liegt nicht auf der Festplatte des Hosts.

Bei einer Anwendung, die du selbst baust, frag das Build-Tool, welche Version es wirklich einpackt:

Maven-Projekt

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

Um zu sehen, ob es jemand versucht hat, durchsuche die Access-Logs des Webservers nach Lookups (Angreifer setzen sie auch in Header, die diese Logs nicht aufzeichnen):

Apache-Access-Logs

sudo grep -rhiE '\$\{jndi|%24%7Bjndi|\$\{\$\{' --include='*access*' --exclude='*.gz' /var/log/apache2 /var/log/httpd 2>/dev/null | tail -20

Beheben

Software eines Herstellers: Installiere das Release des Herstellers, das Log4j 2.17.1 oder neuer mitbringt.
Deine eigene Anwendung: Hebe log4j-core (und log4j-api) auf 2.17.1 oder neuer an, oder auf 2.12.4 bei Java 7 und 2.3.2 bei Java 6, baue neu und deploye erneut. Prüfe mit dem Build-Tool, dass keine andere Abhängigkeit eine ältere Kopie zurückholt.
Starte die Anwendung neu: Eine laufende JVM behält die alten Klassen bis dahin.
Führe die Suche oben erneut aus: Es sollte kein altes log4j-core mehr übrig sein, auch nicht in Backups bereitgestellter Anwendungen, die erneut deployt werden könnten.

Maven: die behobene Version festlegen

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.17.1</version>
</dependency>

Achtung: log4j2.formatMsgNoLookups zu setzen oder Klassen von Hand zu entfernen waren Notlösungen vom Dezember 2021, und die erste deckt nicht jeden Fall ab. Betrachte sie als vorübergehend und aktualisiere.

Wie InfraFence sie blockiert, während du aktualisierst

Der virtuelle Patch für CVE-2021-44228 ist eine ModSecurity-Regel, die nach der URL-Dekodierung die URL, die Request-Header, die Cookies und ihre Namen sowie die Parameter und ihre Namen prüft. Die Regel blockiert eine Anfrage mit ${, auf das innerhalb weniger Zeichen jndi folgt oder einer der verschachtelten Lookups, mit denen man es versteckt (${lower:, ${upper:, ${env:, ${sys:, ${date:, ${::-).

Hinweis: Der Patch sieht nur HTTP-Anfragen, die auf diesem Server über Apache mit ModSecurity laufen. Eine Java-Anwendung, die über ihren eigenen Port erreicht wird, oder ein Payload, der auf einem anderen Weg ankommt (eine E-Mail, eine Message Queue), ist nicht abgedeckt: Das Update ist die Lösung.

Wie der Patch angewendet wird

Der Agent notiert, welche SSH-Ports und Websites antworten.
Er schreibt die Regel (ModSecurity-ID 9920004) zwischen seine eigenen Markierungen in seiner ModSecurity-Datei, führt apachectl configtest aus und lädt Apache sanft neu. Schlägt der Test fehl, wird die vorherige Datei zurückgespielt.
Er prüft, ob SSH und die Websites weiterhin antworten, und entfernt den Patch, wenn nicht.
Er prüft mit einer harmlosen lokalen Testanfrage, ob ModSecurity mit der Regel wirklich blockiert. Ein ModSecurity im Modus DetectionOnly protokolliert nur: Der Patch wird dann entfernt und als unwirksam gemeldet, nie als angewendet.

Jede Anfrage, die der Patch blockiert, wird mit CVE-2021-44228 gemeldet (Agent 1.0.37 oder neuer): Du siehst die Versuche in der Aktivität des Servers und auf der Seite Ausnutzung im Dashboard und weißt so, dass die Schwachstelle gegen dich ausprobiert wird.

Achtung: Ein virtueller Patch blockiert die bekannte Form des Angriffs bei den Anfragen, die auf diesem Server über Apache laufen. Er ersetzt das Update nicht: Installiere die behobene Version und entferne den Patch dann unter Aktivität mit Rückgängig, wenn du ihn nicht mehr brauchst.

Virtuelle Patches brauchen Apache mit ModSecurity, die Einstellung Änderungen an der Webserver-Konfiguration erlauben und kein Hosting-Panel oder Konfigurationsmanagement-Tool, das den Webserver verwaltet; sie gehören zum Plan Pro und zu AutoMode. Ein Mensch wendet sie aus der KI-Analyse an, oder AutoMode tut es. Siehe Virtuelle Patches.

Quellen

Die Fakten auf dieser Seite stammen aus diesen Quellen; prüfe sie auf Änderungen.

Kostenlos auf 1 Server testen

Starter ist für einen Server kostenlos, mit vollem Schutz und automatischen Sperren. Ohne Kreditkarte.

Installiere den Agenten als root, mit deinem Token anstelle von <TOKEN>:

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>

Das Token erstellst du im Dashboard unter Server › Server hinzufügen.

Kostenloses Konto erstellen Zur Dokumentation