AWS - IAM Post Exploitation

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: 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 HackTricks y HackTricks Cloud repos de github.

IAM

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

AWS - IAM, Identity Center & SSO Enum

Problema del Diputado Confundido

Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente tendrás 0 visibilidad sobre quién puede exactamente acceder a esa cuenta externa. Este 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. Esta es una cadena "secreta" que la cuenta externa (A) necesita especificar para asumir el rol en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso a 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 IAM podrá verlo. Pero mientras la cuenta externa A lo conozca, pero la cuenta externa B no lo conozca, esto 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 diputado confundido, necesitará averiguar de alguna manera si los principales de la cuenta actual pueden suplantar roles en otras cuentas.

Confianzas inesperadas

Comodín como principal

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

Esta política permite a todos los AWS asumir el rol.

Servicio como 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 esta Lambda.

S3 como principal

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

Si un bucket de S3 se da como principal, porque los buckets de 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 pueden no soportar eso (como CloudTrail según algunas fuentes).

Referencias

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

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.