Article by Nick Frichette

Abusing Misconfigured Role Trust Policies with a Wildcard Principal

As penetration testers and red teamers we often take advantage of misconfigurations to exploit cloud environments. These are mistakes made by developers and DevOps engineers that make applications and services vulnerable to attack. In this article we will explore one of the more egregious mistakes that can be made in an AWS environment; setting a wildcard as a Principal in a role trust policy.

Role Trust Policies¶

As stated in the AWS documentation, a role trust policy is, "A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM".

This policy typically looks like the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

This policy would Allow anyone in the 111111111111 account the ability to perform the action sts:AssumeRole (assume the role), provided that they have the action in their IAM identity-based policy.

As mentioned in our documentation on Misconfigured Resource Based Policies, there are a variety of options that can be used for the Principal element, including, AWS accounts, specific IAM roles, role sessions, IAM users, and AWS services. Arguably the most risky is the "wildcard" Principal. This Principal encompasses ALL AWS principals.

If a role trust policy is configured with a wildcard Principal element, such as the one shown below, anyone in the world can assume the role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

It's worth noting that, while the simplest version of this misconfiguration can be easy to spot, more complex versions you will see in the wild may not be. Take the following policy for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnNotEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::555555555555:role/intent-allow-role"
                }
            }
        }
    ]
}

In this example, the intention was to create a policy that Denied all Principals except the intent-allow-role. However, while creating this policy, the Effect was mistakenly changed to an Allow, which had the opposite effect, now anyone except intent-allow-role can assume the role.

These types of more complicated role trust policies may slip through some CSPM/CNAPP solutions which don't thoroughly model all IAM policies. Be on the lookout for these types of mistakes on your next assessment!

How to Exploit¶

In order to exploit a role that has a wildcard set as a Principal, you simply invoke sts:AssumeRole from an attacker controlled AWS account. Any AWS account, including those outside of the victim's AWS Organization, will work.

aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/victim-role \
--role-session-name blahsessionname