Imágenes populares de Docker bajo la lupa de seguridad
Docker es una tecnología muy utilizada en desarrollo para desplegar aplicaciones autocontenidas rápidamente e independiente del sistema operativo que se esté utilizando. Es muy útil para los desarrolladores y administradores.
A los desarrolladores le proporciona agilidad a la hora de poder crear y testear arquitecturas tecnológicas complejas y su integración. Otro aspecto crucial en el éxito de Docker entre la comunidad de desarrolladores es la certeza que proporciona de que su código va a funcionar en cualquier otra máquina que tenga Docker, eliminando los clásicos problemas de despliegue en la máquina destino debido a diferentes configuraciones de entornos, dependencias, versiones de SW base, etc.
A los administradores les facilita la tarea de mantenimiento de máquinas virtuales y la asignación de recursos, ya que los contenedores Docker son mucho más ligeros. Simplemente se necesita una imagen para poder desplegar los contenedores que se necesiten. Pero… ¿Qué seguridad nos ofrecen estas imágenes?
Desde el centro de ciberseguridad TEGRA Cybersecurity Center en Galicia, hemos hecho una investigación sobre las imágenes Docker más populares.
Para ello hemos utilizado la plataforma DockerHub que es el repositorio oficial de imágenes gestionado por Docker, para que cualquier usuario descargue la imagen, en vez de construir él mismo una desde cero. Por ejemplo, ésta sería una imagen de la base de datos mysql.
Imágenes populares con más vulnerabilidades
Lo primero que hemos hecho ha sido recuperar un listado de las 100 imágenes más descargadas de DockerHub a día 8 de agosto de 2019.
Posteriormente hemos analizado cada imagen con Dagda, una herramienta que su creador, Elías Grande Rubio, define como: “Una suite de seguridad Docker que permite tanto el análisis estático de vulnerabilidades de los componentes software presentes en imágenes Docker como el análisis de dependencias de distintos frameworks de aplicaciones”[1]
A continuación, os mostramos las 10 en las que Dagda ha encontrado un mayor número de vulnerabilidades de las 100 imágenes Docker analizadas:
¿Tantas
vulnerabilidades entre las imágenes Docker
más populares? ¿Cómo es esto posible?
Funcionamiento de Docker
Si nos paramos a pensar en cómo funciona Docker, vemos que se construye por capas estáticas.
fuente: https://moisesvilar.github.io/post/docker-layers-2/
Por consiguiente, vemos que todas las vulnerabilidades de las capas anteriores están presentes en las imágenes que se construyen a partir de ellas.
Confiamos en que los creadores, el día que crearon la imagen, la actualizaron al máximo. Las imágenes, sin embargo, quedan ancladas al instante de tiempo en que se construyó y a medida que el tiempo pasa, se descubren bugs, vulnerabilidades y exploits nuevos.
Detalle de las vulnerabilidades encontradas
A continuación, ya sabiendo que las imágenes de Docker funcionan por capas y herencia (incluso de vulnerabilidades…), diseccionamos en profundidad las vulnerabilidades encontradas. Para ello obtuvimos los dockerfiles correspondientes a su construcción y vimos cómo se componen las imágenes analizadas. En la siguiente figura podemos ver el esquema de herencia de las imágenes con más vulnerabilidades detectadas:
Llama la atención que dentro de las 10 imágenes populares más vulnerables que hemos analizado la mayoría (6) heredan de centOS7. A continuación analizaremos con detalle esa casuística.
Análisis detallado de Imágenes basadas en CentOS
Desglosemos el origen de las vulnerabilidades de las imágenes basadas en centOS. A cada imagen le restamos las vulnerabilidades propias de centOS resultando la siguiente tabla:
Ahora resulta más evidente el origen de las vulnerabilidades, cuales son específicas de cada imagen y cuales vienen heredadas del sistema operativo.
Herramientas
Si usamos Docker en nuestro stack tecnológico es importante contar con herramientas que nos ayuden a evaluar la seguridad de las imágenes que utilizamos o construimos, ya sean con soluciones libres como Dagda, Anchore, Clair, Dockscan, etc, u otras de pago como Docker Trusted Registry o Twistlock.
Una opción a tener en cuenta en estas herramientas es la funcionalidad de monitorización de contenedores en tiempo real. Esta monitorización dinámica analiza todos los eventos que ocurren en el contenedor en ejecución, y si hay alguna actividad sospechosa lanza una alerta.
Pensemos que las imágenes Docker, normalmente, tienen una actividad muy específica para la que han sido construidas, por lo tanto, dentro de una imagen en ejecución, un administrador tratase de instalar software nuevo es un comportamiento anómalo. Por ejemplo, en un contenedor con un WordPress, resultaría muy raro que un administrador estuviera instalando software nuevo.
Para mostrar el funcionamiento, activamos la monitorizamos en tiempo real para una imagen base de ubuntu:18.04 e instalamos el paquete git. En la figura podemos observar como efectivamente la monitorización dinámica detecta este comportamiento y lanza los avisos correspondientes.
En definitiva, si trabajamos con Docker, el uso de herramientas de análisis de contenedores nos puede ayudar a tener un enfoque de seguridad dentro de nuestro ciclo de vida de desarrollo. Las herramientas nos mostrarán las vulnerabilidades existentes para poder analizar más exhaustivamente si de verdad se puede comprometer la imagen o no, tanto de forma estática como con una monitorización dinámica.
En todo caso, ahora que entendemos que la naturaleza inherente a la creación de imágenes Docker la hace más proclive a quedarse anclada en el tiempo, debemos evaluar el impacto de la presencia de dichas vulnerabilidades. Porque una cosa es que exista una vulnerabilidad, otra que un atacante la pueda explotar, y otra aún más complicada (esperamos) aún es que un atacante la pueda explotar remotamente.
Sin embargo, en el mundo Docker existen ejemplos de este tipo de vulnerabilidades siendo explotadas in-the-wild como el ataque a ElasticSearch dockerizado de 2014 usando la vulnerabilidad CVE-2014-3120, uno de los primeros ataques públicamente reconocidos a imágenes Docker. Otros ejemplos serían las conocidas vulnerabilidades de Heartbleed (CVE-2014-0160) que es a causa de una librería de OpenSSL, o Shellshock (CVE-2014-6271) asociado a la librería BASH de GNU. Estas librerías solían venir instaladas en muchas imágenes base, en este caso, aunque la aplicación desplegada fuese segura tendría una vulnerabilidad explotable remotamente al hacer uso de alguna de ellas.
¿Se deben utilizar estas imágenes? ¿El riego es mayor o menor?
Como toda herramienta, y software, se deben usar con cautela. Es posible que, en desarrollo, en integración continua o mientras se está probando una aplicación con una base de datos, las vulnerabilidades no afecten, siempre que únicamente queramos probar la funcionalidad y esos contenedores se destruirán al finalizar. Aun así, es necesario vigilar bien el entorno y practicar la defensa en profundidad. Las recomendaciones podrían ser:
- Para usarlas en producción se debería verificar que actualmente la aplicación no hace uso de las librerías vulnerables y que el exploit de la vulnerabilidad no afecta a la naturaleza propia de la aplicación para asegurar que las futuras actualizaciones de la aplicación no nos exponen.
- Se debe aplicar a Docker la misma recomendación que al usar cualquier software de terceros: solo debemos utilizar contenedores de fuentes confiables. Como ejemplo de los riesgos de no seguir esta recomendación podemos ver este artículo (en inglés) que describe el uso de Dockerhub con imágenes maliciosas usadas para cryptomining.
- Dentro de un ciclo de desarrollo en el que se tenga en cuenta la seguridad, gestionar las vulnerabilidades y versiones de todos los componentes del producto software es una tarea clave.
- Mínimo punto de exposición. Una ventaja de usar Docker es que se pueden construir imágenes con únicamente las librerías necesarias para funcionar, por ejemplo, se podría eliminar la shell para que ningún atacante pudiera realizar acciones, lo cual sería muy complicado en un servidor real. Estas imágenes reciben el nombre de distroless, y no contienen ninguna shell, administradores de paquetes ni ningún otro programa que se espera que contenga una distribución estándar, resultando en imágenes con menos vulnerabilidades y de menor tamaño.
Como hemos visto, con la aparición de tecnologías como Docker orientadas a facilitar los despliegues, empaquetando las dependencias completas de las aplicaciones, la frontera definida entre las responsabilidades de los desarrolladores y de los administradores de sistemas de una empresa se diluye. El resumen de sus “peligros” podría ser:
- Las imágenes Docker se construyen en base a capas estáticas y por su naturaleza estas quedan ancladas al instante de tiempo en que se construyeron por lo que las imágenes son más proclives a la desactualización sobre todo aquellas con un número de capas significativo.
- Las imágenes de Docker suelen ser creadas por desarrolladores y otros perfiles que, al no estar acostumbrados a labores de administración de sistemas, pueden no tener en cuenta las medidas de seguridad necesarias para la correcta actualización, configuración y mantenimiento de las mismas.
En resumen, es necesario disponer de procesos, herramientas y metodologías conjuntas entre ambos perfiles, que permitan que la nueva productividad ganada con Docker, no genere por otro lado un problema de seguridad o un descontrol de los riesgos a los que estamos expuestos en nuestros sistemas.
Autores
- Juan Elosua Tomé – Director por parte de ElevenPaths del centro I+D en Ciberseguridad TEGRA de Galicia.
- Borja Pintos Castro – Investigador de ciberseguridad del centro tecnológico Gradiant, partner de ElevenPaths en TEGRA.
TEGRA cybersecurity center se enmarca en la unidad mixta de investigación en ciberseguridad IRMAS (Information Rights Management Advanced Systems), que está cofinanciada por la Unión Europea, en el marco del Programa Operativo FEDER Galicia 2014-2020, para promover el desarrollo tecnológico, la innovación y una investigación de calidad.
[1] http://www.elladodelmal.com/2017/03/dagda-docker-security-suite-auditoria_13.html
