Hacking Kubernetes: Auditoría de seguridad y Explotación de vulnerabilidades
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.
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 hacking ético no cubra todos aspectos a tener en cuenta.
Para estudiar la seguridad de un entorno Docker, 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.
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.
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.
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.
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.
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.
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.
Aquí a continuación se muestran todos los TOKENS obtenidos, incluido el del adminpara 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.
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.
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.
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).
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.
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.
