Cómo encontrar el ID de cuenta de AWS de cualquier bucket de S3

Artículo original ↗ Discusión en Hacker News ↗

Una nueva técnica muestra cómo inferir el ID de cuenta de AWS que posee cualquier bucket de S3 abusando de la coincidencia de condiciones de IAM, lo que plantea preguntas sobre qué metadatos antes implícitos ahora pueden mapearse y correlacionarse. Quienes comentan coinciden en gran medida en que los IDs de cuenta de AWS no están destinados a ser secretos —AWS lo dice explícitamente—, pero discrepan sobre si tratarlos como “sensibles” por motivos de seguridad operativa o riesgos de correlación sigue teniendo valor. Muchos ven esto como un recordatorio de que la seguridad no debe depender de identificadores ocultos ni de la oscuridad, y de que los verdaderos peligros a abordar son las políticas cruzadas mal configuradas y la filtración de metadatos.

Alcance del hallazgo

  • La técnica usa políticas de buckets de S3 y condiciones s3:ResourceAccount con comodines para inferir qué cuenta de AWS posee un bucket determinado.
  • Muchos lo ven como un canal lateral interesante más que como una ruptura directa: aún necesitas configuraciones incorrectas o información adicional para obtener acceso.

¿Los IDs de cuenta de AWS son secretos o sensibles?

  • La documentación de AWS dice explícitamente que los IDs de cuenta no son secretos, sensibles ni confidenciales.
  • Una postura: los IDs de cuenta deben tratarse como públicos; diseñar sistemas que dependan de su secreto es mala seguridad y una “suposición falsa”.
  • Otra postura: no son “secretos”, pero sí “sensibles”; filtrarlos añade valor a los atacantes y debería minimizarse cuando sea práctico.

Seguridad operativa y filtración de metadatos

  • La principal preocupación no son los IDs en bruto, sino las relaciones:
    • Correlacionar varios buckets con el mismo propietario (por ejemplo, distintas marcas, clientes, proyectos internos).
    • Vincular buckets “ocultos” o de staging con una cuenta de producción conocida.
    • Casos de uso de inteligencia de negocio / espionaje (por ejemplo, aprender sobre proyectos a partir de los nombres de buckets).
  • Algunos dicen que esto es opsec, no seguridad; otros argumentan que la opsec sigue siendo legítimamente importante.

Debate sobre la seguridad por oscuridad

  • Varios sostienen que la oscuridad es, como mucho, una capa débil y no rotatable, y que nunca debe usarse como control.
  • Otros responden que la información “no pública pero no secreta” es una preocupación válida de opsec y no implica que se use como mecanismo de control de acceso.
  • Punto de consenso: no diseñes IAM ni modelos de amenazas que asuman que el ID de cuenta permanecerá oculto.

Comodines de IAM y diseño de políticas

  • A muchos les sorprende que IAM permita coincidencia con comodines (StringLike) sobre IDs de cuenta; varios no ven un caso de uso legítimo para control de acceso.
  • Explicaciones ofrecidas:
    • Un lenguaje de políticas genérico y poco tipado que aplica operadores de cadenas en todas partes por simplicidad.
    • Usos posibles, aunque dudosos (agrupar muchas cuentas por prefijo, sharding, reducción del tamaño de las políticas).

Vectores y herramientas relacionados de enumeración

  • Los IDs de claves de acceso de AWS incorporan el ID de cuenta y aparecen en URLs prefirmadas, así que probablemente muchos IDs ya se estaban filtrando.
  • Otros espacios de nombres globales (por ejemplo, proveedores de AMI, otros recursos públicos) exponen IDs de cuenta de forma natural.
  • AWS Config con agregación a nivel de organización y Athena se destaca como la forma “correcta” de localizar internamente qué cuenta posee qué recurso, aunque no es gratis.