AWS - IAM Post Exploitation

支持 HackTricks

IAM

有关 IAM 访问的更多信息:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

如果你允许一个外部账户 (A) 访问你账户中的一个角色,你可能对谁能准确访问该外部账户几乎没有可见性。这是一个问题,因为如果另一个外部账户 (B) 能访问外部账户 (A),那么B 也可能能够访问你的账户

因此,当允许外部账户访问你账户中的角色时,可以指定一个 ExternalId。这是一个“秘密”字符串,外部账户 (A) 需要指定它才能假设你组织中的角色。由于外部账户 B 不知道这个字符串,即使他能访问 A,他也无法访问你的角色

然而,请注意这个 ExternalId “秘密”并不是秘密,任何能读取 IAM 假设角色策略的人都能看到它。但只要外部账户 A 知道它,而外部账户 B 不知道它,它就能防止 B 滥用 A 访问你的角色

示例:

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

对于攻击者来说,要利用一个混淆代理,他需要以某种方式找到当前账户的主体是否可以冒充其他账户中的角色。

意外的信任

通配符作为主体

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

此策略允许所有 AWS 承担该角色。

Service as principal

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

此策略允许任何账户配置其apigateway以调用此Lambda。

S3 as principal

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

如果一个S3 bucket被作为principal,因为S3 buckets没有Account ID,如果你删除了你的bucket并且攻击者在他们自己的账户中创建了它,那么他们可能会滥用这一点。

不支持

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

避免混淆代理问题的常见方法是使用带有 AWS:SourceArn 的条件来检查来源 ARN。然而,某些服务可能不支持这一点(根据一些消息来源,如 CloudTrail)。

参考资料

支持 HackTricks

Last updated