Privilege Escalation Via a Cloud Compute Resource

ACM.133 Limiting Pass Role permissions using AWS IAM policies

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

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

🔒 Related Stories: IAM | AWS Security | Data Breaches | Penetration Testing

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

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

In the last post I wrote about AWS IAM Permission Boundaries.

AWS IAM Permission Boundaries

ACM.132 An underused and underrated IAM feature that can help prevent privilege escalation on AWS

medium.com

In this post we’ll consider permission boundaries with the IAM Pass Role permission.

The IAM Pass Role permission

How does a principal on AWS assign permissions to a compute resource? This can be accomplished via the IAM Pass Role permissions.

Granting a user permissions to pass a role to an AWS service

undefined

As AWS explains in the above documentation:

To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.

In other words, if a user wants to run commands on an EC2 instance, they can create an EC2 instance and assign a role to that EC2 instance with whatever permissions they want to use. Then they can run commands on that EC2 instance without providing any credentials. The EC2 instance obtains the credentials by virtue of the role the person who created it assigned to it.

The person running the commands on the EC2 instance can leverage the permissions assigned to the EC2 instance even if their own policy disallows those permissions.

Therein lies our privilege escalation problem. If an AWS user wants to take an action they don’t have permission to execute but they have the Pass Role permission on AWS, then they can leverage an AWS resource and a role assigned to the resource to carry out actions they cannot otherwise perform through their own assigned policies.

In other words, be very careful with Pass Role permissions on AWS.

This capability and potential for privilege escalation has been documented for years. I am not writing about something new. I’ve spoken about it and asked about it since I was on the initial Capital One team and running my meetup in Seattle.

How could we limit a user from escalating privileges through a role assigned to a compute resource?

Only provide the PassRole privilege with a specific role that has permissions that the user cannot modify

If we only allow a user to create compute resource and assign a specific role then we can limit their ability to escalate privileges.

For example, let’s say your organization allows application developers to create applications that retrieve files from S3 and write logs to CloudWatch. You could create a standard application role that developers can assign to their applications. In the developer policy you limit the developer from creating new roles and they can only pass this one assigned role.

Here’s an example from the AWS documentation above:

This is better than a free-for-all but it introduces some other security problems:

This allows an application to access *all* S3 buckets and logs instead of the logs specifically assigned to that application. See why this was a problem by taking a look at what happened in the Capital One Breach. You might be able to fix that through a consistent naming convention and some asterisks in the ARN In the policy.
You will probably need more permissions for some applications. There is generally not a one size fits all policy for all the applications an organization needs to build.
You will probably end up granting overly permissive policies as you add more and more permissions to your “generic” application policy. What if you have an application that needs no access to S3? Do you create a bucket for that application anyway? Do you let it have S3 permissions it doesn’t need?
Let’s say we wanted to prevent our IAM users from accessing Route 53. We could set up a limitation in their policy that they can only assign the IAM administration role to a resource. However, that role has a lot of permissions that won’t be required for a single batch job if we start creating batch jobs to carry out IAM functions. Again we have the problem with an overly permissive role.
The other problem with this approach is that you can’t even use a role that requires MFA on a compute resource. I explained that in more detail in earlier posts. So there’s no point to this particular restriction for our IAM administrators.

Only allow the PassRole privilege with a Permission Boundary condition

Perhaps we want to allow a user to create IAM roles and policies, but we want to limit the permissions that user can assign to a compute resource to a subset of AWS permissions. This is where a Permissions Boundary will help.

Let’s say we want a developer to be able to fire up an EC2 instance that has permission to send logs to a specific AWS CloudWatch location or modify files in a specific S3 bucket. However, the user is a security-conscious developer who wants to create a role that is fine grained as possible, following security best practices. We want to allow them to do that. However, we don’t want them to be able to add permissions to register or change domain names using Route 53.

We can allow the user to use the PassRole privilege but only if the role has a Permission Boundary assigned to it that limits the permissions in the role assigned to S3 and CloudWatch. The user can create a role with whatever permissions they want. But they will never be able to leverage Route 53 permissions even if they add them to their application role, because those permissions can be denied in the Permissions Boundary.

This method might also work for our IAM users once we get to the point of creating batch jobs with IAM roles. I’ll explain that in more detail later, but we’re not there yet. So right now our IAM administrators have no reason to pass a role. The PassRole function doesn’t help when it comes to an EC2 instance because their role requires MFA.

Deny the PassRole privilege

Now let’s say we want users to assign roles to their applications to perform actions so they need to be able to perform a Pass Role function for development and testing purposes. That’s possibly fine in a development environment. However, when we get to production, does any user need the PassRole privilege? Maybe not. Hold that thought.

At the moment, we want to restrict our AWS IAM administrators from leveraging PassRole to assign a role to a resource that might have permission to operate in the domains account we created previously where we host all our domain names.

To completely prevent any problems with PassRole for the moment, we can remove the Pass Role privilege and add it back in when required, with limitations to use it only in specific accounts and with roles that have Permission Boundaries limiting unwanted actions.

Next, check out privilege escalation by way of creating a new user.

Backdoors and Privilege Escalation Via Cloud Account Users

ACM.134 Preventing a user from leveraging another user with permissions they don’t have