Ver el código de «Pentest a entornos Cloud»


¿Qué es el pentest Cloud y por qué es diferente?


'''Definición:''' El Pentesting Cloud es el proceso de identificar y explotar vulnerabilidades de seguridad en infraestructuras y aplicaciones desplegadas en servicios de computación en la nube.

'''Diferencias clave con el pentesting tradicional:'''

* '''Modelo de Responsabilidad Compartida:''' Crucial para entender dónde residen las responsabilidades de seguridad. El proveedor (AWS, Azure, GCP) es responsable de la ''seguridad DE la nube'' (infraestructura subyacente, hardware, software, red que ejecuta los servicios en la nube), mientras que el cliente (tú/tu empresa) es responsable de la ''seguridad EN la nube'' (configuración de los servicios, datos, identidad y acceso, sistemas operativos invitados, código de aplicación).
* '''Naturaleza "Serverless" y Contenedores:''' Nuevos paradigmas de computación que introducen diferentes superficies de ataque y vectores de vulnerabilidad.
* '''APIs omnipresentes:''' Casi toda la interacción con los servicios en la nube se realiza a través de APIs, lo que las convierte en un punto clave para el pentesting.
* '''Volatilidad y Escalabilidad:''' Los recursos pueden crearse y destruirse rápidamente, lo que dificulta el seguimiento y la persistencia.
* '''Dependencia de la configuración:''' La mayoría de las vulnerabilidades en la nube provienen de configuraciones incorrectas o políticas de seguridad débiles.

=== Preparación del Entorno de Pentesting ===

==== Requisitos y Consideraciones Legales/Éticas ====

* '''Cuenta Cloud:''' Se recomienda una cuenta de prueba (ej. AWS Free Tier) ''dedicada únicamente para testing''. Es fundamental configurar alarmas de facturación para evitar costos inesperados.
* '''Autorización:¡CRÍTICO!''' Nunca realices pentesting en entornos que no te pertenecen o para los cuales no tienes una autorización escrita y explícita. La mayoría de los proveedores cloud tienen políticas de uso aceptable que deben revisarse.
* '''Alcance (Scope):''' Define claramente qué servicios y recursos están dentro del alcance del pentest para evitar daños colaterales.

Fases de un Pentest Cloud.

* '''Reconocimiento''': Identificar servicios expuestos, rangos de IP, dominios, usuarios, tecnologías usadas.
* '''Enumeración''': Obtener más detalles sobre los recursos identificados (Versiones, permisos, configuraciones).
* '''Explotación''': Aprovechar vulnerabilidades (configuraciones débiles de IAM, buckets s3 expuestos, credenciales filtradas, APIs inseguras).
* '''Post-Explotación''': Persistencia, escalada de privilegios, movimiento lateral.
* '''Reporting''': Documentar hallazgos y recomendaciones.

Es importante entender donde residen las responsabilidades de la seguridad. El proveedor (AWS, Azure, GCP) es responsable de la seguridad '''DE''' la nube (Infraestructura subyacente, Hardware, software, red que ejecuta los servicios en la nube), mientras que el cliente (nosotros) es responsable de la seguridad '''EN''' la nube (Configuración de los servicios, datos, identidad y acceso, etc.)

Casi toda la interaccion con los servicios en la nube se realiza a traves de APIs, lo que las convierte en un punto clave para el pentesting.

==== Fase de Reconocimiento y Recopilación de Información ====

* '''Objetivo:''' Identificar la superficie de ataque (recursos expuestos, dominios, rangos de IP, tecnologías, usuarios).
* '''Técnicas:'''
** '''OSINT (Open Source Intelligence):''' Búsqueda de información pública sobre la organización objetivo.
*** Registro de dominios (whois).
*** Subdominios (Sublist3r, Amass).
*** Información en redes sociales y sitios de empleados.
*** Búsqueda de credenciales expuestas en repositorios públicos (GitHub, Pastebin).
** '''Escaneo de IP y Puertos:''' Identificar hosts y servicios abiertos en rangos de IP asociados al objetivo.
*** nmap -sV -O <IP_range>
*** '''Cuidado:''' Realizar esto con IP de proveedores cloud puede ser riesgoso si no está en el scope autorizado. Es más seguro si la IP pertenece a un recurso específico y autorizado del cliente.
** '''Enumeración de S3 Buckets:''' Los buckets S3 mal configurados son una fuente común de fugas de datos.
*** Intentar acceder a URLs comunes: http://<bucket_name>.s3.amazonaws.com/ o <nowiki>http://s3.amazonaws.com/</nowiki><bucket_name>/
*** Herramientas como s3recon o scripts personalizados para adivinar nombres de buckets.
* '''Ejemplo Práctico (AWS):'''
** ''Simulación:'' Una empresa ha expuesto accidentalmente un subdominio que apunta a un S3 bucket.
** ''Acción:'' Usar amass enum -d target.com para encontrar el subdominio docs.target.com. Luego, intentar accederlo y ver si el S3 bucket es público.

==== Fase de Enumeración de Servicios y Recursos ====

* '''Objetivo:''' Obtener detalles internos sobre los servicios identificados, configuraciones y permisos.
* '''Herramientas clave:''' AWS CLI, Prowler, ScoutSuite, Pacu.
* '''Técnicas:'''
** '''Enumeración de IAM (Identity and Access Management):'''
*** '''Objetivo:''' Entender la estructura de usuarios, roles, grupos y las políticas de permisos adjuntas. Buscar privilegios excesivos.
*** '''AWS CLI:'''
**** aws iam list-users
**** aws iam list-roles
**** aws iam get-user-policy --user-name <username> --policy-name <policyname>
**** aws iam get-role-policy --role-name <rolename> --policy-name <policyname>
**** '''Pacu:''' Módulos de enumeración IAM (ej. iam__enum_roles, iam__enum_users).
*** '''Cloudsplaining:''' Para analizar políticas IAM y detectar riesgos de escalada.
** '''Enumeración de S3 Buckets (profunda):'''
*** '''Objetivo:''' Listar el contenido de buckets accesibles, verificar permisos de escritura.
*** '''AWS CLI:'''
**** aws s3 ls s3://<bucket-name> (si tienes permisos)
**** aws s3api get-bucket-acl --bucket <bucket-name> (ver ACLs)
**** aws s3api get-bucket-policy --bucket <bucket-name> (ver políticas de bucket)
*** '''Prowler/ScoutSuite:''' Informarán sobre buckets públicos o mal configurados.
** '''Enumeración de EC2 (Elastic Compute Cloud) y Red (VPC):'''
*** '''Objetivo:''' Identificar instancias EC2, sus Security Groups, Network ACLs, y la topología de red.
*** '''AWS CLI:'''
**** aws ec2 describe-instances (información de VMs)
**** aws ec2 describe-security-groups (reglas de firewall a nivel de instancia)
**** aws ec2 describe-network-acls (reglas de firewall a nivel de subred)
**** aws ec2 describe-vpcs
*** '''Prowler/ScoutSuite:''' Destacarán Security Groups con reglas muy permisivas (0.0.0.0/0).

'''Ejemplo Práctico (AWS):'''

* ''Simulación:'' Tenemos credenciales comprometidas (aunque sean de baja prioridad).
* ''Acción:''
*# aws sts get-caller-identity (para saber qué credenciales estamos usando).
*# aws iam list-attached-user-policies --user-name <nuestro_usuario> (ver políticas).
*# prowler -p <perfil_de_nuestras_credenciales> para un escaneo rápido de seguridad.
*# Identificar un S3 bucket con scoutsuite aws y luego intentar listarlo con aws s3 ls s3://<bucket-name>.

==== Fase de Identificación y Explotación de Vulnerabilidades ====

