¿Dónde están todas las infracciones de contenedores?

¿Cómo atacarán y utilizarán los actores de amenazas los contenedores? Esta es una pregunta en la que pienso constantemente. Llevo más de dos décadas trabajando en esta área y siento que debería tener una respuesta. Pero yo no.

En cambio, tengo muchas ideas diferentes, ninguna de las cuales puedo identificar como correcta. Parte de esta indecisión se debe a todo el tiempo que dediqué a aprender sobre seguridad en el mundo "heredado". Los contenedores realmente no tienen un análogo. Claro, las máquinas virtuales (VM) a menudo se combinan con contenedores, pero nunca pudieron escalar como los contenedores. También se utilizan para fines completamente diferentes a los contenedores. Me tomó un tiempo ajustar mi forma de pensar y comprender dónde encajan realmente los contenedores en la superficie de ataque.

Los ejemplos públicos de ataques contra entornos en contenedores son muy limitados. Las infracciones casi siempre están relacionadas con la criptominería, que son ataques graves, pero quien responde al incidente en mí las encuentra decepcionantes. Otro punto en común es que en su mayoría son el resultado de una mala configuración, ya sea en Kubernetes o en una cuenta en la nube. La combinación de motivos y tácticas no ha resultado muy inspiradora hasta ahora.

El viejo camino

Las vulnerabilidades de ejecución remota de código (RCE) han sido la principal preocupación en la seguridad informática durante mucho tiempo. Todavía lo son, pero ¿cómo se aplica esta forma de pensar a los contenedores? Es fácil pasar inmediatamente a RCE como la principal amenaza, pero no parece ser la forma correcta de abordar los contenedores. Por un lado, los contenedores suelen tener una vida muy corta: El 44% de los contenedores viven menos de cinco minutos – entonces un intruso tendría que ser rápido.

Este enfoque también supone que el contenedor está expuesto a Internet. Ciertamente, algunos contenedores están configurados de esta manera, pero a menudo son muy simples y utilizan tecnologías bien probadas, como NGINX. Puede que haya días cero para estas solicitudes, pero serían extremadamente valiosas y difíciles de conseguir. Mi experiencia me ha demostrado que muchos contenedores se utilizan internamente y no se conectan directamente a Internet. En ese caso, el escenario de la ICE se vuelve mucho más difícil. debería mencionar log4j, aunque este tipo de vulnerabilidades tienen el potencial de ser explotadas de forma remota incluso si el sistema vulnerable no está al límite.

El nuevo camino

Si RCE no es la mayor amenaza que enfrentan los contenedores, ¿cuál es entonces? ¿Están los contenedores incluso en el radar de los actores de amenazas? Sí, los contenedores y su infraestructura de soporte son demasiado importantes como para ignorarlos. El software de orquestación de contenedores ha permitido escalar las cargas de trabajo en contenedores a números inimaginables. La tendencia de uso también está aumentando, por lo que puede estar seguro de que serán un objetivo. Simplemente no se pueden considerar servidores a los que se accede a través de vulnerabilidades RCE.

En cambio, en realidad ocurre lo contrario. En lugar de atacar los contenedores desde afuera hacia adentro, es necesario atacarlos desde adentro hacia afuera. Esto es esencialmente lo que hacen los ataques a la cadena de suministro. La cadena de suministro es un vector de ataque extremadamente eficaz contra los contenedores cuando se empieza a comprender cómo se construyen. Un contenedor comienza con un archivo de definición, como Dockerfile, que define todo lo que habrá en el contenedor cuando se ejecute. Una vez construida, se convierte en una imagen, y esa imagen es lo que puede convertirse en una carga de trabajo innumerables veces. Si algo en ese archivo de definición se ve comprometido, entonces todas las cargas de trabajo que se ejecutan se ven comprometidas.

Los contenedores a menudo, pero no siempre, se crean específicamente con una aplicación que hace algo y sale. Estas aplicaciones pueden ser casi cualquier cosa; lo importante que hay que entender es cuánto se construye utilizando bibliotecas, ya sea de código cerrado o de código abierto, escritas por otras personas. GitHub tiene millones de proyectos y ese no es el único repositorio de código que existe. Como vimos con SolarWinds, el código cerrado también es vulnerable a ataques a la cadena de suministro.

Un ataque a la cadena de suministro es una excelente manera para que los actores de amenazas ingresen al entorno del contenedor de un objetivo. Incluso pueden dejar que la infraestructura del cliente escale su ataque por ellos si el compromiso pasa desapercibido. Este tipo de escenario ya se está desarrollando, como vimos con el Incumplimiento de Codecov. Pero es difícil de detectar por lo nuevo que es todo esto y por cómo nuestro pensamiento todavía está arraigado en los problemas del pasado.

Un camino a seguir

Como ocurre con la solución de la mayoría de los problemas, la visibilidad suele ser un buen punto de partida. Es difícil arreglar lo que no puedes ver. Para proteger sus contenedores, necesita tener visibilidad de los propios contenedores, así como de todo el proceso que los construye. La gestión de vulnerabilidades es un tipo de visibilidad que debe integrarse en el proceso de construcción. También incluiría otras herramientas de análisis estático, como las que también buscan secretos filtrados. Dado que en realidad no se puede predecir cómo se verá un ataque a la cadena de suministro, el monitoreo del tiempo de ejecución se vuelve crítico para que sepa exactamente qué están haciendo sus contenedores.