feat(aws): add iam check for passrole without condition

[Oluwatobi-Mustapha]

Context

This PR addresses a critical privilege escalation vector often referred to as Shadow Admin.

When an IAM policy allows iam:PassRole on all resources (*) without any Condition (such as iam:PassedToService), it allows a user to pass highly privileged roles to compute services (like EC2 or Lambda). An attacker can exploit this to launch an instance with an Administrator role, log into that instance, and effectively take over the AWS account.

This check ensures strict validation of iam:PassRole permissions to align with the principle of least privilege and AWS security best practices.

Description

I have added a new check iam_policy_allows_passrole_without_condition to the IAM service.

Changes:

• New Check Logic: This check evaluates customer-managed IAM policies only (excluding inline and AWS-managed policies) and flags any policy that allows iam:PassRole on * resources when the Condition block is missing.

• Robustness: The logic explicitly checks for the condition key in a case-insensitive manner (Condition or condition) to prevent false positives/negatives due to JSON formatting.

• Metadata: Assigned High severity and mapped to NIST 800-53 (AC-6) standards.

• Unit Tests: Added comprehensive unit tests using unittest.mock to verify detection of "Toxic" policies (FAIL) and "Safe" policies (PASS). Note: Used direct object injection in tests to ensure reliability independent of moto limitations regarding condition keys.

Steps to review

Unit Testing: Run the included unit test to verify logic:

pytest tests/providers/aws/services/iam/iam_policy_allows_passrole_without_condition/iam_policy_allows_passrole_without_condition_test.py

Manual Verification:

1. Create a customer-managed IAM policy that allowsiam:PassRole on * without any condition (e.g., missing iam:PassedToService).

Example of a failing (toxic) policy:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

2. Run Prowler targeting this check:

prowler aws --checks iam_policy_allows_passrole_without_condition

3. Expected result:
   The check reports a FAIL, identifying the offending policy and confirming the absence of restrictive conditions on iam:PassRole.

• Visual proof:

Quick Security notes: I deleted the vulnerable policy immediately after confirming the tool worked.

4. Verification of Safe Policy (False Positive Check):

• Create a customer-managed policy that allows iam:PassRole on * BUT includes a valid condition.

Example of a safe policy:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

• Run Prowler again.

prowler aws --checks iam_policy_allows_passrole_without_condition

Expected result: The check should PASS, confirming that policies with proper conditions are not flagged. This safe policy restricts iam:PassRole to EC2 only.

• Visual proof:

Checklist

Community Checklist

• This feature/issue is listed here or on roadmap.prowler.com
• Is it assigned to me? If not, request it via the issue/feature here or Prowler Community Slack

• Review if the code is being covered by tests.
• Review if code is being documented following this specification.
• Review if backport is needed.
• Review if it is needed to change the configuration.
• Ensure new entries are added to the changelog, if applicable.

—

SDK / CLI

• Are there new checks included in this PR? Yes
• If so, do we need to update permissions for the provider? No

—

UI

• All issue/task requirements work as expected on the UI
• Screenshots/Video of the functionality flow (if applicable) – Mobile (X < 640px)
• Screenshots/Video of the functionality flow (if applicable) – Tablet (640px ≤ X < 1024px)
• Screenshots/Video of the functionality flow (if applicable) – Desktop (X ≥ 1024px)
• Ensure new entries are added to the changelog, if applicable.

—

API

• All issue/task requirements work as expected on the API
• Endpoint response output (if applicable)
• EXPLAIN ANALYZE output for new/modified queries or indexes (if applicable)
• Performance test results (if applicable)
• Any other relevant evidence of the implementation (if applicable)
• Verify if API specs need to be regenerated.
• Check if version updates are required (e.g., specs, Poetry, etc.).
• Ensure new entries are added to the changelog, if applicable.

—

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

✅ Conflict Markers Resolved

All conflict markers have been successfully resolved in this pull request.

[danibarranqueroo]

Thanks for contributing to Prowler! We'll review your PR as soon as we can 💯

[danibarranqueroo]

Hello again, I've reviewed this with the team and we think that we shouldn't merge this check.

Standalone iam:PassRole was previously detected by our privilege escalation checks but was intentionally removed in #8530 due to false positives it generated.

The rationale from that PR:

iam:PassRole is flagged as risky but shouldn't be, as it requires additional execution permissions to be exploitable. PassRole alone is not a privilege escalation, it needs to be combined with actions like ec2:RunInstances, lambda:CreateFunction, etc. to actually be exploitable.

Our existing iam_policy_allows_privilege_escalation check already detect dangerous PassRole combinations and we plan to add more combinations to that check.

Re-introducing standalone PassRole detection would bring back the same false positive issues we fixed. Hope you understand this and thanks for dedicating time to create this check!

[Oluwatobi-Mustapha]

Subject: Re: Context on #8530 and False Positives

Thanks for the detailed context.
The false positives makes perfect sense and I agree that PassRole without the execution primitive (like RunInstances) isn't an immediate exploit path.

I’d love to help improve the existing iam_policy_allows_privilege_escalation check instead. Since I’ve already written the logic to parse PassRole conditions and statements, are there specific service combinations (beyond EC2/Lambda) you are currently looking to add to that check?

I can refactor this PR (or open a new one) to focus on adding those missing combinations to the existing check if that aligns better with the roadmap.