Preventing the Cross-Service Confused Deputy Attack on AWS

ACM.336 Adding Conditions to A Generic AWS Service Role CloudFormation Template

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Secure Code | Batch | IAM

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I sorted out the AWS Batch Documentation and provided some suggestions for more consistency in AWS documentation across the board. Better documentation would drive more service usage and more secure service implementations.

Now that we’ve sorted out the roles we need to create and have a better understanding of the Batch architecture, we can return to building our roles in CloudFormation. One of the things I was thinking about along the way was a global way to prevent the confused service deputy attack mentioned in the Batch documentation.

Essentially there should be a link to a global page that explains how to prevent this problem for every service, in my opinion. Then for every service hopefully there’s documentation on how to prevent this attack for a specific service.

Let’s take a look at the recommended condition for AWS Batch and add it to the generic CloudFormation template I created to deploy Service Roles.

I already have a function to create a service role. I add the AWS Batch service as noted in a prior post.

My deployment script has the following:

Here’s my generic service role:

For the Batch Service specifically, the documentation recommends a trust policy like this.

How does that policy prevent a confused deputy attack for an AWS Service?

We can find more information about the confused deputy attack here:

But I find some of the documentation slightly misleading or at least — confusing — ironically. Like this line:

Some AWS services use aws:SourceAccount and aws:SourceArn in trust policies for newly created roles, but using the keys isn't required for existing roles in your account.

What? If you created a role without this condition prior to reading this documentation, I presume the trust policy lacks the protections and should be updated.

Anyway, what is the confused deputy problem as it specifically relates to services? I already wrote about it for other use cases (and probably services) but let’s look at it more closely to see what we need to add to our generic service template.

The confused deputy problem allows someone to assume a role to obtain privileges that were not intended for that principal. We only want to allow those who are specifically authorized to assume a role.

For example, I wrote about the dangers of IAM PassRole. If you give a developer the IAM PassRole privilege and they can use any role with any EC2 instance, they could spin up an instance and add a role for a production resource to obtain access to things in production their own user role or roles they can assume directly do not have.

In the case of a service provided by a third party, if someone knows you are using a particular role in an AWS account with a third party service, that person could create their own account with the third party and specify your role in their account to obtain access to your resources. Using an external ID that is restricted to your account with the external service provider will help prevent that problem as explained in the above documentation.

In the case of our Batch jobs we are granting a service the ability to assume a role. Who has permission to create AWS Batch resources in your account? Which roles can they apply to the Batch resources they create? Do any of those roles have more permission than the person creating the batch resources has? Is there any way to assume a role from a batch job to access a resource that batch job shouldn’t be able to access?

The goal is to be as specific as possible in our trust policies when specifying who is allowed to assume a role. Our threat modeling should include who could possibly assume and abuse a role as we design our systems and create trust policies that prevent unauthorized role assumption.

In fact, we may want to consider these restrictions for the role that we are using with MFA as well to access secrets, but I’ll think on that and get to it later. For now, we want to lock down our service role more specifically to limit who can assume the role.

So revisiting our role above:

Only requests that are from a specific source account can assume the role.

Only requests where the source ARN is a specific batch compute environment a batch job can assume the role.

But is the above recommended condition correct? As I took a look at all the different roles for AWS Batch, it seems like some roles are assumed by the AWS Batch compute environment. Other roles are assumed by AWS Batch jobs. Perhaps we only need the first ARN in the Batch compute environment role and the second ARN in the job specific role.

• We don’t want the AWS Batch environment role assuming our batch job roles.
• We don’t want our batch jobs assuming the compute environment role.

I may be misunderstanding something and will revise this upon further testing if needed but that seems logical to me at this point.

Limiting requests to the current account in our generic service role template

I wrote about conditions and context keys in prior IAM Posts.

I was specifically reviewing context keys and the impact of multiple conditions in a policy in this post:

I want to add a generic condition in that template that will work for any role I deploy.

Adding the SourceAccount restriction to our generic trust policy

AWS has global context keys, one of which is aws:SourceAccount.

Use this key to compare the account ID of the resource making a service-to-service request with the account ID that you specify in the policy.

It seems like we can apply this generically to every service to limit it to the current account for most use cases. If for some reason we ever need cross-account access for a service, we could add that logic. I imagine some AWS Organizations roles may need cross account access. I’ll revisit that if and when I redeploy those roles. It could be a matter of specifying to use the AWS root account ID (but probably not allowing someone to pass in any account ID — I would pull that from a trusted source that the person deploying the role could not alter.)

I can add this condition to my policy using the account ID pseudo parameter: AWS::AccountId.

Let’s see if our Batch roles deploy successfully with that change that I already started creating in prior posts.

Yes and if I head over to the trust policy for the role, I can see the update.

Adding a SourceArn condition

Next we have our source ARNs. What I wanted to run as a test is to see if we can use a generic source ARN for all services like this:

      ArnLike:
        aws:SourceArn:
          - !Sub arn:aws:batch:${AWS::Region}:${AWS::AccountId}:*/*

That way at least the role assumption would be limited to a specific service in a specific account and region.

That also worked:

The one thing I need to do now is replace “batch” in my ARN with the service name. I have a Parameter called AWSServiceParam but it has a capital letter and our ARN needs a lowercase later I presume.

I add the lowercase version of the name to my mappings:

I add the logic to find the value in the map to my ARN:

And miraculously it worked on the first try.

Now at least any new service role we deploy will have those limitations.

Here’s the full condition.

But want if we need a more specific SourceArn?

As I’ve done in other posts using CloudFormation, we can pass in an optional parameter that overrides the SourceArn list. If the parameter has a value, then we use that. If it doesn’t, then we can use the default ARN above.

I’m going to save that for another post when I have a chance to test out the Batch roles more thoroughly. I can look at the requests that perform the AssumeRole actions to figure out exactly what the sourceArn values need to be.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab