Wildcard Resources on Data-Exfiltration IAM Actions

High Risk infrastructure-security
awsterraformiamdata-exfiltrationprivilege-escalationwildcard-permissionsleast-privilege

What it is

IAM policies grant data-exfiltration actions (s3:GetObject, ssm:GetParameter, secretsmanager:GetSecretValue, rds:*Snapshot) with wildcard resource permissions, allowing principals to read sensitive data from unintended resources and enabling unauthorized data access and privilege escalation.

# VULNERABLE: IAM policy with wildcard resources

resource "aws_iam_role_policy" "overprivileged_data_access" {
  name = "application-data-access"
  role = aws_iam_role.application_role.id
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:ListBucket"
        ]
        Resource = "*"  # VULNERABLE: Can access ALL S3 buckets
      },
      {
        Effect = "Allow"
        Action = [
          "ssm:GetParameter",
          "ssm:GetParameters"
        ]
        Resource = "*"  # VULNERABLE: Can read ALL SSM parameters
      },
      {
        Effect = "Allow"
        Action = [
          "secretsmanager:GetSecretValue"
        ]
        Resource = "*"  # VULNERABLE: Can access ALL secrets
      },
      {
        Effect = "Allow"
        Action = [
          "dynamodb:GetItem",
          "dynamodb:Query"
        ]
        Resource = "*"  # VULNERABLE: Can access ANY DynamoDB table
      }
    ]
  })
}
# SECURE: IAM policy with specific resource ARNs

resource "aws_iam_role_policy" "secure_data_access" {
  name = "application-secure-data-access"
  role = aws_iam_role.application_role.id
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowSpecificS3Access"
        Effect = "Allow"
        Action = ["s3:GetObject", "s3:ListBucket"]
        Resource = [
          "${aws_s3_bucket.application_data.arn}/*",
          aws_s3_bucket.application_data.arn
        ]
        Condition = {
          StringEquals = {
            "s3:ExistingObjectTag/Environment" = "production"
          }
        }
      },
      {
        Sid      = "AllowSpecificSSMParameters"
        Effect   = "Allow"
        Action   = ["ssm:GetParameter", "ssm:GetParameters"]
        Resource = [
          "arn:aws:ssm:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:parameter/myapp/*"
        ]
      },
      {
        Sid      = "AllowSpecificSecretsAccess"
        Effect   = "Allow"
        Action   = ["secretsmanager:GetSecretValue"]
        Resource = [
          aws_secretsmanager_secret.app_database_credentials.arn
        ]
      },
      {
        Sid      = "AllowSpecificDynamoDBAccess"
        Effect   = "Allow"
        Action   = ["dynamodb:GetItem", "dynamodb:Query"]
        Resource = [
          aws_dynamodb_table.customer_records.arn,
          "${aws_dynamodb_table.customer_records.arn}/index/*"
        ]
      }
    ]
  })
}

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

💡 Why This Fix Works

The vulnerable configuration grants wildcard resource permissions on data-sensitive IAM actions, allowing access to any S3 bucket, SSM parameter, secret, or RDS snapshot. The secure version restricts access to specific resource ARNs with IAM conditions, implementing least-privilege access and preventing unauthorized data exfiltration.

Why it happens

IAM policies grant data-exfiltration actions like s3:GetObject, secretsmanager:GetSecretValue, and ssm:GetParameter with Resource: '*'. This allows principals to read sensitive data from any resource in the account, violating least-privilege principles.

Root causes

Wildcard Resources for Sensitive Actions

IAM policies grant data-exfiltration actions like s3:GetObject, secretsmanager:GetSecretValue, and ssm:GetParameter with Resource: '*'. This allows principals to read sensitive data from any resource in the account, violating least-privilege principles.

Overprivileged Service Roles

AWS service roles (Lambda, EC2, ECS) granted broad data access permissions across all resources for operational convenience. These roles can access unrelated databases, secrets, and storage beyond their legitimate requirements.

Developer Convenience Over Security

Developers use wildcard resources in IAM policies to avoid determining specific resource ARNs or dealing with permission errors. This convenience pattern creates severe security risks by granting unnecessary broad access.

Missing Resource-Level Restrictions

IAM policy statements lack resource-level ARN restrictions that limit access to specific S3 buckets, DynamoDB tables, or parameter paths. Without Resource arrays containing specific ARNs, policies default to wildcard access.

Excessive Cross-Account Role Permissions

Cross-account IAM roles granted overly broad permissions with wildcard resources enable partner accounts or third-party integrations to access sensitive data beyond intended scope, creating data exfiltration risks.

Fixes

1

Replace Wildcards with Specific ARNs

Replace Resource: '*' with specific ARN patterns for each data access action. For S3, use 'arn:aws:s3:::specific-bucket/*'; for Secrets Manager, use 'arn:aws:secretsmanager:region:account:secret:app-secrets-*'. This limits access to only intended resources.

2

Apply IAM Condition Key Restrictions

Use IAM condition keys to further restrict access beyond resource ARNs. Apply conditions like aws:ResourceTag, aws:PrincipalOrgID, or service-specific conditions (s3:prefix, dynamodb:LeadingKeys) to enforce fine-grained access control.

3

Implement Least-Privilege Resource Permissions

Design IAM policies following least-privilege principles where each statement grants access only to specific resources required for the use case. Audit policies regularly to remove unused resource permissions and tighten ARN patterns.

4

Create Dedicated Service Roles

Deploy separate IAM roles for each service or application component with permissions scoped to their specific data requirements. Eliminate shared roles that accumulate permissions from multiple use cases.

5

Use AWS Access Analyzer

Enable AWS IAM Access Analyzer to continuously scan policies for overprivileged access including wildcard resources on sensitive actions. Configure Access Analyzer findings as automated security alerts for remediation.

6

Implement Tag-Based Access Control

Apply consistent resource tagging across S3 buckets, DynamoDB tables, and other data stores. Use aws:ResourceTag conditions in IAM policies to dynamically scope access based on resource tags like Environment, DataClass, or Application.

Detect This Vulnerability in Your Code

Sourcery automatically identifies wildcard resources on data-exfiltration iam actions and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities