Confused Deputy Problem and its defense
Hello everyone,
Hope you all are doing well. In this technical blog, we will be talking about the confused deputy problem in AWS IAM and how can we defend it. Note this blog is only for education purpose. This problem is misused if not configured properly. Consider a following situation - You have an AWS Account and your AWS account contains an AWS IAM role that trusts a third party service provider. The AWS IAM role’s trust policy specifies the service provider’s AWS account as authorized to assume the IAM role The problem unfolds as follows:
1. You provide your AWS IAM role’s ARN to the service provider when you are using their service as a part of requirement.
2. The service provider uses your IAM role ARN to obtain temporary credentials for accessing your AWS Account resources.
3. Another customer of the same service provider discovers your IAM role’s ARN through various methods.
4.When this other customer requests service actions, the provider uses your discovered AWS IAM role to access your resources instead of the other malicious customer’s intended resources.
This scenario allows the malicious customer to gain access to your AWS Account resources because they successfully manipulated the service provider into acting as a confused deputy using your legitimately discovered IAM role ARN.
Defense Solutions -
1) Use ExternalID in the trust policy:
One of its defense includes requiring external ID validation in AWS IAM role trust policies. The service provider generates unique external ID values for each customer and includes these values when assuming AWS IAM roles.
External IDs must be unique for the all the customers.
The service provider should control the generation of external ID, not the customers.
External IDs shouldnt be self generated, they should be generated and provided by the service provider.
Below is a sample trust policy -
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::293449058656:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "100200300"
}
}
}
}
2) Use RCPs in AWS Organization:
Resource Control Policies in AWS Organizations helps you for centrally controlling, without modifying every resource policy individually.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyServicePrincipalAccessOutsideOrg",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:PrincipalIsAWSService": "true"
},
"Null": {
"aws:SourceAccount": "false"
},
"StringNotEquals": {
"aws:SourceOrgID": "o-23556sa23e"
}
}
}
]
}
This will handle that only AWS service principals within your AWS Organization (o-23556sa23e) can access resources like S3 buckets, while still allowing requests from your own IAM principals.
3) Use of Condition keys in the trust policy:
AWS provides global condition keys that help prevent cross-service confused deputy problems. These keys allow resource policies to validate the context of service principal requests.
Essential Condition Keys: aws:SourceArn , aws:SourceAccount aws:SourceOrgID aws:SourceOrgPaths
Below is an example of S3-Cloudtrail Integration -
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLambdaPutObject",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::secure-lambda-bucket/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:lambda:us-east-1:123456789012:function:MySecureLambda"
}
}
}
]
}
This policy will handle that only the specified Lambda function in the given account can put objects into the S3 bucket. It prevents Lambda functions from other accounts, or even other functions in the same account, from writing data if they are not explicitly allowed.
Hence, in this blog, we learnt more on Confused deputy problem and its defense in AWS IAM.
See you in the next blog.
Thanks,
