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

Encontrar el ID de cuenta de AWS de un bucket de S3

• En 2021, Ben Bridts presentó una forma ingeniosa de encontrar el ID de cuenta de AWS de un bucket de S3 público.
• Este artículo explica una técnica para encontrar el ID de cuenta tanto de buckets de S3 privados como públicos.

De un bucket de S3 al ID de cuenta de AWS

• Se muestra una técnica para encontrar, mediante la salida de la shell, el ID de cuenta de AWS antes desconocido de un bucket llamado bucket-alpha.

¿Cómo funciona exactamente esta técnica?

• Se analiza por qué funciona la técnica de Ben, combinando tres elementos clave:
  • la capacidad de aplicar políticas de IAM a una solicitud
  • la capacidad de inferir si una política de IAM permitió una solicitud o no
  • la capacidad de aplicar coincidencias con comodines a la clave de condición s3:ResourceAccount

La solución

• Se encontró una solución que usa un endpoint de VPC para S3 y aprovecha la diferencia de comportamiento en CloudTrail cuando una solicitud es rechazada.

Paso a paso

• Procedimiento paso a paso al intentar encontrar el ID de cuenta del bucket bucket-alpha:
  • determinar la región del bucket
  • desplegar una VPC y un endpoint de VPC en la misma región
  • iniciar una instancia EC2 dentro de la VPC y verificar que use el endpoint de VPC para S3
  • modificar la política del endpoint de VPC para determinar si el ID de cuenta del bucket objetivo comienza con "0"
  • hacer una solicitud al bucket objetivo
  • comprobar si la solicitud aparece en CloudTrail
  • según el resultado, modificar la política del endpoint de VPC para descubrir más información sobre el ID de cuenta

Resultado

• Se puede escribir un script que automatice este proceso para encontrar de forma confiable el ID de cuenta del bucket.
• Se realiza una búsqueda binaria para cada dígito con el fin de reducir la cantidad de pruebas necesarias.

Mejora de velocidad

• Se modificó la política del endpoint de VPC para reducir el tiempo que tarda en surtir efecto y la espera individual de los resultados en CloudTrail.
• Con esto, el tiempo necesario para encontrar el ID de cuenta se redujo a menos de 10 minutos.

Opinión

• Esta entrada del blog se publicó después de consultarlo con el equipo de seguridad de AWS.
• Hubo una discusión interesante sobre si el ID de cuenta de AWS debería considerarse información sensible.
• Esta técnica podría aplicarse también a otros servicios además de S3.
• Estas técnicas son posibles porque se pueden usar condiciones StringLike para s3:ResourceAccount.
• Podría ser útil que los eventos rechazados por políticas del endpoint de VPC se registraran en CloudTrail.

Agradecimientos

• La técnica original de Ben Bridts inspiró este trabajo.
• Agradecimientos a Chris Farris por su ayuda y sus consejos.

Opinión de GN⁺

• Esta técnica puede ser muy útil para realizar auditorías de seguridad en entornos de nube, especialmente para verificar la propiedad de buckets de AWS S3.
• La discusión sobre la sensibilidad de la información que ofrece esta técnica refleja la conversación continua sobre seguridad de datos y privacidad entre proveedores de servicios en la nube y usuarios.
• Otra herramienta con funciones similares es el propio servicio de AWS, CloudTrail, que se usa para registrar y monitorear toda la actividad que ocurre en el entorno de AWS del usuario.
• Antes de adoptar esta técnica, el usuario debe asegurarse de que esté alineada con las políticas de AWS y con las mejores prácticas de seguridad.
• Entre los beneficios de usar esta técnica están una auditoría de seguridad eficiente y la verificación rápida de la propiedad de los datos, pero también deben considerarse riesgos como una posible exposición de información personal.

[GN⁺]

Comentarios de Hacker News

• La capacidad de aplicar coincidencias con comodines a la clave de condición s3:ResourceAccount de AWS

  • Lo sorprendente de esto es que no hay una razón legítima para otorgar o denegar permisos con base en coincidencias parciales del ID de cuenta. Los ID de cuenta de AWS pueden ser sensibles, como una dirección IP, pero alguien tiene que conocerlos para poder hacer el trabajo.

• ID de cuenta de AWS == tu dirección IP. Puede ser sensible, pero para resolver cosas, alguien tiene que conocerlo.

  • Ejemplo: debido a procedimientos contra el lavado de dinero, el autor quería una configuración de PrivateLink, que por lo general es más segura que un puerto sftp abierto, para una operación con un tercero con el que necesitaban integrarse. Pero esa empresa se negó por razones de seguridad, para no revelar su ID de cuenta. Como resultado, el equipo del autor puso en lista blanca su rango de IP públicas en el puerto 22.
  • Moraleja de la historia: ocultar tu ID puede parecer inteligente, pero en realidad no puedes operar un negocio si la gente no tiene una dirección para contactarte.

• En general, no distribuirías públicamente tu ID de cuenta, pero en algún momento deberías asumir que parte de él se hará público.

  • A medida que los proveedores externos y las plataformas SaaS avanzan hacia métodos de integración que prefieren la asunción de roles (role assumption) sobre usuarios IAM y claves de acceso, el ID de la cuenta usada como punto de integración será conocido por la otra parte, y ellos tienen sus propias dependencias y vulnerabilidades.

• Otros recursos públicos de AWS con un espacio de nombres global también revelan el ID de cuenta de AWS.

  • Para quien tenga interés, publicó ese código en línea aquí: find-s3-account

• Relacionado: el ID de clave de AWS (no la parte de la clave secreta) incluye el ID de cuenta, desplazado un bit.

  • Ese ID de clave está incluido en la URL de los enlaces prefirmados para S3, así que es muy probable que ya estés exponiendo tu ID de cuenta.

• Es un hallazgo interesante, pero al ver el título esperaba un método más simple.

  • Ojalá hubiera una forma sencilla de preguntarle a AWS, desde una cuenta administradora, “¿dónde está el recurso X?”. En particular, hace falta una función que te diga rápido en qué cuenta está un bucket específico de S3. Esto suele ser un problema relacionado con buckets heredados que existían antes de definirse como código. Cuando tienes muchas cuentas de AWS, encontrar recursos entre cuentas desconocidas y posibles regiones puede ser engorroso.

• Siempre es genial cuando un hack real trae uno de esos viejos clichés o malentendidos de “hackear” una contraseña “un carácter a la vez”.

• Un vector de ataque aún más preocupante es cuando ahora intentas usar un número de cuenta para agregar a la lista permitida un principal de otra cuenta en la política de tu propia cuenta.

  • Si ese principal no existe en la otra cuenta, aparece un error de que no se pudo encontrar el rol/usuario. Eso puede aprovecharse para descubrir principales reales de otras cuentas.

• ¿Por qué importa esto? Una razón obvia: si te dan un bucket de producción, entonces podrías encontrar buckets de desarrollo de la misma organización, lo cual es un comportamiento inesperado.