AWS - IAM Post Exploitation
IAM
Para más información sobre el acceso IAM:
AWS - IAM, Identity Center & SSO EnumProblema del Deputy Confundido
Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente tendrás 0 visibilidad sobre quién puede acceder exactamente a esa cuenta externa. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que B también pueda acceder a tu cuenta.
Por lo tanto, al permitir que una cuenta externa acceda a un rol en tu cuenta, es posible especificar un ExternalId
. Este es un string "secreto" que la cuenta externa (A) necesita especificar para asumir el rol en tu organización. Como la cuenta externa B no conocerá este string, incluso si tiene acceso sobre A, no podrá acceder a tu rol.
Sin embargo, ten en cuenta que este ExternalId
"secreto" no es un secreto, cualquiera que pueda leer la política de asunción de rol de IAM podrá verlo. Pero mientras la cuenta externa A lo conozca, pero la cuenta externa B no lo conozca, previene que B abuse de A para acceder a tu rol.
Ejemplo:
Para que un atacante explote un confused deputy, necesitará encontrar de alguna manera si los principals de la cuenta actual pueden suplantar roles en otras cuentas.
Confianzas Inesperadas
Wildcard como principal
Esta política permite que todo AWS asuma el rol.
Service as principal
Esta política permite a cualquier cuenta configurar su apigateway para llamar a este Lambda.
S3 como principal
Si un bucket S3 se da como un principal, debido a que los buckets S3 no tienen un ID de Cuenta, si eliminaste tu bucket y el atacante lo creó en su propia cuenta, entonces podrían abusar de esto.
No soportado
Una forma común de evitar problemas de Confused Deputy es el uso de una condición con AWS:SourceArn
para verificar el ARN de origen. Sin embargo, algunos servicios podrían no soportar eso (como CloudTrail según algunas fuentes).
Referencias
Last updated