Cada vez es más común el desarrollo de aplicaciones basadas en arquitecturas basadas en microservicios. Una de las tendencias más populares es el uso de contenedores gestionados por el equipo de SecDevOps en plataformas Docker o  Kubernetes - también llamada en inglés "K8" -. Esta última plataforma, se trata de un sistema de código libre originalmente diseñado por Google para la automatización del despliegue, el ajuste de escala y el manejo de aplicaciones en contenedores.

Figura 1: Hacking Kubernetes: Auditoría de seguridad y Explotación de vulnerabilidades

Esta tendencia, que no presenta visos de abandonarnos en un futuro próximo, hace que las auditorias de seguridad para localizar las vulnerabilidades y la explotación de las mismas estén cambiando en este sentido y que el modelo tradicional de Ethical Hacking no cubra todos aspectos a tener en cuenta.

Figura 2: Libro de Docker:SecDevOps

Para gestionar la seguridad de los contenedores Docker, nuestros compañeros escribieron el libro de Docker: SecDevOps y varios artículos de seguridad en estas plataformas que tenéis en las referencias, pero hoy, en este artículo os mostraremos algunas herramientas y técnicas que hemos utilizado en algunas de nuestras auditorías de K8.

- Docker: SecDevOps. El nuevo libro de 0xWord

- Docker Distroless Images: Cómo crear imágenes sin shell, ni interfaz de comandos 

- Docker: Cómo crear un entorno de Ethical Hacking desde cero con Docker

- Docker de My WordPress in Paranoid Mode: The Making of

- SuperLatch Docker: Integrar Latch con Docker y Kubernetes en tus aplicaciones

Para ello, desarrollaremos en primer lugar la “Fase de descubrimiento de vulnerabilidades”, para continuar con las “Fases de explotación I y II", finalizando con las “Conclusiones” extraídas y las referencias utilizada durante todo el proceso.

Fase de descubrimiento de vulnerabilidades

Dentro de esta fase usamos una herramienta en Python (llamada Kube-hunter y desarrollada por AquaSecurity) que permite analizar las posibles vulnerabilidades de un Clúster de K8. En este caso, utilizamos el modo Network scanning para revisar internamente todos los nodos del clúster, aunque esta herramienta dispone de muchas más opciones como Active Hunting o Container/Pod Deployment.

Figura 3: Kube-Hunter Discover

Los clúster de K8 se montan sobre un conjunto de nodos o servidores en el que al menos uno de ellos tiene que tomar el rol de máster y el resto se definen como workers. Estos nodos tienen que tener visibilidad entre sí para poder comunicarse. Es importante saber que los principales puertos para la gestión de estos clúster son: 443 u 8080, 10250 y el 10255.

Figura 4: Resultados de Kube-Hunter

A continuación, explotamos varias vulnerabilidades de las identificadas por Kube-hunter (en distintas fases) para poner a prueba el clúster de K8 y de ahí llegar a comprometer uno de los nodos.

Fase de explotación I

Empezamos por explotar Anonymous Authentication para obtener la información de los PODS que estaban corriendo en el clúster e identificar qué POD estaba ejecutando el Docker que contiene la API del clúster de K8. Para ello, hicimos la siguiente llamada, la cual nos devolvió todos los PODs dentro de ese nodo.

Figura 5: Enumeración de PODs dentro de un nodo

En este punto, fue necesario estudiar los PODs uno a uno, probando en cada nodo hasta encontrar el que contenía la API del clúster de K8.

Figura 6: POD con la API del clúster de K8

Fase de explotación II

Una vez encontrado el POD que contenía la API, pasamos a explotar la vulnerabilidad de RCE (Remote Code Execution), lo que nos permitió obtener el TOKEN de administración del clúster.

Figura 7: Vulnerabilidad RCE (Remote Code Execution) descubierta

Con esta evidencia que obtenemos mediante una simple petición HTTP POST usando curl demostramos que es posible realizar esta ejecución remota de código a través del puerto 10250 sin credenciales de acceso.

Figura 8: Remote Code Execution mediante una petición curl

Con la ejecución remota sobre el POD y el Docker que se han localizado anteriormente (que estaban ejecutando el API Server), se realizó un listado de procesos para encontrar la ruta dónde se encontraban los TOKENS de acceso a esa API.

Figura 9: Información de los procesos dentro del Docker

Aquí a continuación se muestran todos los TOKENS obtenidos, incluido el del admin para el acceso a la API pública.

Figura 10: TOKEN del admin para el acceso a la API Pública

Con ese TOKEN obtenido se demuestra con la siguiente prueba usando una llamada HTTP GET con curl con el TOKEN obtenido que se pueden realizar peticiones desde la API expuesta y bien securizada de la red pública, tal y como se puede ver en la imagen siguiente de la Figura 11.

Figura 11: Comprobación de que el TOKEN admin funciona correctamente

También es posible aprovechar ese TOKEN admin para crear un POD malicioso con el objetivo de obtener información del propio nodo sobre el que está corriendo.

Figura 12:  POD malicioso creado

También con ese mismo TOKEN obtenido se puede generar un fichero de configuración para “kubectl” y realizar el despliegue del POD a través del archivo de ejemplo que se muestra a continuación en la imagen siguiente.

Figura 13: Archivo de configuración kubectl

Una vez creado, se abrirá una Shell sobre el Docker desplegado, lo que desplegará un mapeado en “/octopus” de la raíz “/” del nodo sobre el que se esté ejecutando (con permisos root).

Figura 14: Despliegue correcto

Y por lo tanto, ya se pueden realizar todas acciones que sean necesarias o útiles para la prueba de Ethical Hacking sobre el sistema auditado.

Figura 15: Acceso al fichero /etc/hosts del nodo

Conclusiones

En este post se ha visto cómo, en este nuevo modelo de desarrollo de aplicaciones basado en el uso de microservicios, hay que prestar especial atención a todos los componentes y realizar una correcta configuración, securización y bastionado de todas las capas, pues, aunque en este ejemplo la API del clúster principal sí se encontraba bien securizada, ha sido posible comprometer toda la infraestructura a través de una API secundaria interna que no se había tenido en cuenta.

Autores: Ricardo Sánchez Ruiz (@neorichi) Senior Security Pentester y Antonio Ramírez Oliva (@ramirezversion) Security Architecture & Security Pentester del Equipo Octopus de la unidad CDO de Telefónica.