AWS - IAM Post Exploitation

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.

IAM

Para más información sobre el acceso IAM:

AWS - IAM, Identity Center & SSO Enum

Problema 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:

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

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

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" },
}

Esta política permite que todo AWS asuma el rol.

Service as principal

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Esta política permite a cualquier cuenta configurar su apigateway para llamar a este Lambda.

S3 como principal

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

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

{
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

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

• https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Apoya HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los repositorios de github de HackTricks y HackTricks Cloud.