False Positives for iam_role_cross_service_confused_deputy_prevention AWS ec2.amazonaws.com

[D592]

Steps to Reproduce

prowler aws -M csv html json --quiet --filter-region us-east-1 us-west-2 eu-central-1 --severity critical high medium
the roles in AWS account with Trusted entities like that:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            }
            "Action": "sts:AssumeRole",
        }
    ]
}

Expected behavior

pass and do not report "IAM Service Role INSIN does not prevent against a cross-service confused deputy attack"

Actual Result with Screenshots or Logs

prowler-aws-iam_role_cross_service_confused_deputy_prevention-123123123123-us-east-1-*** | aws | iam_role_cross_service_confused_deputy_prevention | Ensure IAM Service Roles prevents against a cross-service confused deputy attack |   | FAIL | IAM Service Role *** does not prevent against a cross-service confused deputy attack | iam |   | high | AwsIamRole |    | Ensure IAM Service Roles prevents against a cross-service confused deputy attack | Allow attackers to gain unauthorized access to resources |   | Use the aws:SourceArn and aws:SourceAccount global condition context keys in trust relationship policies to limit the permissions that a service has to a specific resource | https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention |   |   |   |   | ENS-RD2022: op.exp.8.r4.aws.ct.8 | trustboundaries |   |   | CAF Security Epic: IAM 

How did you install Prowler?

Cloning the repository from github.com (git clone)

Environment Resource

Docker container

OS used

Amazon Linux

Prowler version

Prowler 3.9.0

Pip version

pip 22.0.2

Context

The aws:SourceArn and aws:SourceAccount global condition context keys do not suit for the role Trusted entities. The instance profile needs to be 'assigned' to the EC2 instance. Then only the EC2 service will assume this role on behalf of that instance.
Also -the only condition:

"Condition": {
				"StringEquals": {
					"sts:RoleSessionName": [
						"i-xxxxxxxxxxxxxxx"
					]
				}

make sense there. That's not prevent the role assuming to instance but the permissions won't work. Anyway it's not linked with "prevent against a cross-service confused deputy attack". Service such as Lambda, API gateway, EC2 and Backup service doesn't support aws:SourceAccount and aws:SourceArn condition keys in their role trust policy as per their service documentation. Implementing these conditions will result in access issues

[n4ch04]

Hi @D592, interesting ...
We are gonna tackle this and reach you when we have something.

[n4ch04]

@D592 But according to that information, what do you propose ? The role session name changes every time the role is assumed, so it is not a valid, fixed condition option

[D592]

I propose do not trigger the check for AWS services: Lambda, API gateway, EC2, Backup, Glue

…

On Thu, Sep 7, 2023 at 10:33 AM Nacho Rivera ***@***.***> wrote: @D592 <https://github.com/D592> But according to that information, what do you propose ? The role session name changes every time the role is assumed, so it is not a valid, fixed condition option — Reply to this email directly, view it on GitHub <#2810 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUE4PIRK35SKBZ4NVUK7BTDXZF2FZANCNFSM6AAAAAA4LSUNC4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hauboldj]

From the AWS documentation here:

For non-service-linked role trust policies, every service in the trust policy has performed the iam:PassRole action to verify that the role is in the same account as the calling service. As a result, using aws:SourceAccount with those trust policies is not necessary. Using aws:SourceArn in a trust policy allows you to specify resources a role can be assumed on behalf of, such as a Lambda function ARN. Some AWS services use aws:SourceAccount and aws:SourceArn in trust policies for newly created roles, but using the keys isn't required for existing roles in your account. (emphasis mine)

IAM roles cannot be passed cross account. IAM:PassRole does not allow this. That is to say you cannot instruct a service to use a role in a different account.

[D592]

OK it's correct for non-service-linked roles
but the role with trust police like below is service role - however aws:SourceArn and aws:SourceAccount condition do not make sense here. The same is true for API gateway, Backup, Glue and other services.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
}
"Action": "sts:AssumeRole",
}
]
}

[hauboldj]

From the documentation on service linked roles.

Remember that service roles are different from service-linked roles. A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see Creating a role to delegate permissions to an AWS service in the IAM User Guide. A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.

We are talking about service roles (aka non-service-linked roles) not service-linked roles.

[D592]

OK - my point is true for trust entities of the service roles
According for AWS Support:
There is no public documentation which lists all the services which supports the aws:SourceAccount and aws:SourceArn condition keys.
Amazon Sagemaker - It is recommended to use the aws:SourceArn and aws:SourceAccount global condition keys in resource policies to limit the permissions to the resource that Amazon SageMaker gives another service.
Amazon Data Lifecycle Manager also supports the aws:SourceAccount and aws:SourceArn global condition keys in the trust policy.
Amazon Redshift also supports the aws:SourceAccount and aws:SourceArn global condition keys in the trust policy
Amazon EC2 , API gateway, Backup , Glue do not support aws:SourceAccount and aws:SourceArn condition keys in the trust policy.
Also tested by me:
Amazon Lambda supports aws:SourceArn global condition key in the trust policy

I'd like to ask update the Prowler's check.

[sergargar]

so @D592 you would execute the check only for specific service roles and not apply it to all the services?

[Holz-Dumpf]

OK - my point is true for trust entities of the service roles According for AWS Support: There is no public documentation which lists all the services which supports the aws:SourceAccount and aws:SourceArn condition keys. Amazon Sagemaker - It is recommended to use the aws:SourceArn and aws:SourceAccount global condition keys in resource policies to limit the permissions to the resource that Amazon SageMaker gives another service. Amazon Data Lifecycle Manager also supports the aws:SourceAccount and aws:SourceArn global condition keys in the trust policy. Amazon Redshift also supports the aws:SourceAccount and aws:SourceArn global condition keys in the trust policy Amazon EC2 , API gateway, Backup , Glue do not support aws:SourceAccount and aws:SourceArn condition keys in the trust policy. Also tested by me: Amazon Lambda supports aws:SourceArn global condition key in the trust policy

I'd like to ask update the Prowler's check.

Do you mind including an actual screenshot of the AWS support response (obv blank out identifying/sensitive information). This is pretty important for me to confirm with a similar issue I am having. Just looking for the exact wording they used when they stated which services 'do not support' this.

[D592]

References :

[1] https://docs.aws.amazon.com/sagemaker/latest/dg/security-confused-deputy-prevention.html
[2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/service-role.html#custom-role
[3] https://docs.aws.amazon.com/machine-learning/latest/dg/redshift-parameters.html
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html
[5] https://repost.aws/knowledge-center/iam-role-chaining-limit

[D592]

Despite the fact that it is stated that the Lambda service doesn't support aws:SourceAccount and aws:SourceArn condition keys, I have tested the policy, which works."
{

"Version": "2012-10-17",

"Statement": [

    {

        "Effect": "Allow",

        "Principal": {

            "Service": "lambda.amazonaws.com"

        },

        "Action": "sts:AssumeRole",

        "Condition": {

            "StringEquals": {

                "aws:SourceArn": "arn:aws:lambda:us-east-1:123123123:function:MyLovelyLambdaFunction"

            }

        }

    }

]

}

[canhanhan]

Despite the fact that it is stated that the Lambda service doesn't support aws:SourceAccount and aws:SourceArn condition keys, I have tested the policy, which works." {

"Version": "2012-10-17",

"Statement": [

    {

        "Effect": "Allow",

        "Principal": {

            "Service": "lambda.amazonaws.com"

        },

        "Action": "sts:AssumeRole",

        "Condition": {

            "StringEquals": {

                "aws:SourceArn": "arn:aws:lambda:us-east-1:123123123:function:MyLovelyLambdaFunction"

            }

        }

    }

]

}

I've tried this as well. Initially it looked like it worked. I could invoke the Lambda successfully. But I've noticed that I cannot update the VPC configuration of the Lambda anymore. When I try to attach a different SG to the Lambda; I get en error: "Function's execution role doesn't have permission to perform this operation.".

Removing the condition resolves the error. So, I'm guessing AWS Support's statement is right. It's not fully supported - but works for function invocation.

[D592]

I would say that there is a certain logic in such access settings behavior. A role is generated that defines the lambda execution parameters. Changes to network settings are not covered by the policies of this role. To modify network settings, you need to expand the access parameters of this role. Alternatively, you can delete the entire stack and recreate it with new network settings. Thus, I think it works, but in a somewhat unexpected way. AWS Support finds it easier to say 'do not use it' than to explain the internal workings of these access settings.