IAM Policy Crafting Masterclass: Preventing Privilege Escalation and Wildcard Misuse

In the realm of AWS, Identity and Access Management (IAM) policies are fundamental to securing your cloud environment. Properly crafted IAM policies ensure that users and services have only the permissions they need, adhering to the principle of least privilege. However, misconfigurations, especially those leading to privilege escalation and improper use of wildcards, can introduce significant security vulnerabilities. This guide delves into best practices for crafting IAM policies that mitigate these risks.​

Understanding Privilege Escalation

Privilege escalation occurs when an entity gains higher access rights than intended, potentially leading to unauthorized actions within your AWS environment. This can happen due to overly permissive policies or misconfigurations. To prevent this, it's crucial to implement the principle of least privilege, granting only the permissions necessary for a task. Regularly reviewing and refining IAM policies helps in identifying and mitigating unintended access. ​

Best Practices to Prevent Privilege Escalation

1. Implement Permission Guardrails: Use permission boundaries and service control policies (SCPs) to define the maximum permissions an IAM entity can have. This ensures that even if an identity-based policy grants broader permissions, the entity cannot exceed the defined boundary. ​

2. Restrict IAM PassRole Permissions: The iam:PassRole permission allows an entity to delegate permissions to AWS services. Misuse can lead to privilege escalation if not properly restricted. Limit this permission to only the roles that an entity truly needs to pass.

3. Utilize IAM Access Analyzer: This tool helps in identifying and rectifying policies that grant unintended access. Regularly analyze your policies to ensure they adhere to best practices and do not open avenues for privilege escalation.

---

Let's understand with example scenario:

1. Applying Permission Guardrails with Permissions Boundaries

Use case: In a development environment, developers must have the ability to create IAM roles for their applications to perform limited actions on S3 and EC2 services. However, it's critical to ensure they don't assign overly permissive policies that could lead to privilege escalation.

Without any restrictions, a developer might create a role and attach the AdministratorAccess policy, either accidentally or intentionally, giving full access to AWS resources. Such over-permissioning presents serious security risks.

Mitigation with Permissions Boundaries:

By setting up a permissions boundary, you can define the maximum set of permissions a developer's created roles can have—limited only to S3 and EC2 activities—and block sensitive actions like deleting or terminating resources, no matter what policies are attached. This ensures that even if a developer tries to assign excessive permissions, they’ll still be governed by the boundary.

Setup Code Sample:

Step 1: Create a Permissions Boundary Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitToSpecificServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",                 // Allows S3 actions
                "ec2:Describe*"          // Allows describing EC2 resources
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenySensitiveActions",
            "Effect": "Deny",
            "Action": [
                "s3:DeleteBucket",       // Deny bucket deletion
                "ec2:Terminate*"         // Deny EC2 termination
            ],
            "Resource": "*"
        }
    ]
}

Save this policy as DevPermissionsBoundary and attach it to the IAM users or roles responsible for creating new roles.

Step 2: Create a Role with the Permissions Boundary

aws iam create-role \
  --role-name DevAppRole \
  --assume-role-policy-document file://trust-policy.json \
  --permissions-boundary arn:aws:iam::123456789012:policy/DevPermissionsBoundary

This command creates a role named DevAppRole with the specified boundary, ensuring its permissions cannot exceed what’s allowed by DevPermissionsBoundary.

---

2. Limiting iam:PassRole Permissions

Use case: An application needs the ability to launch EC2 instances and attach specific IAM roles required for its operation.

Exploitation Without Restriction:

If a user has unrestricted iam:PassRole and ec2:RunInstances permissions, they could launch EC2 instances using any IAM role, even one with administrative privileges. Through the instance metadata, they could then access temporary credentials for these high-privilege roles—leading to privilege escalation.

Mitigation by Restricting iam:PassRole:

By clearly specifying which roles users are allowed to pass, you can prevent them from assigning unauthorized roles to EC2 instances. This ensures they can only work with roles appropriate for their tasks, reducing security risks.

Setup Code Sample:

IAM Policy to Restrict iam:PassRole

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/EC2AppRole"
    },
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*"
    }
  ]
}

This policy allows the user to pass only the EC2AppRole role when launching EC2 instances, blocking them from assigning other roles with elevated privileges.

---

The Risks of Wildcard (*) Usage

Using wildcards in IAM policies can simplify configurations but often at the cost of security. For instance, specifying "Resource": "*" grants permissions across all resources, which might be excessive and risky. Similarly, "Action": "*" permits all actions, potentially allowing unintended operations.​

Best Practices to Avoid Wildcard Misuse

1. Specify Explicit Resources and Actions: Define the exact resources and actions required. Instead of using "Resource": "*", specify the ARN of the resource. This minimizes the risk of unintended access. ​

2. Combine Deny Statements with Conditions: If you must use wildcards, combine them with explicit deny statements and conditions to limit their scope. This approach adds an additional layer of security by preventing actions under specific conditions. ​

3. Regular Policy Reviews: Periodically review IAM policies to identify and replace unnecessary wildcards. This ensures that permissions remain tight and aligned with current requirements.

Consider below policy - this is a classic example of wildcard misuse.

 {

  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLimitedActions",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        ],
      "Resource": "*"
    }
  ]
}

Why?

• "s3:*" grants full administrative access to S3, including:

  • s3:DeleteBucket

  • s3:PutBucketPolicy

  • s3:GetObject

  • s3:DeleteObject

• Combined with "Resource": "*", it means any S3 bucket or object in the account is fair game.

Fix:

 {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnlyForSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",                    //Use action-level granularity
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-logs",
        "arn:aws:s3:::my-app-logs/*".     // Scope to specific ARNs
      ]
    }
  ]
}

---

Leveraging AWS Tools for Enhanced Security

• IAM Access Analyzer: Beyond identifying unintended access, IAM Access Analyzer can generate fine-grained policies based on actual usage, aiding in the creation of least privilege policies.

• AWS Security Hub: Provides a comprehensive view of your security posture, highlighting deviations from best practices and offering actionable insights. ​

Conclusion

Crafting secure IAM policies is a continuous process that demands attention to detail and an understanding of AWS's security tools and best practices. By preventing privilege escalation and avoiding the misuse of wildcards, you fortify your AWS environment against unauthorized access and potential breaches. Regularly leveraging AWS's suite of security tools will further enhance your cloud security posture.​