AWS - IAM Post Exploitation

Aprende hacking en AWS desde cero hasta experto con htARTE (Experto en Equipo Rojo de HackTricks en AWS)!

Otras formas de apoyar a HackTricks:

IAM

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

pageAWS - IAM, Identity Center & SSO Enum

Problema del Delegado Confundido

Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente no tendrás 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. Esta es una cadena "secreta" que la cuenta externa (A) debe especificar para asumir el rol en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso sobre A, no podrá acceder a tu rol.

Sin embargo, ten en cuenta que este ExternalId "secreto" no es realmente un secreto, cualquiera que pueda leer la política de asumir roles de IAM podrá verlo. Pero siempre y cuando la cuenta externa A lo conozca, y la cuenta externa B no lo conozca, evita 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 a un subalterno confundido, necesitará encontrar de alguna manera si los principios de la cuenta actual pueden hacerse pasar por 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 se proporciona un bucket de S3 como principal, dado que los buckets de S3 no tienen un ID de cuenta, si borraste tu bucket y el atacante lo creó en su propia cuenta, entonces podrían abusar de esto.

No compatible

{
"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 admitir eso (como CloudTrail según algunas fuentes).

Referencias

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Última actualización