Skip to main content

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

Modelo de amenzas para Docker definido por la OWASPModelo de amenzas para Docker definido por la OWASP

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.

Modelo de amenazas simplificado y agrupadoModelo de amenazas simplificado y agrupado

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).