Confused Deputy Attack in IAM, Resource, and AssumeRole Policies

ACM.31: Considering how an attacker could abuse role templates

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

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | Application Security | IAM

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

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

FYI, I’m not getting paid for anyone who reads or claps on this particular story by Medium for some unknown reason. If you like this story please read and clap on the story in this blog to show your support.

~~

In the last post I showed you how not to design a CloudFormation template that defines an AWS trust policy. In this post I explain why in more detail.

Before we go any further in this series we want to take a look at a potential threat when using our roles, and especially cross-account or service roles. This security problem is known as the Confused Deputy in AWS terminology.

This attack is consists of an external attacker is able to leverage the permissions provided by a role externally to access your account.

How does a confused deputy attack work?

This attack reminds me of the subdomain takeover attack I spoke about at RSA 2020. You can find that and other presentations I’ve given in the past here. In that scenario, an attacker leverages a subdomain you own to gain access to services you may have used in that past with that subdomain. They may also find another way to leverage your subdomain without your permission.

There are three flavors of this confused deputy problem: Cross-account, Cross-service, and Role-Assumption.

Cross-Account Confused Deputy Attacks

In this case, an attacker is using a role in your account from another account. They somehow obtained the name of the role and they can use it in places where a role is required to integrate with a third-party system to obtain access to your data.

For example, I looked at a service that would leverage a role to run queries on your account remotely and display misconfigurations in their portal. What if an attacker could figure out what role you gave that company? If the vendor is not monitoring for the duplicate use of roles in their system and not validating that customers actually own the accounts where the role exists, an attacker could register their own account at the vendor, provide your AWS role to the vendor, and view all the misconfigurations in your AWS account in their own account at the third-party service.

To combat this problem AWS recommends making use of a external ID.

Don’t use any sensitive data in an external ID:

It will be visible in your AWS policies to anyone who can view them.

The External ID should be a random string generated by the third-party to whom you are giving access. When you create a role you add two conditions:

That means the other account cannot take an action unless the external ID is configured on their side. In order to grant access to leverage the role, the customer of the vendor has to add their unique external ID to the role policy.

How does this help exactly? Let’s take the scenario of our attacker again. The attacker tries to set up an account with the vendor to access your account with a role they have somehow guessed or acquired. When they register their account with the vendor, the vendor provides them a unique external ID. The external ID that the vendor provides to the attacker will not match the external ID they gave you. The attacker will not be able to use your role ARN in their vendor account, because the external IDs don’t match. They don’t know what external ID to use in their role configuration.

We’re not using any third-party services at the moment but I could use my services on customer projects. I do use external IDs when I work with customers on penetration tests as well as MFA as I wrote about in a prior post:

In addition, I ask customers to disable roles and credentials as soon as an engagement is over.

Cross-Service Confused Deputy Attacks with Resource Policies

The other scenario AWS mentions is cross-service impersonation, which is specifically mentioned in regards to AWS Lambda Step Functions:

In AWS, cross-service impersonation can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to use its permissions to act on another customer’s resources in a way it should not otherwise have permission to access.

To solve this AWS recommends the following:

We recommend using the aws:SourceArn and aws:SourceAccount global condition context keys in resource-based policies to limit the permissions that a service has to a specific resource. Use aws:SourceArn if you want only one resource to be associated with the cross-service access. Use aws:SourceAccount if you want to allow any resource in that account to be associated with the cross-service use.

Could someone access our resources using this attack that we’ve created so far? It looks like we could add some additional security to our resource policies. We’ll consider that in an upcoming post. For now I’m more concerned about the next potential attack.

Confused deputy problem and STS role assumption (trust policies)

Could an attacker use one of the roles I have built so far to carry out this type attack or some related attack where they can use our roles? Well, I’m not using any third-party service so far or using any external roles. But what else could lead to role-takeover or abuse?

We’ve specifically limited assumption of the IAM and KMS admins to specific users and required MFA. Unless the attacker has the credentials for that specific user and authenticates with MFA, they should not be able to assume those roles as they are specifically locked down to a single user.

What about our batch job role?

The one thing I did just do was show you how to create a role where someone could pass in an ARN to assume that role in a CloudFormation template. What might someone be able to do with this template? Anyone who can run this CloudFormation template for a batch job could pass in any ARN to assume the role they create. They will also be able to assume any of the batch job roles that start with the name “BatchRole.”

What have we done to prevent someone from abusing this functionality? So far we have only required MFA. Anyone who’s logged in with MFA could potentially run the CloudFormation script and pass in their own ARN to assume any batch job role.

Once someone has assumed batch job role they can do anything that batch job can do. So far in this series that includes creating a new set of credentials for our Batch Job administrator, so somewhat limited, but the goal of our batch jobs is to perform any number of functions. How could we further lock this down?

Fixing the problem by using hard-coded templates

One thing would be to revert to using a separate role template for each type of batch job and user and hard-coding the ARN in the template again. We could hard code in the ability for the IAM user to assume IAM batch job roles. We could hard code a separate role template to allow the Batch Job user to assume the regular batch job roles.

That would probably be the simplest approach but requires duplicating code. What’s the problem with duplicated code? I explained that in this blog post:

In addition to hard-coding the templates you need to obviously make sure that an attacker or malicious insider cannot edit the templates.

I would prefer not to take this approach if I can think of a better solution.

Can we fix the problem with an external ID?

What if we require an external ID. Well, take my case. I’m an administrator running this template but let’s say I can’t change the code. When I run this template I have to pass in an external ID provided by someone to pass into the script. There’s nothing from stopping me from changing the ARN and it will still work because someone has to give me the external ID so I can run the script.

What if we put the external ID in a secret? Well, the CloudFormation template will need to retrieve the secret right? I, as an administrator running the template, can still put in whatever ARN I want and the CloudFormation template will still execute. However, what happens when I try to go use the role? I will need to pass in the external ID:If can’t see or know that external ID then I won’t be able to put the external ID in my configuration and assume the role.

The caveat with that solution is that the external ID must not be present anywhere in the CloudFormation outputs or metadata. If I, as administrator, have permission to edit the CloudFormation template, I could try to get the value of the secret and display it in the CloudFormation outputs. If I only have permission to execute but not change the CloudFormation template, I won’t be able to do that.

The other caveat with this solution is that if I have permission to view the assume role policy after it is deployed, then I can get the external ID from there. If we use this option the person deploying the template:

1. Cannot have access to change the CloudFormation template.
2. Cannot have visibility into any place the external ID is output or viewable.

If this is a person responsible for maintaining cloud deployments, then likely they need to be able to view the resources created when the deployments execute, so this may be problematic in some cases. If you are providing a locked down environment for users to create batch job policies then you might be able to meet these criteria.

Limiting which roles users can assume

One of the mitigations AWS recommends for STS assume-role problems is to limit which roles a user can assume with conditions in the IAM User policy. Their example demonstrates a policy for an incident manager who can only assume an incident-manager role:

You could use this approach to limit those responsible for deployments who also do not have access to change this policy above from assuming batch job roles. They might have permissions to assume only a deployment role to execute CloudFormation to deploy a batch job, but not assume the roles the batch job deployment scripts create.

Limiting the ARNs that can be passed into our batch job template

What about further limiting the ARNs that can be passed into our batch job? We can update our role further to limit what ARNs will be used by our batch job roles instead of allowing our template to take any ARN as a parameter. To me, that is just too risky, but it was a way to get started and think through how I could use a single template for batch job roles.

Essentially so far I’ve determined I need to have two different types of batch jobs so far — batch jobs run by IAM administrators, and the batch jobs run to process data executed by a batch job administrator. If I can ensure that only those two roles can be used to assume batch jobs I’ll be better off. If I can figure out a way to ensure only the IAM administrator can assume IAM batch jobs and only the batch job administrator can run other types of jobs even better.

Read on for code changes to address those problems in our role template.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2024

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity for Executives in the Age of Cloud
⭐️ 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 Appication Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Medium: Teri Radichel
❤️ Sign Up For Email
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab