Este artículo es un resumen de la ponencia presentada por Geoffrey SAUVAGEOT-BERTLAND en Hack 2024[1], en la que se abordan las posibles vulnerabilidades relacionadas con el uso de un registro privado de Docker mal protegido.
Un registro privado de Docker permite a las empresas gestionar y almacenar sus imágenes de Docker de forma centralizada, a menudo por motivos de confidencialidad o personalización. Sin embargo, la falta de una seguridad adecuada, a menudo debida a una configuración predeterminada, puede exponer estos registros a ataques selectivos.
¿Por qué utilizar un registro privado de Docker?
Un registro privado de Docker ofrece un control total sobre la gestión de las imágenes de aplicaciones, especialmente en entornos de desarrollo, pruebas y producción. A diferencia del registro público Docker Hub, las imágenes alojadas de forma privada pueden incluir componentes confidenciales o configuraciones específicas. Esto también permite cumplir con los requisitos de conformidad en materia de seguridad y confidencialidad de los datos.
Sin embargo, una configuración incorrecta de estos registros puede exponer los sistemas sensibles a los ataques. Es fundamental comprender los riesgos y las técnicas de ataque para anticiparse a ellos y proteger adecuadamente estos entornos.
En este artículo se tratarán dos escenarios de ataque:
- El robo y la revisión de una imagen privada de Docker.
- La manipulación de una imagen para poner en peligro la cadena de suministro.
Robo y análisis de una imagen
Detección de un registro privado de Docker vulnerable
El primer paso para llevar a cabo un ataque es identificar un registro Docker privado vulnerable. Una herramienta sencilla y eficaz para esta tarea es Nmap, un escáner de red que se utiliza para detectar los servicios que se están ejecutando en un equipo de destino. Al iniciar un escaneo, es posible detectar un registro Docker en un servidor mal configurado:
nmap -p- -sV <ip_server>
- El argumento -p- permite escanear todos los puertos de un equipo.
- La opción -sV permite identificar las versiones de los servicios que se están ejecutando en los puertos abiertos. Esto facilita la identificación del puerto del registro de Docker.
Una vez localizado el registro, es posible aprovechar su configuración si se puede acceder a él sin necesidad de autenticación (acceso anónimo).
Recuperación de la imagen
Una primera medida posible podría ser realizar una consulta en la siguiente URL:
http://<ip_registre>:<port>/v2/_catalog
Esta sencilla comprobación permite obtener dos datos fundamentales:
- Acceso anónimo: Si el servidor devuelve un código HTTP 200, esto confirma que el registro está abierto y es accesible sin necesidad de autenticación. El atacante puede entonces proceder a la recuperación de las imágenes.
- Lista de imágenes: La respuesta incluye una lista de todas las imágenes alojadas, lo que ofrece una visión general de lo que se puede descargar y examinar.
Una vez obtenida esta lista, las imágenes se pueden descargar con un simple comando «docker pull»:
docker pull <image_name>
Revisión de la imagen
Una vez completada la descarga, la imagen se puede ejecutar en un contenedor para examinar su contenido. Para ello, hay que conectarse directamente a su shell mediante el siguiente comando:
docker run -it <image_docker> sh
Esto permite acceder a todos los componentes incluidos en la imagen, en particular al código fuente de las aplicaciones. Este código puede contener información confidencial como:
- Claves API.
- Fichas de acceso.
- Variables de entorno o archivos .env que contengan nombres de usuario y contraseñas.
Esta fase de la investigación puede resultar especialmente crítica, ya que ofrece la posibilidad de obtener información confidencial que luego puede utilizarse para atacar otros sistemas conectados a la aplicación.
Modificación de una imagen
Ampliación del ataque a través de la cadena de suministro
Las consecuencias de un ataque de suplantación de imagen pueden agravarse si se ataca directamente la cadena de suministro. La idea consiste en comprometer una imagen y, a continuación, volver a introducirla en el registro sin que nadie se dé cuenta. Esto puede hacerse, por ejemplo, añadiendo una puerta trasera a la imagen comprometida.
Una vez modificada, la imagen se vuelve a subir al repositorio con la misma etiqueta y la misma versión que la imagen original. Esto sustituye discretamente a la imagen legítima, sin activar ninguna alerta inmediata.
Las consecuencias de un ataque de este tipo pueden ser graves:
- Cualquier persona o sistema que descargue la imagen dañada puede verse afectado.
- Los entornos de producción pueden verse afectados, lo que genera vulnerabilidades en infraestructuras críticas.
Creación de la puerta trasera
Durante la presentación, se utilizó una imagen web como ejemplo. Se empleó la herramienta Weevely para generar una puerta trasera sencilla que se integrara en la imagen:
weevely generate 123456 backdoor.php
Este comando genera un archivo backdoor.php, que luego se puede utilizar para crear un webshell semiinteractivo. Se puede acceder a este webshell con la contraseña 123456, lo que proporciona al atacante un acceso remoto discreto.
Incorporación de la puerta trasera en la imagen
Para integrar la puerta trasera en la imagen, se necesita un archivo Dockerfile. Este contiene las instrucciones para modificar la imagen Docker original:
- FROM: Utilizar la imagen original como base.
- COPY: Copia el archivo backdoor.php en el directorio /var/www/html o en otra ubicación adecuada.
- RUN: Instalar la utilidad sudo para permitir la elevación de privilegios a través del webshell.
- RUN: Cambiar la contraseña del usuario www-data.
- RUN: Añadir el usuario www-data al grupo sudo.
Una vez realizadas las modificaciones, la imagen se puede compilar y enviar al registro utilizando el siguiente comando:
docker build -t <image_tag>:<version>
docker push <image_tag>:<version>
Si no se especifica ninguna versión, se utiliza la etiqueta «latest» por defecto.
Implementación automática y supervisión
En algunos entornos, se puede utilizar una aplicación de implementación automática, como Watchtower, para supervisar e implementar automáticamente las nuevas versiones de las imágenes. Esto supone un riesgo adicional, ya que las imágenes comprometidas pueden implementarse sin una verificación manual previa, lo que amplía el alcance del ataque.
En tal caso, la imagen modificada se pondrá en producción inmediatamente después de su implementación en el registro.
Explotación
Una vez que la imagen modificada se ha implementado en un equipo de destino, es posible aprovechar la puerta trasera accediendo al webshell mediante el siguiente comando:
weevely http://<ip_server>/backdoor.php 123456
Añadir el usuario www-data al grupo sudo permite elevar los privilegios, lo que ofrece un control total del contenedor para llevar a cabo otras acciones maliciosas.
Posibles soluciones
Para evitar este tipo de ataques, se pueden adoptar, por ejemplo, las siguientes medidas de seguridad:
Uso de políticas de imagen
Es fundamental establecer políticas de admisión estrictas para las imágenes de Docker en entornos de Kubernetes. Se pueden utilizar herramientas como Kyverno u OPA (Open Policy Agent) para definir reglas que impidan el despliegue de imágenes que no cumplan con los estándares de seguridad. Además, el uso de escáneres de vulnerabilidades como Trivy o Anchore permite analizar las imágenes antes de su implementación para garantizar que no contengan ninguna vulnerabilidad conocida que pueda comprometer los sistemas.
Uso de imágenes Docker mínimas
Para reducir la superficie de ataque, se recomienda dar prioridad a las imágenes Docker mínimas. El uso de imágenes ligeras, como Alpine, permite limitar los componentes superfluos y, por lo tanto, las vulnerabilidades. También es importante eliminar todos los paquetes y componentes que no sean imprescindibles de las imágenes, con el fin de reducir el número de dependencias vulnerables. Cuanto menos software innecesario contenga una imagen, menos riesgos de seguridad presenta.
Protección de los certificados TLS
La protección de las comunicaciones con el registro de Docker es fundamental. La implementación de una política de rotación periódica de certificados y claves de firma permite reducir el tiempo durante el cual un certificado o una clave comprometidos podrían ser objeto de abuso. El uso de un gestor de certificados como Let's Encrypt puede facilitar la automatización de la gestión y la renovación de los certificados TLS, reforzando así la seguridad de las infraestructuras.
Segmentación de red
Una segmentación de red eficaz es imprescindible para limitar la exposición de los registros de Docker. Se recomienda configurar cortafuegos y listas de control de acceso (ACL) para filtrar y restringir el acceso a los registros. Además, la separación de las redes de desarrollo, producción y gestión de los registros de Docker contribuye a reducir los movimientos laterales en caso de que se produzca una brecha de seguridad, al tiempo que protege los entornos críticos.
Firma de las imágenes de Docker
Para garantizar la integridad de las imágenes de Docker, se recomienda implementar un proceso de firma digital. La firma de las imágenes permite asegurarse de que no hayan sido modificadas o dañadas antes de su implementación. Herramientas como Docker Content Trust (DCT) o Notary son adecuadas para firmar y verificar las imágenes de Docker. Además, es importante configurar los pipelines de CI/CD de manera que solo acepten imágenes firmadas, garantizando así que solo se utilicen imágenes seguras y validadas en los entornos de producción.
Conclusión
En conclusión, esta presentación realizada por Geoffrey SAUVAGEOT-BERTLAND en Hack 2024 me ha demostrado hasta qué punto un registro de Docker mal protegido puede constituir una puerta de entrada para los ataques. Sin embargo, también me ha permitido ver que, al tomar medidas proactivas para proteger la infraestructura y adoptar prácticas de seguridad sólidas, podemos reducir considerablemente los riesgos asociados al uso de registros Docker privados.
[1] Puede ver la grabación de la conferencia en: https://youtu.be/f8t-z0M9C-k?si=UN4_nK12ZQ0JDIoD
