7 Common Pitfalls with IaM Passrole Configurations

When we say Pass, you say Role! Ready? Pass!… Okay, maybe PassRole doesn't inspire quite the same enthusiasm as your favorite sports team, but it doesn't mean it isn't essential. In fact, PassRole is a crucial part of ensuring security on your AWS account.

The number one vulnerability across Microsoft is the escalation of privileges attack - as it has been for the past four years. IAM PassRole helps mitigate this vulnerability within AWS. However, implementing it effectively can be challenging, leaving the door ajar for bad actors to access your sensitive data. In this article, we look at PassRole - how it works, where it falls short, and how to use it securely.

What is IAM Passrole?

Passrole is a nifty permission that allows you to specify whether a user can Pass [a] Role to an instance they create and which roles they can assign. You can pass a role to an instance to interact with other AWS services (e.g., creating a Lambda function that can delete an object in an S3 bucket) or access specific IP addresses. For this purpose, passing a role to an instance is essential.

However, allowing all users to assign whatever roles they want can create a dangerous vector for attack. This type of attack is called escalation of privilege. It will enable an actor with limited permissions to gain extra access to your cloud estate and any sensitive information.

Proper use of Passrole can help mitigate this type of attack. To illustrate how this attack could work and how Passrole helps mitigate it, we've devised an example.

Source

An example of IAM Passrole in action

Imagine there are two people in your AWS account: an administrator and a developer. Your developer wants to be able to create an EC2 instance that automatically sends an email via SES on a timer. Since this seems like a perfectly reasonable thing to do, the administrator grants them permission to create and run EC2 instances, plus the IAM PassRole permission, so that they can allow the Lambda to call SES. So far, so good.

The problem occurs when a hacker comes onto the scene. This hacker got access to the developer's account and permissions and wants to access sensitive data on an S3 bucket to which the developer doesn't currently have access to. Although the hacker can't access the data directly, they can create EC2s and assign whatever roles they want to them. And so, they make an EC2 with AdministratorAccess.

Both the hacker and the developer still can't access the bucket, but the EC2 can. The hacker then logs into the instance and uses the escalated privilege of the EC2's role to access and steal sensitive information. This attack poses a real threat if you allow users to assign whatever role they want to the infrastructure they create. Fortunately, Passrole includes functionality that addresses this.

The Passrole permission includes a Resource field that allows you to specify which roles a user can pass to an instance. Therefore, administrators can grant developers Passrole privileges to make their email-sending instance but only allow them to assign a locked-down role that enables the EC2 to talk to SES and nothing more.

As you can see from this example, using Passrole properly can be incredibly powerful in stopping this attack and enforcing strong Identity Access Management. Unfortunately, the theory is often undercut by some practical quirks and limitations of this permission, making it challenging to implement.

Source

7 Common pitfalls with IAM:Passrole configurations

1. Not logged by CloudTrail

Although IAM PassRole is nestled comfortably in the Actions section of your IAM policies, it is not an API - it is a permission. CloudTrail does not log when PassRole is used to pass a role to an instance. There is no clear paper trail of when and how PassRole is used in your organization, forcing you to read between the lines to infer its use.

2. Lack of monitoring

Having no detailed logs of PassRole invocations can make it a nightmare to configure PassRole accurately. Without the visibility of a log trail, it is more difficult to spot any misconfigurations and potential security issues that have arisen. As a result, overly generous PassRole permissions are, unfortunately, standard.

3. Lack of role documentation

No central dashboard within AWS allows you to see which roles each identity can pass. This is another example of the lack of monitoring tools that make assessing and monitoring your permissions hard.

4. Overprivileged Accounts

Since PassRole is challenging to monitor, it is very common to find accounts with far too many privileges assigned to them. Far from the ideal of Least Privilege, often, accounts are given PassRole permissions with an overly lenient list of roles it can provide.

It is common to see accounts with legacy permissions that still need revocation. An instance moved onto a different task might need completely different PassRole permissions. Still, updating and removing unnecessary permissions once they are given is a pain.

Tools such as Slauth.io's Policy Copilot enable you to create secure machine-based identities automatically. You can enforce the Least Privilege approach without manually adding or revoking permissions.

5. Nested role parameters

When creating an EC2 instance, you do not give it a role directly. Instead, you provide an Instance Profile, which contains the role inside. If you use the console, this is automatically created - it's only when you use the SDK or CLI that you need to create a profile and explicitly attach it to the instance.

Therefore, you need to find these other parameters for certain services to understand which PassRole permissions were given. Such added complexity makes it even harder to manage your PassRole estate and accurately lock down permissions to prevent attacks.

6. Weak IAM policies

Making safe PassRole permissions can take a lot of trial and error. It is a manual process to determine and assign the required roles to each user. There is no in-built way to set permissions and dynamically monitor them automatically.

Slauth.io creates PassRole policies based on the API calls your instances actually make. It determines which policies are required and dynamically assigns the minimum necessary permissions to work.

7. Implicit role passes

In certain situations, AWS will create a service-linked role automatically to perform an action. These service-linked roles will use default permissions if not explicitly stated, which can cause these services to have greater-than-required privileges.

Source

Making IAM Passrole configurations work for you

Despite these common pitfalls that can reduce the security of your AWS organization, PassRole remains a potent tool when used correctly. Success lies in ongoing monitoring, automatic assignment, and least-privilege permissions.

Scanning your IAM configurations automatically can help reduce the risk of overextended permissions being granted to your instances. You should regularly conduct these scans to revoke any unnecessary privileges quickly. Slauth.io Policy Copilot also enables you to assign privileges dynamically to your services, reducing the risk of manual error. These practices help you move to a more secure estate where the principle of Least Privilege is more actively enforced.

Should I Stop Using PassRole?

The short answer is: no. PassRole remains the best way to protect against escalating privilege attacks. However, PassRole should still be handled with care and respected as a tool that can be easily misused and accurately understood. This tool is challenging to monitor, so it can be hard to determine which permissions are required. This lack of visibility often results in overprivileged accounts, where the risk of attack is much greater. If you want to try Slauth.io to analyze and assign PassRole permissions securely, you can sign up for a 30-day free trial here.