Se ha descubierto una técnica de ataque crítica denominada "bucket hijacking" (secuestro de buckets), que permite a los atacantes redirigir silenciosamente los flujos de datos activos de una organización, como registros de auditoría y telemetría, hacia almacenamientos externos controlados por ellos. Se ha confirmado que este método afecta a las principales plataformas de nube: Google Cloud, Amazon Web Services (AWS) y Microsoft Azure.

Una técnica crítica de ataque al almacenamiento en la nube denominada "secuestro de buckets" (bucket hijacking) es un método que permite a los actores de amenazas redirigir silenciosamente los flujos de datos activos en la nube de una organización, incluidos los registros de auditoría y la telemetría, hacia buckets de almacenamiento externos controlados por el atacante en las principales plataformas de nube.

Se ha confirmado que la técnica afecta a Google Cloud, Amazon Web Services (AWS) y Microsoft Azure, habiendo sido notificados los tres proveedores a través de una divulgación responsable.

Aunque todavía no se ha observado a ningún actor de amenazas del mundo real explotando esta técnica, los investigadores advierten que su detección sería extremadamente difícil una vez desplegada.

El ataque explota un fallo arquitectónico fundamental basado en la unicidad global de los nombres de los buckets de almacenamiento en la nube. Debido a que no hay dos usuarios que puedan registrar un nombre de bucket idéntico dentro del espacio de nombres de un proveedor, la identidad de un bucket de almacenamiento de destino está ligada únicamente a su nombre, y no a un propietario de cuenta específico.

Un atacante que comprometa un entorno de nube y obtenga permisos de eliminación de buckets puede ejecutar el ataque en una secuencia sencilla:

1. Eliminar el bucket de almacenamiento activo de la organización objetivo.
2. Recrear inmediatamente un nuevo bucket utilizando el nombre idéntico dentro de una cuenta controlada por el atacante.
3. El flujo de datos original, ya sea un sumidero de registros de Google Cloud, una regla de replicación de AWS S3 o una exportación de diagnóstico de Azure Monitor, continúa operando de forma autónoma y comienza a escribir datos directamente en el bucket del atacante.

El ataque es particularmente peligroso porque es autosuficiente. Una vez completado el secuestro, la configuración legítima del sumidero o de replicación sigue pareciendo válida al inspeccionarla, no genera estados de error obvios y no activa ninguna alerta nativa. Los registros, las métricas y la telemetría sensible fluyen silenciosamente hacia el entorno del atacante de forma indefinida.

Nuevo Ataque de Secuestro de Buckets

Unit 42 simuló con éxito el secuestro de buckets en múltiples servicios de cada uno de los principales proveedores:

• Google Cloud: Confirmado en sumideros de Cloud Logging, suscripciones de Pub/Sub con destinos de Cloud Storage y trabajos del Servicio de Transferencia de Almacenamiento. Permisos requeridos: storage.buckets.delete y storage.objects.delete
• AWS: Confirmado en la replicación de buckets S3 y en los canales de Amazon Data Firehose dirigidos a destinos S3
• Azure: Demostrado como un ataque entre suscripciones a través de la configuración de diagnóstico de Azure Monitor; limitado al alcance del mismo inquilino debido a los retrasos en la reutilización de nombres impuestos por la plataforma

Los investigadores destacaron que los roles amplios de administración de almacenamiento, asignados comúnmente en entornos empresariales, aumentan drásticamente la exposición.

En Google Cloud, el rol estándar de Administrador de Almacenamiento concede storage.buckets.delete por defecto, eludiendo el permiso más restrictivo logging.sinks.update que sería necesario para reconfigurar legítimamente un flujo de datos. Esto permite efectivamente que los atacantes redirijan los flujos de datos sin tocar nunca las configuraciones del flujo directamente.

Unit 42 recomienda una estrategia de defensa doble que combine controles de acceso de privilegio mínimo y un monitoreo proactivo:

• Restringir los permisos de eliminación (storage.buckets.delete, DeleteBucket, Microsoft.Storage/storageAccounts/delete) a los roles administrativos mínimos requeridos
• Implementar controles de perímetro de datos —Políticas de Control de Servicios (SCPs) de AWS o Controles de Servicio VPC de Google Cloud— para bloquear escrituras en buckets fuera del límite organizativo confiable
• Habilitar los espacios de nombres S3 regionales de cuenta de AWS para limitar los nombres de los buckets a cuentas y regiones específicas, eliminando directamente el vector de secuestro
• Desplegar alertas de monitoreo de alta prioridad para las llamadas a la API de eliminación de buckets de almacenamiento, especialmente en aquellos que contengan datos sensibles o regulados

Unit 42 destacó que esta técnica no se limita a los tres proveedores probados. Cualquier plataforma en la nube que dependa de recursos de almacenamiento con nombres estáticos y globalmente únicos para el enrutamiento de flujos de datos podría ser vulnerable a la misma metodología.

La investigación refuerza que las filosofías de diseño compartidas entre los proveedores de la nube significan que un fallo descubierto en un ecosistema puede servir como un plano directo para explotar otro, un recordatorio crítico para los equipos de seguridad que gestionan entornos multi-nube.

Fuentes:
https://cybersecuritynews.com/bucket-hijacking-attack/