1.3 Threat Modeling
La fundación (OWASP) incluye un modelo de amenazas específico para Docker que nos ayuda a visualizar en una sola imagen todo lo que tenemos que tener en cuenta
Imagen derivada de OWASP para adaptar el formato
Para hacerlo más sencillo y didáctico he decido hacer una clasificación alternativa al modelo de amenazas que plantea la fundación OWASP, tomándome la licencia de agrupar y reducir algunas casuísticas para facilitar la comprensión.
Escapar del contenedor
En un ataque contra contenedores, el primer paso es intentar hacerse con el control del contenedor y el siguiente paso será escalar permisos e intentar hacerse con el control de la máquina host.
Si realizamos una mala configuración del contenedor y permitimos el acceso root o permitimos la ejecución del contenedor con muchas capacidades/permisos podemos acabar comprometiendo la máquina host (capítulo 2.1.3)
Ataques de red
Los contenedores muy frecuentemente están abiertos al tráfico a través de uno o múltiples puertos. La configuración de redes es un tema complejo que requiere su tiempo (capítulo 2.2.4).
Si hacemos una configuración incorrecta de red podemos acabar en escenarios de todo tipo cuando ese contenedor se ve comprometido con acceso a la red:
- Contenedor que comparte red con el Host. Esto permite hacer ataques a la interfaces vía red de los orquestadores presentes en el host, así como otras aplicaciones que tengan puertos abiertos, etc... En casos muy extremos podríamos incluso sufrir una expansión del ataque a la red donde la propia máquina host está conectada.
- Contenedor que comparte red con otros contenedores (sin necesidad de ello). Esto brinda la posibilidad de expandir el ataque a otros contenedores vía red.
Diezmar recursos
Ya sea porque estemos sufriendo un ataque intencionado o porque nuestro contenedor tenga un error de diseño como un memory leak , podemos fácilmente drenar los recursos de la máquina host si no establecemos unos límites a nuestros contenedores (capítulo 2.2.5).
Hacer que la máquina host se vuelva inestable por falta de recursos es otra forma de sabotear una infraestructura. Si además esa máquina host se encarga de orquestar otros servicios, podemos en ocasiones generar verdaderos problemas con nuestros clientes.
Este tipo de problemas de recursos pueden tornarse rápidamente muy costosos en términos económicos si estamos usando infraestructuras escalables en la nube y no hacemos una configuración correcta de las mismas.
Romper la integridad
Hablaremos de poisoned images (imágenes envenenadas) cuando estas estén desactualizadas y existan vulnerabilidades conocidas que puedan ser comprometidas, así como a su contenido. También incluye el caso de dockerizar un proyecto y que este incluya vulnerabilidades en sus propias dependencias o las imágenes que nos descarguemos no sean las que esperamos, sufriendo así un ataque man in the middle (capítulo 2.3.3).
Información
Un ejemplo sencillo: Creamos una imagen de Docker que por un error de diseño en nuestro propio código permite inyecciones SQL y que se exploten para la ejecución de comandos a través de una reverse shell.
Exposición de secretos
Este riesgo está siempre presente, podemos accidentalmente exponer información sensible por un error en nuestra lógica de negocio en la aplicación o por contar con alguna vulnerabilidad conocida, como un servidor web que permita un ataque tipo path traversial
y acabe exponiendo nuestro fichero .env o similares (capítulo 2.2.3).
Pero también existen escenarios donde excedemos el nivel de información a la que accede un contenedor, por ejemplo dando acceso completo a un volumen del host cuando solo necesitaria una carpeta específica o garantizando acceso root al contendor con privilegios suficientes como para poder montar los volúmenes de la máquina anfitriona en el contenedor (capítulo 2.2.2).