* '''Objetivo:''' Aprovechar las debilidades encontradas durante la enumeración.
* '''Tipos de Vulnerabilidades Comunes:'''
** '''Gestión de Identidad y Acceso (IAM)'''
*** '''Descripción:''' Permisos excesivos, políticas mal configuradas, claves de acceso expuestas, uso indebido de roles.
*** '''Caso Práctico: Escalada de Privilegios vía Políticas IAM.'''
**** ''Escenario:'' Un usuario IAM tiene un permiso limitado, pero una de sus políticas permite iam:AttachUserPolicy o iam:PassRole a un rol privilegiado.
**** ''Explotación:''
****# Identificar la política con cloudsplaining o revisión manual de las políticas.
****# Si puedes adjuntar políticas, adjúntate una política de AdministratorAccess (temporalmente y solo en labs).
****# Si puedes PassRole, asume un rol con más privilegios.

'''Almacenamiento (S3)'''

* '''Descripción:''' Buckets públicamente accesibles (lectura/escritura), políticas de bucket inseguras, ACLs laxas, falta de cifrado.
* '''Caso Práctico: Acceso a datos sensibles en un S3 Bucket mal configurado.'''
** ''Escenario:'' Un S3 bucket tiene PublicRead habilitado, exponiendo datos confidenciales.
** ''Explotación:''
**# Descubrir el bucket (reconocimiento).
**# Intentar acceder a los objetos: aws s3 ls s3://<nombre-de-bucket-publico> o vía navegador.
**# Descargar archivos sensibles: aws s3 cp s3://<nombre-de-bucket-publico>/secret_file.txt .
** ''Defensa:'' Bloquear el acceso público, usar políticas de bucket y ACLs mínimas.

'''Redes y Cómputo (EC2, VPC)'''

* '''Descripción:''' Security Groups o Network ACLs demasiado permisivos (ej. 0.0.0.0/0 en puertos críticos), instancias con credenciales incrustadas, vulnerabilidades en aplicaciones ejecutándose en EC2.
* '''Caso Práctico: Explotación de Security Group permisivo en EC2.'''
** ''Escenario:'' Una instancia EC2 con un Security Group que permite SSH (puerto 22) desde cualquier IP (0.0.0.0/0).
** ''Explotación:''
**# Identificar la IP pública de la instancia y el puerto abierto (nmap -p 22 <IP_instancia>).
**# Intentar ataques de fuerza bruta contra SSH si las claves no son fuertes.
**# Buscar claves SSH expuestas en repositorios públicos.
**# Una vez dentro, buscar credenciales AWS en el archivo ~/.aws/credentials o credenciales de rol en <nowiki>http://169.254.169.254/latest/meta-data/iam/security-credentials/</nowiki><nombre-del-rol>/ (Metadata Service).

'''Serverless (AWS Lambda)'''

* '''Descripción:''' Funciones con permisos excesivos, credenciales incrustadas, inyección de código, vulnerabilidades en las dependencias.
* '''Caso Práctico: Escalada de Privilegios vía Función Lambda con Permisos Excesivos.'''
** ''Escenario:'' Una función Lambda es vulnerable a inyección de comandos o tiene permisos iam:PutUserPolicy o iam:CreateUser.
** ''Explotación:''
**# Identificar el rol de ejecución de la Lambda y sus permisos.
**# Si puedes inyectar comandos, usarlos para interactuar con la AWS CLI usando los permisos del rol de la Lambda.
**# Si la Lambda tiene permisos para crear usuarios/roles o modificar políticas IAM, úsalos para crearte un usuario con acceso total.

'''Bases de Datos (RDS)'''

* '''Descripción:''' Bases de datos expuestas a internet, credenciales débiles o por defecto, falta de cifrado, snapshots públicos.
* ''Simulación de Escenario:'' Un RDS (MySQL) está accesible desde internet.
* ''Explotación:''
** nmap -p 3306 <IP_RDS> (si está expuesto)
** Intentar adivinar credenciales comunes o de fuerza bruta.
** Buscar snapshots públicos de RDS que puedan contener datos sensibles.
** aws rds describe-db-snapshots --public-only

==== Fase de Post-Explotación y Persistencia ====

