Introduction

Many AWS services often require the use of an IAM role to execute actions on your behalf. For example, when you create a Lambda function, you assign an execution role to it. AWS can generate one for you automatically, and then you define the permissions you want it to have after. Most of the time, that’s the case. However, there are instances when you might choose to associate an existing IAM role. In practice, we often concentrate on which permissions a user is allowed to perform and which are off-limits. But what’s often overlooked are the IAM roles a user has access to. In this article, we’ll delve into the importance of the iam:PassRole permission and how it impacts the security of your AWS environment.

What is IAM:PassRole?

 iam:PassRole is a special permission within IAM that enables you to associate an IAM role with a specific resource. “Passing” a role refers to the process of linking an IAM role to a resource, which in turn dictates the actions the resource can perform on other AWS services. Although PassRole is classified as a WRITE operation, it’s not an action that can be invoked through API/CLI calls. As a result, you can’t directly audit it in CloudTrail.

Escalation of Privilege attack

An escalation of privilege attack is when someone figures out how to “level up” their access and get into things they’re not supposed to. In AWS, iam:PassRole is one of the attack vectors an attacker can exploit to be able to do more than they should have. To explain this concept, consider the following scenario.

Sample Scenario

Let’s say your company has an AWS account with numerous IAM roles. One of those roles, named “ParameterStoreAccessRole”, has permission to read sensitive data, such as passwords, from the SSM Parameter store. This role is currently being used by a production application to securely access the required credentials. Although your personal IAM user does not have direct access to the SSM Parameter store, you may still be able to access the passwords using that role. 

Imagine the following policy is attached to your IAM user:

{
    “Version”: “2012-10-17”,
    “Statement”: [{
        “Effect”: “Allow”,
        “Action”: “iam:PassRole”,
        “Resource”: “*”
    }] }

This IAM policy allows you to pass any IAM role to AWS services, creating a security hole that you can exploit to elevate your access. If you have sufficient permissions to launch a new Lambda function, you could assign the “ParameterStoreAccessRole” as its execution role. This would grant the Lambda function the ability to read passwords from the SSM parameter store. As a result, even if your IAM user doesn’t have permission to access those passwords directly, you could invoke the Lambda function to retrieve the sensitive data.

Conclusion

As they say, security is only as strong as your weakest link. Despite having security measures in place (ex: MFA, encryption), a single misconfiguration can cause everything to topple. IAM:PassRole is one of those IAM nuances you should keep an eye on, especially since they’re quite difficult to audit.

For improved security, I suggest staying away from managed IAM policies with overly broad permissions and the use of wildcards (*). Instead, explicitly list the specific roles that a user is allowed to pass. While this method may involve a bit more effort, you’re making sure that users are granted only the necessary permissions to carry out their tasks. This minimizes the risk of unauthorized access or unintended privilege escalation.