Docker, ¿contenedores seguros?

viernes, 29 de junio de 2018

Desde la salida, hace 4 años, de los sistemas de contenedores, estos han ganado mucha popularidad y usabilidad en entornos empresariales y educativos, debido a las grandes virtudes que poseen en cuanto a las facilidades de despliegue y las opciones de seguridad obvias que trae, por ser aplicaciones puntuales las que se cargan en el sistema.

Sin embargo, en el blog no hemos hablado mucho de ello y sus características de seguridad, que en algunos casos, han generado una falsa sensación de que son sistemas sin ningún tipo de vulnerabilidad y que al desplegar las imágenes de los diferentes servicios que se requieren, estos van a estar completamente protegidos ante cualquier incidente. Los que trabajamos en seguridad de la información, sabemos que eso nunca será cierto.

En el 2017, Sagie Dulce durante la conferencia de Black Hat, hizo una ponencia llamada “Cómo abusar de la API Docker con contenedores fantasmas”, donde con una prueba de concepto (PoC) demostró como en los montajes de Docker sobre Windows era posible usar la API a través de las conexiones de TCP de un contenedor para crear o probar aplicaciones en los contenedores en ejecución.

Esta actuación permite a un atacante esconder o ejecutar malware en los contenedores que están operando, generando una persistencia en el equipo base que es muy difícil de detectar por los mecanismos de seguridad para PC, ya que son herramientas usadas para afectar el contenedor.

Esta vulnerabilidad ya fue corregida por Docker en sus actualizaciones para la versión community y para la versión Enterprise, pero a partir de esta investigación se han realizados varias pruebas de concepto para validar lo expuesto en los documentos oficiales de Docker sobre seguridad (Docker docs). Aquí una de las principales énfasis es que la seguridad del contenedor depende de la seguridad del anfitrión y de su kernel.

Estas debilidades expuestas en las investigaciones son intrínsecas de los contenedores, pero muy poco tenidas en cuenta al momento de desplegar sistemas en producción o incluso en la integración por parte de sistemas operativos anfitriones, como la reportada en el CVE 2018-8115. Esta aprovecha en la validación de parámetros de ingreso de una librería del sistema de Windows justo en el momento de cargar una imagen de Docker.

Debido a esto, es necesario que los administradores usen herramientas para validar algunos de los riesgos, que validen principalmente la relación entre el anfitrión y el contenedor, desde incluso antes de ejecutar una imagen. Como se ve a continuación, el solo demonio de Docker puede tener brechas, debido a la forma que el administrador lo haya configurado.

Respuesta de Docker sin contenedores imagen
Ilustración 1: Respuesta de Docker sin contenedores

Herramientas como Dockscan permiten validar esa relación entre el anfitrión y los contenedores, y como cada aplicación que se habilita, puede generar riesgos. En el caso de la ilustración 1, la herramienta evidencia la falta de límites de usuarios y con tráfico libre entre la red del anfitrión y la de los contenedores.

Cuando se ejecuta un contenedor y exponer algún servicio, surgen nuevas brechas que se deben tener en cuenta, como se puede apreciar en la ilustración 2, donde se ve la falta de controles de acceso en el contenedor que se marca como una vulnerabilidad de riesgo alto.

Detección de brechas con un contenedor en ejecución imagen
Ilustración 2. Detección de brechas con un contenedor en ejecución

Existen muchas herramientas Open Source y otras de pago, que permiten hacer validaciones sobre la configuración del demonio de Docker o sobre los servicios expuestos, tales como:

La integración de estas u otras herramientas dentro de los sistemas de DevOps empresariales basados en contenedores como Docker, incorporan una capa necesaria de seguridad para la implementación en producción de esta tecnología. Esta capa es cada vez más importante, generando nuevas herramientas y metodologías denominadas SecDevOps que buscan tener esquemas de seguridad para los servicios de producción.

Si tienes dudas o comentarios, puedes hacerlo en nuestra comunidad de ElevenPaths y compartirlo con el resto de usuarios. Let's hack!

Diego Espitia
Chies Security Ambassador at ElevenPaths (CSA)

No hay comentarios:

Publicar un comentario