Superficie de ataque en la nube

La superficie de ataque de la nube es el conjunto total de puntos por los que un atacante podría intentar acceder a un entorno en la nube o extraer datos de él. A diferencia de las redes locales, la superficie de la nube está definida principalmente por la configuración y la identidad, no por un perímetro físico.

• API y consolas de administración expuestas públicamente
• Gestión de identidades y accesos (IAM)
• Depósitos de almacenamiento, bases de datos y funciones sin servidor
• Exposición de red (grupos de seguridad, balanceadores de carga)

Un único ajuste mal configurado puede exponer una cuenta completa.

La mayoría de las pruebas de penetración en la nube se dirigen a uno de los tres proveedores principales. Cada uno tiene su propio modelo de identidad y terminología, pero los patrones de ataque son similares.

• AWS — usuarios y roles de IAM, S3, EC2, Lambda
• Azure — Entra ID (Azure AD), Blob Storage, máquinas virtuales, Functions
• GCP — cuentas de servicio de IAM, Cloud Storage, Compute Engine

Aprender uno en profundidad facilita el aprendizaje de los demás, porque los conceptos fundamentales (identidad, procesamiento, almacenamiento y red) se corresponden entre todos ellos.

Los proveedores de nube protegen la infraestructura; el cliente protege lo que coloca en ella. Este es el modelo de responsabilidad compartida, y casi todas las filtraciones en la nube se producen en el lado del cliente.

• Proveedor: centros de datos físicos, hipervisor y aplicación de parches de servicios administrados
• Cliente: políticas de IAM, datos, aplicación de parches del sistema operativo (IaaS) y configuración de red

Como pentester, debe centrarse en las responsabilidades del cliente, porque ahí se encuentran los errores explotables.

El primer trabajo en una evaluación de la nube consiste en averiguar quién es usted y qué puede hacer con las credenciales que tiene. La CLI de AWS muestra al instante la identidad del autor de la llamada.

Si una clave tiene permisos excesivos, esta única identidad puede desplazarse por toda la cuenta.

Los recursos en la nube pueden ser accesibles desde Internet público o únicamente desde el interior de una red virtual. La exposición mal configurada es uno de los hallazgos más comunes.

• Grupos de seguridad / NSG abiertos a 0.0.0.0/0
• Depósitos de almacenamiento configurados para lectura pública
• Bases de datos con endpoints públicos habilitados
• Puertos de administración (22, 3389, 5432) expuestos

Mapear qué recursos son públicos es la base del reconocimiento de la nube.

Incluso sin credenciales, los atacantes enumeran la huella en la nube de un objetivo. Los nombres predecibles y el DNS filtran una cantidad sorprendente de información.

Las herramientas fuerzan nombres de depósitos y almacenamientos basándose en el nombre de la empresa y en patrones habituales.

En cada cuenta de nube existen dos capas de ataque distintas:

• Plano de gestión o control — las API que crean, modifican y eliminan recursos (por ejemplo, iam:CreateUser, ec2:RunInstances)
• Plano de datos — el acceso a los datos dentro de los recursos (leer un objeto de S3 o consultar una base de datos)

Comprometer el plano de gestión suele significar el fin de la partida, porque el atacante puede concederse cualquier acceso al plano de datos que desee.

Las acciones en la nube se registran de forma centralizada. Como pentester, debe saber que estos registros existen porque los defensores los supervisan, y descubrir que están desactivados constituye en sí mismo un hallazgo.

• AWS CloudTrail — registra todas las llamadas a la API
• Azure Activity Log / Monitor
• GCP Cloud Audit Logs

Una cuenta cuyos registros están desactivados o no se supervisan constituye un hallazgo de alto riesgo incluso antes de realizar cualquier explotación.

La mayoría de las intrusiones en la nube comienzan a partir de uno de unos pocos puntos de apoyo:

• Claves de acceso filtradas en repositorios de Git, registros de CI o aplicaciones móviles
• Roles de IAM con permisos excesivos asociados a servidores comprometidos
• SSRF que alcanza el servicio de metadatos de la instancia
• Buckets de almacenamiento públicos que exponen secretos o copias de seguridad

Reconocer estos patrones le permite priorizar dónde buscar primero.

Un enfoque estructurado permite que una evaluación de la nube sea exhaustiva. Las herramientas automatizadas enumeran toda la cuenta una vez que dispone de credenciales.

Herramientas como ScoutSuite y Prowler auditan la configuración de los servicios y señalan los riesgos automáticamente.

Las pruebas en la nube deben mantenerse dentro de la autorización del trabajo. Los proveedores también tienen reglas de participación.

• Confirme las cuentas, suscripciones o proyectos exactos incluidos en el alcance
• Evite acciones que afecten a otros tenants o a infraestructura compartida
• No ejecute nunca pruebas similares a una denegación de servicio sin una aprobación escrita explícita

Las pruebas no autorizadas en la nube pueden infringir las condiciones del proveedor y la legislación local.

Según el modelo de responsabilidad compartida, ¿qué parte es responsable de las políticas de IAM y de la configuración de los datos?

Ha aprendido qué define la superficie de ataque de la nube y en qué se diferencia de las redes tradicionales.

• La superficie está determinada por la identidad y la configuración, no por un perímetro físico
• AWS, Azure y GCP comparten los mismos conceptos básicos: identidad, cómputo, almacenamiento y red
• El modelo de responsabilidad compartida asigna la configuración y los datos al cliente
• Distinga entre el plano de gestión y el plano de datos
• Confirme siempre el alcance y la autorización antes de realizar pruebas

A continuación, profundizaremos en las configuraciones incorrectas de IAM, el núcleo de los ataques en la nube.