AWS - IAM Post Exploitation

支持 HackTricks

IAM

有关 IAM 访问的更多信息:

混淆代理问题

如果您允许一个外部账户 (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承担该角色。

服务作为主体

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

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

S3 作为主体

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

如果将 S3 存储桶作为主体,因为 S3 存储桶没有账户 ID,如果你删除了你的存储桶,攻击者在他们自己的账户中创建了它,那么他们可能会滥用这一点。

不支持

{
"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