-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False Positives for iam_role_cross_service_confused_deputy_prevention AWS ec2.amazonaws.com #2810
Comments
Hi @D592, interesting ... |
@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 |
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:
***@***.***>
|
From the AWS documentation here:
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. |
OK it's correct for non-service-linked roles |
From the documentation on service linked roles.
We are talking about service roles (aka non-service-linked roles) not service-linked roles. |
OK - my point is true for trust entities of the service roles I'd like to ask update the Prowler's check. |
so @D592 you would execute the check only for specific service roles and not apply it to all the services? |
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. |
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."
} |
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. |
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. |
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:
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
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:
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
The text was updated successfully, but these errors were encountered: