El bucketsquatting de S3 (por fin) desapareció

 (onecloudplease.com)
2 puntos por GN⁺ 2026-03-14 | 1 comentarios | Compartir por WhatsApp
  • AWS introdujo una nueva protección de espacio de nombres basada en cuentas para resolver el problema de S3 bucketsquatting
  • El nuevo espacio de nombres usa el formato <prefix>-<accountid>-<region>-an, y solo la misma cuenta puede crear un bucket con ese nombre
  • Si otra cuenta intenta usar el mismo nombre, se produce el error InvalidBucketNamespace; el mismo error también se devuelve si se especifica una región incorrecta
  • Se recomienda usar este espacio de nombres por defecto, y puede aplicarse de forma obligatoria en políticas organizacionales (SCP) con la clave de condición s3:x-amz-bucket-namespace
  • No se aplica de forma retroactiva a los buckets existentes, pero ofrece una protección sólida para los buckets nuevos, lo que representa una mejora fundamental en la arquitectura de seguridad de S3

Resumen del problema de bucketsquatting

  • Bucketsquatting (o Bucketsniping) es una forma de ataque que aprovecha que los nombres de buckets en AWS S3 son globalmente únicos
    • Cuando un bucket se elimina, su nombre vuelve a quedar disponible, por lo que un atacante puede registrar un bucket nuevo con ese mismo nombre
    • Esto puede provocar riesgos de acceso a datos sensibles o interrupciones del servicio
  • Las organizaciones solían usar con frecuencia convenciones de nombres predecibles como myapp-us-east-1, lo que aumentaba la exposición a este tipo de ataques
  • Incluso equipos internos de AWS se vieron afectados por este problema, y durante unos 10 años trabajaron junto con el equipo de seguridad de AWS para encontrar una solución

Nuevo espacio de nombres de S3

  • AWS introdujo el concepto de espacio de nombres por cuenta (account namespace) para resolver el problema
    • Formato: <prefix>-<accountid>-<region>-an
    • Ejemplo: myapp-123456789012-us-west-2-an
  • Este espacio de nombres restringe la creación del bucket con ese nombre a la cuenta correspondiente
    • Si otra cuenta intenta crear el mismo nombre, aparece el error InvalidBucketNamespace
    • El mismo error también se devuelve si la región del nombre del bucket no coincide con la región real
  • AWS recomienda usar este espacio de nombres por defecto en todos los buckets nuevos
    • A diferencia de espacios de nombres existentes como .mrap, --x-s3, -s3alias, esta vez se introdujo como un espacio de nombres para usuarios generales con fines de seguridad

Aplicación y gestión de políticas

  • Los administradores de seguridad pueden usar la clave de condición s3:x-amz-bucket-namespace para exigir el uso del espacio de nombres mediante políticas organizacionales (SCP)
  • No se aplica automáticamente a buckets existentes ni a plantillas sin espacio de nombres
    • Para proteger buckets existentes, es necesario crear un bucket con el nuevo formato de espacio de nombres y migrar los datos
  • Con esta medida, el bucketsquatting está en la práctica “desapareciendo”, y los buckets nuevos reciben protección completa

Enfoque de otros proveedores de nube

  • Google Cloud Storage (GCS) ya usa un espacio de nombres basado en verificación de nombres de dominio
    • Los buckets con formato de dominio como myapp.com solo pueden ser creados por el propietario del dominio
    • En buckets que no usan formato de dominio, sigue existiendo la posibilidad de bucketsquatting
  • Azure Blob Storage usa una estructura de nombre de cuenta de almacenamiento + nombre de contenedor
    • Como el límite máximo es de 24 caracteres, el espacio de nombres es más reducido y podría ser más vulnerable al mismo problema

Conclusión (tl;dr)

  • AWS S3 incorporó un nuevo espacio de nombres de cuenta y región
  • Este espacio de nombres previene ataques de bucketsquatting y se recomienda usarlo siempre al crear buckets nuevos
  • Los buckets existentes no quedan protegidos automáticamente, así que, si es necesario, conviene reforzar la protección mediante migración de datos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-14
Opiniones de Hacker News

  • Recientemente descubrí que no se puede reutilizar la dirección de correo del usuario root incluso después de eliminar una cuenta de AWS
    Alguien de nuestra organización creó el usuario root de una cuenta cerrada con el correo principal de la empresa, y luego creó una cuenta nueva con otro correo, pero ahora ya pasó incluso el período de recuperación tras la eliminación
    Como resultado, ese correo quedó ligado permanentemente a la cuenta root eliminada, así que ya no fue posible iniciar sesión por SSO mediante un IdP externo
    Contactamos al soporte de AWS, pero casi no nos ayudaron

    • Hace poco, mientras ayudaba con soporte al cliente, vi un caso en el que, tras la salida del ingeniero principal anterior, el MFA de la cuenta root quedó vinculado a su celular
      La contraseña estaba documentada, pero no había forma de desactivar el MFA, así que contactamos a soporte de AWS, al ejecutivo de cuenta y a otros, pero no se pudo resolver
      Al final, el acceso a la cuenta root quedó bloqueado, y existe la posibilidad de que tengamos que migrar todo un entorno complejo a una cuenta nueva
    • Si tu proveedor de correo lo permite, puedes usar plus addressing
      AWS reconoce los correos con signo más como direcciones distintas
    • La cuenta root no debe usarse para personas; debe crearse como una cuenta especial de emergencia y guardar sus credenciales de forma segura
      Lo ideal es usarla solo cuando ocurra un problema realmente grave
    • Esto vuelve a mostrar lo frágil que puede ser la seguridad
      Al final, si algún phishing logra engañar al equipo de soporte al cliente y consigue una calificación de 10 puntos, todo podría venirse abajo
    • Si el correo del IdP se mapea a un rol, me pregunto qué significa exactamente que “quedó permanentemente ligado a la cuenta root eliminada”
      Me gustaría saber qué mecanismo es el que realmente impide su uso

  • Parece que el autor entendió mal el concepto de account name en Azure Blob Storage
    En la práctica está al mismo nivel que el nombre de bucket en S3, debe ser globalmente único y sigue siendo una gran molestia
    Sobre todo porque el límite de longitud es de 24 caracteres, lo que lo hace aún más frustrante
    Ojalá Microsoft también introduzca un namespace por cliente, como AWS

    • Hace unos 10 años, el equipo de S3 ya era consciente de este problema
      Pero por las limitaciones del diseño inicial no pudieron cambiarlo
      Personalmente, no entiendo por qué todavía no han creado una API S3 v2
      Podrían haber impulsado una migración gradual con una API nueva, pero al final tanto clientes como ingenieros siguen sufriendo innecesariamente
    • La primera vez que usé Azure, me pareció un diseño muy extraño ver que los recursos no estaban namespaced a nivel de cuenta
    • El propio autor apareció para decir que actualizó el artículo incorporando los comentarios
    • El límite del nombre no es solo de 24 caracteres, sino que además no permite guiones, guiones bajos ni puntos,
      así que solo se pueden usar números y minúsculas, lo cual es muy incómodo
      Ojalá al menos permitiera guiones, como S3 o GCS
    • Que ni siquiera se puedan usar guiones en el nombre de una cuenta de almacenamiento me parece un diseño terrible
      Otros recursos, como el registry de contenedores, tienen el mismo problema

  • Pienso que para nombres de paquetes, buckets, cuentas de GitHub y similares podría usarse un formato como el de Discord: @nombre-4dígitosaleatorios
    Así se democratiza el espacio de nombres y se evitan los ataques de squatting o reutilización
    Cuando una cuenta se elimina, se puede descartar el nombre completo y listo

    • Pero Discord eliminó ese formato hace 2 años y cambió a un sistema de nombres globalmente únicos
      La razón se explica en el anuncio oficial:
      era incómodo tener que recordar 4 dígitos y además distinguir mayúsculas y minúsculas
    • Personalmente, creo que un sistema de UUID + petname sería mejor
      Sobre todo en apps de chat, lo más limpio es usar un ID interno y dejar que el usuario use solo un alias
      En el caso de los buckets, como lo importante es que el nombre sea fácil de leer para humanos, me parece mejor usar tu propio dominio
    • Puede servir para buckets, pero para evitar package hijacking un código de 4 dígitos no ayuda mucho
      Más bien aumenta el riesgo de errores de escritura
    • Ojalá se pudiera usar en todas partes un esquema de nombres basado en validación de dominio (@example.com)
    • Cuando construía herramientas internas, asignaba a los usuarios un ID interno opaco y les permitía cambiar libremente el nombre
      En las comunidades en línea es natural que haya nombres repetidos,
      así que me pregunto por qué se insiste en forzar nombres globalmente únicos

  • Gracias a Ian Mckay por el artículo
    Es un buen cambio que AWS haya introducido oficialmente un namespace por cuenta y región
    Sería aún mejor si herramientas IaC como Terraform adoptaran esta regla como valor predeterminado
    Terraform ya agrega un sufijo hash aleatorio al final del nombre del bucket para evitar colisiones
    También hay información relacionada en el blog oficial de AWS

  • Es interesante el ataque de bucket squatting que ocurre cuando los proveedores de nube usan nombres de bucket predecibles para espacios internos temporales
    En AWS el ataque real era difícil por los hashes, pero GCP tuvo problemas de este tipo incluso recientemente
    Presentación relacionada: charla de DC32 sobre bucket squatting en AWS,
    vulnerabilidad en GCP: CVE-2026-1727

    • Esa charla fue realmente impresionante
      En cuanto vi que los nombres de bucket eran predecibles, intuía el riesgo
      Con la combinación de bucket squatting + bucket público + problema TOCTOU de CloudFormation,
      sí se podía llegar a desplegar recursos en otra cuenta
      Sorprende que el equipo de seguridad de AWS no lo haya detectado antes

  • Los nombres DNS tienen un problema parecido
    Si no renuevas el dominio, alguien puede volver a registrarlo
    y configurar registros MX para interceptar correos de restablecimiento de contraseña y similares

    • También hay casos en los que se recuperan activos como bloques IPv4 heredados de esta manera

  • Los buckets de AWS todavía ofrecen funciones especiales solo cuando su nombre coincide con el hostname
    Documentación relacionada: Virtual Hosting in S3

  • Un nombre no debe ser igual al objeto que designa
    Si el nombre se reutiliza, pasa a señalar algo completamente distinto,
    y su significado cambia según el contexto
    Solo puede considerarse el mismo si uno mismo vuelve a asignar ese nombre

  • Me preguntaba si exponer el ID de cuenta representa un riesgo de seguridad

    • AWS indica oficialmente que el ID de cuenta no es información secreta
      Según la documentación oficial,
      debe tratarse con cuidado, pero no se considera información sensible
    • En mi opinión, como una dirección de correo, es un identificador, no un medio de autenticación
      Mientras no se exponga demasiado, no hay problema
    • Desde el punto de vista de higiene no es ideal, pero no se puede atacar solo con el ID de cuenta
      En las reglas de IAM el atacante puede usar *, así que al final lo importante es cómo configura las políticas el lado defensor
    • Si compartes una URL firmada de S3, ahí se incluye el Access Key ID
      Si lo decodificas en base32, puedes extraer el Account ID
      Referencia: análisis relacionado

  • Que S3 haya usado solo el nombre del bucket como clave de acceso fue una de las decisiones de diseño más irritantes