La cloud ha alterado el contexto en el que los defensores estaban acostumbrados a apoyarse para comprender la superficie de ataque. Los atacantes ya no se mueven a lo largo de un plano de red lineal, de un activo a otro donde la visibilidad se puede rastrear en una capa predecible de la pila de red. En la cloud, cada movimiento de un atacante debe entenderse en relación con la infraestructura de cloud en la que opera.
En este artículo pretendo aclarar los enfoques exclusivos necesarios para defender los sistemas cloud analizando la arquitectura en la que se basa la cloud, el modelo de amenazas resultante y, por último, cómo abusan los atacantes de estos sistemas.
En primer lugar, un breve repaso de la arquitectura on-prem clásica y los puntos de inflexión que los atacantes tratan de explotar. Frente a la pila tecnológica tradicional se encuentra la arquitectura de su proveedor de servicios cloud (CSP). Les guiaré a través de los fundamentos de la arquitectura cloud , el nuevo modelo de amenaza que surge y, en consecuencia, los pasos que dan los atacantes para infiltrarse en los recursos desplegados cloud . Para terminar, una vez que tengamos claro por qué la cloud es diferente, destacaré una forma cloud en la que los atacantes abusan del entorno junto con la forma en que los defensores deben pensar sobre la visibilidad en la cloud.
Modelo de amenaza de la pila tecnológica tradicional
Puede ser útil proporcionar una breve visión general de la arquitectura del centro de datos, incluso si la mayoría de los lectores están bien versados en una pila de tecnología tradicional. Dedicar tiempo a tocar el modelo de amenazas de las arquitecturas de centros de datos ayuda con el yuxtaposicionamiento que haremos más adelante contra un modelo de amenazas de cloud , pero también ayuda a recordarnos a nosotros mismos las suposiciones incorporadas que tenemos sobre cómo proteger los sistemas.
Examinar los vectores de compromiso inicial.
- La arquitectura clásica puede estar plagada de puertos de gestión expuestos donde los atacantes podrían obtener acceso directo a un servidor.
- También debemos modelar los riesgos asociados a las vulnerabilidades de la capa de aplicación y cómo podrían explotarse para acceder a la capa del sistema operativo.
- Otro par de puntos comunes de compromiso inicial en un sistema clásico incluyen los siempre relevantes ataques phishing , implantes enviados por correo electrónico y la explotación de vulnerabilidades de la capa de host.
Cada uno de estos vectores puede ser aprovechado por un atacante ya sea para ganar ese punto de apoyo inicial en un entorno o utilizado para progresar a través de un sistema en la búsqueda de un objetivo - a menudo para afectar a la confidencialidad de los datos.
Las técnicas de los atacantes vienen dictadas por las características de la pila tecnológica.
Esto podría parecer una observación obvia, que los atacantes vivirán del terreno y adaptarán sus metodologías a la pila tecnológica con la que se encuentren. A pesar de su simplicidad, esta verdad universal ayuda a explicar la divergencia de las técnicas utilizadas cuando las amenazas atacan sistemas locales frente a infraestructuras cloud .
Es probable que los sistemas locales que utilizan los adversarios estén instalados con sistemas operativos plenamente funcionales. Esa superficie de ataque podría aprovecharse para pasar de una estación de trabajo comprometida a un servidor enrutable en el centro de datos de la víctima.
Los servidores no funcionan a distancia, sino que están conectados entre sí a través de una red. Es a través de esta red que los atacantes pueden moverse de host en host.
En la arquitectura tradicional de los centros de datos es frecuente encontrar reglas de salida permisivas. Es en esta ruta de salida de la red donde los atacantes tratan de establecer la persistencia a través de túneles de comando y control y exfiltrar datos fuera de un perímetro de red de confianza.
Si te fijas, la progresión del ataque en las instalaciones documentado en el diagrama anterior está impulsado por la superficie disponible para un atacante. En la siguiente sección, cuando pasemos a hablar de la arquitectura cloud , observará que se mantienen las mismas reglas del juego: la pila tecnológica determina las tácticas y técnicas que emplean los atacantes para lograr sus objetivos.
La arquitectura Cloud y el nuevo modelo de amenazas
La cloud se basa en el concepto de infraestructura compartida, en la que se concede a los clientes acceso granular a determinadas capas de la pila de infraestructura para crear y mantener recursos. Un cliente de cloud tiene total autonomía para crear recursos IaaS, utilizar servicios PaaS, transferir datos y crear políticas IAM (Identity and Access Management) para gobernar el acceso, todo ello gracias a su permiso delegado a una porción de la infraestructura que mantienen los proveedores de servicios cloud .
El acceso a la funcionalidad se delegado y expuesto al cliente a través de una capa de API denominadas API del plano de control de Cloud .
Todas las interacciones del usuario final con un entorno de cloud se canalizan a través del plano de control de Cloud nube mediante miles de API disponibles públicamente. Las API del plano de control permiten a los clientes realizar tareas administrativas como la creación de nuevos entornos, el aprovisionamiento de usuarios, el mantenimiento de recursos y el acceso a datos almacenados en servicios PaaS gestionados.
La responsabilidad de la API del Plano de Control es:
- Autorice a las personas que llaman, asegúrese de que tienen los permisos correctos para realizar las acciones solicitadas.
- Reproducir la acción en el componente posterior. Una acción podría ser apagar y encender una máquina virtual, copiar un objeto de un cubo a otro o actualizar los permisos de un usuario.
¡La cloud es poderosa!
Al exponer toda la funcionalidad a través de un conjunto de API públicas bien conocidas, las empresas pueden encontrar una velocidad y una escala impactantes como nunca antes habían podido. Construir en la cloud es como echar gasolina a tus ciclos de desarrollo y es la razón por la que la gran migración a la cloud en todos los sectores está en marcha en serio a pesar del coste a menudo elevado de la migración y de los costes continuos de la infraestructura de cloud .
Ante este nuevo paradigma, ¿cómo debemos modelar las amenazas a las que se enfrentan los datos almacenados en cloud?
En este caso, me parece útil centrarme en el compromiso inicial, ya que es una gran lente para poner de relieve las similitudes y las diferencias entre los modelos de amenazas on-prem y cloud .
Un par de vectores de compromiso inicial en cloud nube deberían resultarte familiares.
- El compromiso inicial en la cloud puede ocurrir debido a puertos de gestión abiertos en los recursos IaaS. Todos estamos familiarizados con un puerto SSH o RDP abierto que atrae una atención no deseada. En la cloud, esos riesgos persisten.
- Además, las vulnerabilidades de la capa de aplicación siguen siendo totalmente relevantes. El código inseguro desplegado en aplicaciones web de cara al público, como mínimo, causa interrupciones en las operaciones de negocio y, en el peor de los casos, da a los atacantes un punto de apoyo en su DMZ.
Toda la experiencia que tenga en su entorno local en la prevención y detección de ataques iniciales a través de estos dos vectores le será útil en la cloud. Las reglas de prevención y detección pueden adoptar un sesgo ligeramente cloud, pero son fundamentalmente las mismas cuando se producen en un entorno de cloud .
Pero, ¿qué pasa con las API del plano de control? Se trata de puntos finales públicos en los que el cliente puede configurar la autorización. Esta superficie de ataque es completamente nueva, y es donde el atacante astuto aprovechará las comodidades de la cloud para promover sus objetivos.
Examinemos cómo podría ser la progresión de un ataque cuando un atacante aprovecha las API del plano de control en lugar de una superficie de ataque local (véase el diagrama):
- El compromiso inicial a través de phishing es una táctica popular de los adversarios porque a menudo funciona.
- El impacto de las credenciales recolectadas puede trasladarse a la cloud cuando las credenciales se utilizan para autenticar y autorizar la actividad en entornos de cloud .
- Es poco probable que las credenciales asociadas con el compromiso inicial proporcionen un camino directo para el adversario. Como resultado, se podría emplear una de las muchas técnicas de escalada de privilegios probadas en la cloud para obtener permisos adicionales.
- Las campañas a menudo buscan establecer alguna forma de persistencia. En el plano de control de cloud , esto tendrá un aspecto muy diferente al de la nube local. La persistencia en cloud nube a menudo se parece al backdooring de acceso a la cuenta a través de la manipulación de la política de IAM.
- Recorriendo la progresión de este ataque, nos encontramos ahora en un punto en el que se ha obtenido acceso al objetivo. En la cloud , esto significa simplemente obtener los permisos IAM adecuados para acceder a los datos alojados en cloud .
- Y por último, en este escenario, las acciones sobre los objetivos son la exfiltración de datos fuera del entorno. De nuevo, las API del plano de control de cloud se utilizan para transferir datos desde el entorno de la víctima a un entorno controlado por el atacante.
Toda esta secuencia de ataque, desde el compromiso inicial hasta el impacto, se orquestó a través de las API disponibles públicamente del proveedor de servicios cloud . En ningún momento entró en juego la capa de red o la capa de host. Ni siquiera hubo controles preventivos o sensores en la red.
Filtración de datos Cloud
Una característica clave de cualquier CSP es su red troncal. Qué es una red troncal?
- Se trata de la capa de servicio del proveedor de servicios cloud , utilizada para tareas operativas de fondo del CSP, la red de canal de retorno utilizada para comunicarse con la infraestructura multiarrendatario y mantener la disponibilidad.
- La red troncal también se refiere a la red utilizada por el CSP para transferir los datos del cliente, en lugar de transportar bytes por la web abierta.
Esta red troncal hace que muchos servicios gestionados, como los repositorios de almacenamiento cloud , puedan dirigirse automáticamente a todos los demás repositorios de almacenamiento del CSP.
Tácticamente hablando, si quieres mover datos de un bucket S3 a otro bucket S3, todo lo que se requiere son los permisos IAM para hacerlo. La ruta de red ya está creada a través de la red troncal del CSPCloud proveedor de serviciosCloud ).
Como consumidor de cloud , no es posible implementar ninguna restricción de red en torno a los datos que viven en el almacenamiento cloudnube1, y no tienes visibilidad de esta red por la que viajan.
Por ejemplo, no es posible ingerir ningún registro de la capa de red para capturar el tráfico entre dos buckets S3.
Esto hace que se den una serie de circunstancias atractivas para un atacante motivado para exfiltrar datos de un entorno de cloud .
Si obtienen los permisos de IAM adecuados, los datos se pueden mover de un bucket de la víctima a un bucket en una cuenta controlada por el atacante mediante el envío de solicitudes API de capa 7 al plano de control de cloud .
Para ejecutarlo, un atacante interactúa únicamente con las API del plano de control de cloud disponibles públicamente y aprovecha la red troncal del CSP, una ruta de red preconfigurada, no accesible para el cliente.
Visibilidad en el plano de control
Los datos que se mueven de un cubo a otro no dejan el tipo de rastro al que están acostumbrados la mayoría de los defensores.
- Registros de la capa de red, que podrían revelar los paquetes de datos que se mueven de su cubo a otro - estos no están disponibles para usted como consumidor de cloud .
- El movimiento de datos se produce a través de la red troncal, de la que los clientes de cloud no tienen visibilidad.
- ¿Y la visibilidad en la capa host?
- El almacenamiento Cloud, como los buckets de S3, los blobs de almacenamiento de Azure y similares, son servicios gestionados. El cliente no tiene acceso al nivel de host o de sistema operativo, como ocurre con el modelo de infraestructura como servicio. No se pueden desplegar agentes en los servicios gestionados.
Esto nos deja con el plano de control. Ninguna de las acciones realizadas por un atacante podría identificarse con los sensores tradicionales, pero los indicadores de la actividad sí aparecen en los registros escritos por el plano de control cloud .
Todas las acciones sobre los recursos y los datos cloud están autorizadas por las API proxy del plano de control de cloud y dan lugar a algún tipo de registro.
- Las acciones de sus desarrolladores cuando crean sus buckets se registran, la ingestión y lectura normal de datos se registra y da lugar a los eventos correspondientes.
- Por el contrario, cuando los malos aprovechan las API del plano de control de cloud , sus acciones se registran como el mismo evento.
Estos registros de eventos cuentan la historia de su entorno cloud , quién accedió a qué, desde dónde y con qué credenciales, pero no las intenciones del usuario. Determinar si una acción concreta tiene una intención maliciosa o benigna requiere pistas contextuales adicionales y, a menudo, una lente más amplia a través de la cual ver el entorno.
Conclusiones
Un par de conclusiones
- Los adversarios aprovecharán la arquitectura única de la cloud y los servicios cloud por la misma razón que los desarrolladores utilizan la cloud : ¡es rápida! ¡Es escalable! Y las API del plano de control de la cloud les ayudan a conseguir sus objetivos.
- El plano de control es donde podemos encontrar pruebas de actividad, maliciosa o no, en un entorno de cloud . La supervisión basada en la red y en el host no le proporcionará la visibilidad que necesita.
[1] Controles de servicio VPC (Virtual Private Cloud): Sólo Google Cloud ofrece funcionalidades para imponer perímetros alrededor de servicios gestionados, no vinculados a VPCs cloud