En el evento Rooted Warfare 2017 celebrado este mes de marzo en paralelo con la 8ª edición de RootedCON Madrid, he presentado un nuevo proyecto que he estado desarrollando en mis ratos libres llamado Dagda. Es un proyecto completamente Open Source de análisis estático de vulnerabilidades conocidas sobre imágenes Docker, que además, permite la monitorización de comportamientos anómalos dentro de contenedores docker en ejecución.

Figura 1: Dagda Docker Security Suite Parte 1 de 2

Este proyecto nació de mi curiosidad por aprender Docker y Python, y finalmente ha resultado ser un proyecto bastante ambicioso del que he tenido buen feedback por parte de la comunidad, lo que me anima a continuar con él. Así que con vistas a compartir el conocimiento aprendido durante el desarrollo del proyecto Dagda, en este artículo haré una recopilación de las lecciones aprendidas para el que no pudiera asistir al evento.

Figura 2: cr0hn hablando de Dagda en su ponencia de RootedCON 2017

Docker es un proyecto Open Source que permite la automatización del despliegue de aplicaciones dentro de contenedores software portables. Estos contenedores proporcionan a las aplicaciones un sistema de ficheros completo que contiene todo lo que necesitan para ejecutarse. Además, dicho contenedor es completamente independiente del host sobre el que se ejecute por lo que garantiza que siempre se ejecutará sin dependencias externas al propio contenedor.

Figura 3: Docket en un vistazo

Desde el nacimiento de Docker en marzo de 2013, cada vez son más las empresas que adoptan esta tecnología día a día para cubrir sus necesidades DevOps dentro de sus entornos de integración continua y proyectos de despliegues automatizados en Cloud.

Esto implica que si una empresa quiere verificar si una aplicación tiene vulnerabilidades conocidas o no antes de su puesta en producción, será necesario, además de revisar el código fuente de la aplicación, revisar tanto los paquetes instalados en la imagen base del contenedor como las dependencias de librerías que la aplicación requiera para su correcto funcionamiento.

Figura 4: Flujo habitual de integración continua con Docker

Estas dos últimas revisiones son una nueva necesidad creada por la filosofía de DevOps, ya que el descriptor Dockerfile que describe cómo se construirá y qué se instalará en el contenedor para que pueda funcionar la aplicación en él, al ejecutarse dentro de un entorno de integración continua, generará y publicará de manera automática en el Docker Registry corporativo, un contenedor docker que puede incluir software o dependencias de las aplicaciones que no estén aprobadas por el equipo de seguridad por presentar vulnerabilidades conocidas.

Aunque verificar el contenedor Docker al completo sería la mejor práctica de seguridad, en muchas ocasiones, los entornos de integración continua de las empresas no suelen contar con todas estas revisiones, ya sea por la imposibilidad de integrar las herramientas de análisis de vulnerabilidades en sus entornos de integración continua o por el elevado coste de las mismas.

Figura 5: Slide en la presentación de David Cole de Tenable Security en RootedCON 2017

Como comentó David Cole de Tenable Security en una de sus presentaciones, esta problemática de “ir limpiando y revisando todo lo que la filosofía DevOps va generando de manera automatizada, no es divertido” .

Estado del arte de herramientas de auditoría para Docker

En la actualidad existen decenas de herramientas relacionadas con el análisis de vulnerabilidades en aplicaciones, dependencias de librerías y contenedores Docker. Algunas son pequeñas utilidades Open Source muy focalizadas en una funcionalidad concreta y otras son grandes proyectos de pago.

Si se observan las utilidades más significativas dentro el campo de la búsqueda de información sobre vulnerabilidades conocidas y análisis de dependencias, ninguna de ellas es capaz de integrarse y funcionar de manera colaborativa con el resto, no pudiéndose aprovecharse de las virtudes de otras herramientas para mejorar su funcionamiento. Entre dichas utilidades podemos encontrar las siguientes:

• cve-search: es una herramienta Open Source focalizada en centralizar la base de conocimiento de vulnerabilidades en una base de datos local del usuario sobre la que poder ejecutar consultas. Esta herramienta se centra en recabar todos los CVE de distintas fuentes e incluye también información de Exploit-db.

