The Confused Deputy Problem happens when a trusted entity is misled into doing something wrong because it doesn't know it's being tricked by someone.
Analogy Think of a situation at a bank. You are a customer, and based on your instructions the bank teller handles tasks for your account, like deposits or withdrawals. One day Mr. Unknown walks into the bank pretending to be you. They tell the teller, "Do the money transfer from this customer’s account to mine." If the teller doesn’t confirm the person’s identity, they might accidentally send your money to the wrong person's account.
How this happens in AWS and how can we resolve it?
This can happen in AWS when a trusted AWS service (deputy) is confused and performs unauthorized actions because it doesn't verify from where the request comes.
This often happens in scenarios involving cross-account access or when services interact on behalf of multiple users/accounts.
Requirement: You hired a 3rd party to do the security audit periodically for your AWS account and provide the audit report.
For accessing your AWS account by the 3rd party AWS account:
Create an IAM Role for Cross-Account access and this IAM role is assumed by this 3rd party only
Create a Trust Policy by adding the 3rd party's account Id to the Principal object of the policy
Give the permissions in the policy for accessing the service
Share this role ARN with the 3rd party
3rd party will authenticate with AWS
Assume the Role provided by your account
Access your AWS account
3rd party access your account via IAM Role
Trust Policy:
configured
The above approach is very secure and AWS security will manage that this 3rd party account only accesses this role.
Now assume the same 3rd party is auditing many other customers' AWS accounts like Customer X and Customer Y along with your account as shown below:
3rd party access more than one account for auditing Is there any way the Other Customer can access your account using a third-party account?
Let's try this way: If Customer 'Y' somehow gets Your account's role which you have created for the 3rd party (arn: aws: iam::111111111111/security) by any means like Social Engineering etc. then Customer 'Y' can ask the 3rd party service provider to use Your IAM role to get your audit data.
See the below image for a simple explanation.
3rd party is a gave the audit data to Customer Y
Here the 3rd party account is the CONFUSED DEPUTY
3rd party Account is the Confused Deputy
Mitigation of Confused Deputy problem
We need some mechanism other than the Account Id to verify the account for which it is configured. So one of the solutions is to create an ExternalId attached to the Account Id and change the Trust policy to explicitly assign the ExternalId.
So whenever the Customer wants to assume the Role and try to access the account they MUST pass the ExternalId as well.
Assign ExternalId to all the customers accounts
Trust Policy:
Now if Customer Y tries to pass the IAM Role arn: aws: iam::111111111111/security to access Your account via 3rd party account, 3rd party will see the request coming from Customer Y and they will add the ExternalId of Customer Y to the request which will not match and there will be an Access Denied.
Extra check using ExternalId to resolve the problem
NOTE: Whenever you grant access to your account to a 3rd party environment always remember to configure the ExternalId (Unique) as a part of your IAM Role.
I have covered ExternalId as the solution here but services like IAM, Resource Policies, and Service Control Policies also help us to mitigate the Confused Deputy Problem.
