Buckets y almacenamiento público

El almacenamiento de objetos (S3 en AWS, Blob en Azure, Cloud Storage en GCP) es uno de los servicios cloud más usados y, por configuraciones laxas, una de las mayores fuentes de fugas de datos de la historia reciente. Un bucket mal configurado puede exponer backups, bases de datos, credenciales, código fuente y datos personales a cualquiera con la URL. Descubrir y evaluar buckets es casi obligatorio en todo pentest cloud.

El problema

Los buckets pueden configurarse para acceso público (lectura, listado e incluso escritura). Históricamente el acceso público ha sido fácil de activar por error, y los nombres predecibles (empresa-backups) facilitan encontrarlos. Resultado: incontables brechas por buckets abiertos (Verizon, Accenture, Capital One, y un largo etcétera).

Descubrir buckets

# patrones de nombres a probar
target, target-backups, target-dev, target-prod, target-assets, target-logs...
# herramientas de descubrimiento
cloud_enum -k target          # S3 + Azure Blob + GCS a la vez
s3scanner scan -f buckets.txt
# buscadores de buckets ya indexados
GrayhatWarfare (buckets.grayhatwarfare.com)
# Google dorking (ver recon-dorking)
site:s3.amazonaws.com target

Comprobar acceso (AWS S3)

# listar el contenido (si permite listado público)
aws s3 ls s3://<bucket> --no-sign-request
curl https://<bucket>.s3.amazonaws.com/            # lista XML si es público
# descargar todo
aws s3 sync s3://<bucket> ./loot --no-sign-request
# ¿escritura? (muy grave: subir ficheros, webshell, defacement)
aws s3 cp test.txt s3://<bucket>/ --no-sign-request
# permisos/ACL del bucket
aws s3api get-bucket-acl --bucket <bucket> --no-sign-request

--no-sign-request prueba el acceso anónimo. El acceso de escritura anónimo es crítico (envenenamiento de contenido, hosting de malware).

Azure Blob y GCS

# Azure Blob
https://<account>.blob.core.windows.net/<container>?restype=container&comp=list
# GCS
gsutil ls gs://<bucket>              # si es público
curl https://storage.googleapis.com/<bucket>

Qué buscar dentro

# lo más jugoso
backups (.sql, .bak), .env, config, claves (.pem, id_rsa, service-account.json)
código fuente, dumps de BD, datos personales, logs con secretos
# tras descargar, buscar secretos
grep -rniE 'password|secret|api_key|AKIA' ./loot
trufflehog filesystem ./loot

Más allá del listado: otros vectores

Snapshots/EBS públicos, AMIs públicas, RDS snapshots compartidos → datos expuestos sin ser “buckets”.
Subdomain takeover si un CNAME apunta a un bucket que ya no existe (ver Subdomain takeover).
Políticas de bucket demasiado abiertas (no solo ACL): Principal: *.

Para la defensa

Block Public Access a nivel de cuenta (AWS) / acceso público deshabilitado por defecto (Azure/GCP).
Políticas y ACL mínimas: nunca Principal: * ni AllUsers; revisar con herramientas (Prowler/ScoutSuite marcan buckets públicos).
Cifrado en reposo, versioning y logging de acceso (S3 access logs / CloudTrail data events).
No poner secretos en buckets; usar gestores de secretos. Nombres no predecibles no son defensa.
Monitorizar accesos anónimos y cambios de política; remediar snapshots/AMIs públicos.

Checklist de prueba

Descubrir buckets por patrones y herramientas (cloud_enum/GrayhatWarfare)
Probar listado anónimo (—no-sign-request / curl)
Descargar contenido y buscar secretos (trufflehog)
Probar escritura anónima (crítico)
Revisar ACL y políticas del bucket
Azure Blob y GCS equivalentes
Snapshots/AMIs/RDS públicos
Subdomain takeover por bucket inexistente (Subdomain takeover)