* '''Objetivo:''' Mantener el acceso, escalar privilegios, moverse lateralmente dentro del entorno cloud, y exfiltrar datos.
* '''Técnicas:'''
** '''Creación de Backdoors IAM:''' Crear usuarios IAM con claves de acceso persistentes o roles IAM para mantener el acceso.
** '''Modificación de Security Groups/NACLs:''' Abrir puertos para accesos futuros.
** '''Exfiltración de Datos:''' Copiar datos sensibles a un bucket S3 controlado por el atacante, a una máquina externa, etc.
** '''Movimiento Lateral:''' Asumir roles en otras cuentas conectadas (ej. mediante AWS Organizations), explotar servicios con confianza de rol.

==== Fase de Limpieza y Reporte ====

* '''Limpieza (en tu lab):'''
** '''¡Fundamental en un entorno real!''' Deshacer todos los cambios realizados, eliminar usuarios/roles creados, cerrar puertos, limpiar logs.
** En tu laboratorio, si usas CloudGoat o SadCloud, tienen scripts para destruir los entornos y limpiarlos.
* '''Reporte de Hallazgos:'''
** Documenta todas las vulnerabilidades encontradas, su impacto y las pruebas de concepto.
** Ofrece recomendaciones claras y accionables para la remediación, siguiendo las mejores prácticas de seguridad de cada proveedor.
** Incluye logs de CloudTrail o CloudWatch si se pudieron capturar las actividades del pentester.

=== Consideraciones Específicas para Azure y Google Cloud ===
Mientras que los conceptos de pentesting son similares, las terminologías, servicios y herramientas difieren.

==== Microsoft Azure ====

* '''Servicios Equivalentes:'''
** '''Identidad y Acceso:''' Azure Active Directory (Azure AD).
** '''Máquinas Virtuales:''' Azure Virtual Machines.
** '''Almacenamiento:''' Azure Blob Storage, Azure Files.
** '''Redes:''' Azure Virtual Network (VNet), Network Security Groups (NSG).
** '''Serverless:''' Azure Functions.
** '''Bases de Datos:''' Azure SQL Database, Azure Cosmos DB.
* '''Herramientas de Seguridad Nativas:'''
** Azure Security Center / Microsoft Defender for Cloud.
** Azure Sentinel (SIEM).
** Azure Key Vault.
** Azure Firewall, Azure WAF.
* '''Herramientas de Pentesting:'''
** '''Azure CLI:''' Para interactuar con los servicios.
** '''ScoutSuite:''' Soporte para Azure.
** '''AadInternals:''' Herramienta para enumerar y explotar Azure AD.
** '''Microburst:''' Colección de scripts de PowerShell para Azure.
** '''NetSPI K-Pack / Az-Pack:''' Herramientas para enumeración y post-explotación.
* '''Vulnerabilidades Comunes:''' Configuraciones de RBAC (Role-Based Access Control) débiles en Azure AD, Storage Accounts públicas, NSGs permisivos.

==== Google Cloud Platform (GCP) ====

* '''Servicios Equivalentes:'''
** '''Identidad y Acceso:''' Cloud IAM.
** '''Máquinas Virtuales:''' Compute Engine.
** '''Almacenamiento:''' Cloud Storage.
** '''Redes:''' Virtual Private Cloud (VPC), Firewall Rules.
** '''Serverless:''' Cloud Functions.
** '''Bases de Datos:''' Cloud SQL, Cloud Spanner, Firestore.
* '''Herramientas de Seguridad Nativas:'''
** Security Command Center.
** Cloud Logging, Cloud Monitoring.
** Cloud Key Management.
** Cloud Armor (WAF/DDoS).
* '''Herramientas de Pentesting:'''
** '''gcloud CLI:''' Para interactuar con los servicios.
** '''ScoutSuite:''' Soporte para GCP.
** '''Pacu (módulos limitados de GCP):''' Algunos módulos experimentales.
** '''GCPBucketBrute:''' Para enumerar buckets de Cloud Storage.
* '''Vulnerabilidades Comunes:''' Permisos excesivos de Cloud IAM, Storage Buckets públicos, Firewall Rules laxas.