Figura 6: cve-search en GitHub

Aunque la base de conocimiento de vulnerabilidades conocidas que agrupa es bastante extensa, tiene un API de consulta bastante rígida, lo cual puede que sea el motivo por el que el resto de las herramientas de análisis de vulnerabilidades no se aprovechen de dicha herramienta y prefieran gestionar su propia base de conocimiento de vulnerabilidades conocidas.

• OWASP Dependency-Check: es una herramienta Open Source enfocada en identificar las dependencias de un proyecto y comprobar si dichas dependencias tienen vulnerabilidades conocidas. Actualmente soporta Java y .NET y de manera experimental, Ruby, Node.js y Python. 

Figura 7: OWASP Dependency-Check

Para cumplir su función de comprobar si dichas dependencias tienen vulnerabilidades conocidas, gestiona su propia base de datos de CVE y no se aprovecha de herramientas como cve-search. Además, puede integrarse con facilidad en los entornos de integración continua al estar disponible para herramientas como Jenkins y Sonar.

• Retire.js: es una herramienta Open Source enfocada en identificar sólo las dependencias JavaScript de un proyecto y comprobar si dichas dependencias tienen vulnerabilidades conocidas. Al contrario que OWASP Dependency-Check, Retire.js gestiona su propia base de conocimiento ad-hoc de librerías JavaScript vulnerables y no puede integrarse con herramientas como Jenkins y Sonar.

Por otro lado, dentro del campo de análisis de vulnerabilidades en contenedores docker, podemos encontrar desde grandes proyectos de pago que realizan análisis estático de vulnerabilidades así como análisis runtime, a herramientas Open Source que dejan de lado el análisis de las dependencias o el runtime de un contenedor. Entre dichas herramientas y proyectos podemos encontrar como más significativos los siguientes:

• Docker Security Scanning: es un proyecto propiedad de la propia compañía Docker Inc. que será gratuito por un breve periodo de tiempo. Dicho proyecto se encarga de verificar que las imágenes Docker están libres de vulnerabilidades conocidas.

Figura 8: Docker Security  Scanning integrado en Docker Cloud

Para ello identifica todos los componentes software presentes en cada capa y compara el SHA de cada componente contra una base de datos de expedientes CVE propia, dejando de lado, el análisis de las dependencias de librerías de las aplicaciones incluidas en la propia imagen.

• Twistlock: es un proyecto propietario de Twistlock Inc. que proporciona una suite completa de seguridad sobre contenedores Docker. Permite el análisis estático de vulnerabilidades tanto de los componentes software de la propia imagen Docker como el análisis de dependencias de distintos frameworks de aplicaciones.

Figura 9: Twistlock Container Security

Además, entre otras funcionalidades, permite detectar anomalías en contenedores Docker en ejecución. La desventaja de este producto es su coste de licenciamiento al ser un producto de pago.

• OpenSCAP: es un proyecto Open Source basado en OpenScap que permite el análisis estático de vulnerabilidades de imágenes Docker y requiere la instalación de las herramientas de OpenScap y del motor de Docker (además de otros requisitos como wget), así como clonar su repositorio de GitHub u obtener el shellscript desde ahí.

El proceso de análisis de este proyecto, al igual que el del resto de proyectos y herramientas descritas hasta ahora, gestiona su propia base de datos de expedientes CVE para realizar el análisis estático de vulnerabilidades, estando limitado dicho análisis a las imágenes Docker basadas en sistemas operativos compatibles.

• Coreos/clair: es un proyecto Open Source centrado también en el análisis estático de vulnerabilidades de imágenes Docker que gestiona su propia base de datos de expedientes CVE y requiere de una base de datos Postgres DB para su funcionamiento.

Figura 10: Proyecto Clair

Tras el repaso a todos estos proyectos, en la segunda parte de este artículo nos centraremos en la solución Dagda propuesta en la pasada RootedCON Warfare 2017.

Autor: Elias Grande (@3grander)
Graduado en por el Master de Seguridad de la UEM