wgpsec/aws-iam-policy-analysis

AWS IAM / Resource Policy 分析方法论

拿到 AWS 策略文件（IAM Policy、Resource Policy、Lambda 代码等）后的系统化分析方法。核心目标：从策略中推导攻击面，而非盲目枚举。

⛔ 深入参考（必读）

• S3 策略分析 + 常见漏洞模式 → references/s3-attack-techniques.md
• Lambda/API Gateway/SNS 资源策略漏洞模式 → references/aws-resource-policy-exploits.md

---

核心原则

1. 策略文件优先 — 拿到 IAM Policy / 源代码 / CloudFormation 模板时，第一时间分析，不要先盲目枚举
2. 从策略推导攻击面 — 策略告诉你"允许什么"，攻击面就在"允许范围的边界"
3. Principal 是入口 — "Principal": "*" 意味着跨账户/匿名访问，是最高优先级检查项
4. Condition 可能被绕过 — StringLike 通配符在不同协议/上下文中含义不同
5. 信任关系 > 单个权限 — 关注服务之间的信任链（谁能调用谁、谁能传递角色给谁）

---

Step 1: 策略文件快速分类

拿到附件/下载的文件后，先分类：

| 文件类型 | 识别方式 | 关注点 | |---------|---------|--------| | IAM Policy | "Version": "2012-10-17", "Statement" | Action/Resource 范围 | | Resource Policy | 同上，但有 Principal 字段 | 谁能访问、条件限制 | | Lambda 代码 | .py/.js 文件，handler(event, context) | 输入处理、路径拼接、注入点 | | CloudFormation | AWSTemplateFormatVersion, Resources | 完整架构、角色绑定 | | Trust Policy | "Action": "sts:AssumeRole" | 角色可被谁 assume |

---

Step 2: IAM Policy 危险模式识别

2.1 检查 Principal

🔴 "Principal": "*"              → 任何 AWS 身份（含匿名）可访问
🔴 "Principal": {"AWS": "*"}     → 同上
🟡 "Principal": {"Service": "lambda.amazonaws.com"}  → 特定服务可调用
🟢 "Principal": {"AWS": "arn:aws:iam::123456:root"}  → 限定账户

2.2 检查 Action 范围

| Action 模式 | 风险 | |------------|------| | "Action": "*" | 🔴 完全控制 | | "Action": "s3:*" | 🔴 S3 完全控制 | | "Action": ["s3:GetObject", "s3:PutObject"] | 🟡 可读可写 | | "Action": "s3:GetObject" on "Resource": "*" | 🟡 可读所有 Bucket | | "Action": "sts:AssumeRole" | 🟡 可切换角色（权限提升入口） | | "Action": "iam:PassRole" | 🟡 可传递角色（间接提权） | | "Action": "lambda:InvokeFunction" with Principal:* | 🔴 任何人可调用 Lambda |

2.3 检查 Resource 范围

🔴 "Resource": "*"                          → 所有资源
🟡 "Resource": "arn:aws:s3:::bucket/*"      → bucket 内所有对象
🟢 "Resource": "arn:aws:s3:::bucket/public/*" → 仅 public 前缀

2.4 检查 Condition 绕过

// StringLike 通配符 — 不同上下文含义不同
"Condition": {"StringLike": {"sns:Endpoint": "*@company.com"}}
// email 协议: Endpoint = 邮箱 → 必须是 [email protected]
// https 协议: Endpoint = URL → URL 中包含 @company.com 即可绕过

// IpAddress 条件 — 可能有 VPN/代理绕过
"Condition": {"IpAddress": {"aws:SourceIp": "10.0.0.0/8"}}

// StringEquals vs StringLike — 前者精确匹配，后者支持通配符

---

Step 3: 服务信任关系图推导

从策略文件中画出"谁信任谁"的调用关系：

读取所有策略文件
    ↓
识别所有 Principal（谁是调用者）
    ↓
识别所有 Resource（谁被访问）
    ↓
连线: Principal → Action → Resource
    ↓
找到最弱一环（Principal:* 或过宽权限的边）

常见服务关系：

• API Gateway → Lambda（API GW 触发 Lambda）
• Lambda → S3/DynamoDB/SNS（Lambda 执行角色权限）
• SNS → Lambda/SQS/HTTP（消息推送目标）
• IAM User → AssumeRole → 高权限角色

关键: 分析 Lambda Execution Role 的权限 — 这决定了 Lambda 能访问什么资源。

---

Step 4: Lambda / 应用代码审计

拿到 Lambda 代码（handler.py/index.js）后重点检查：

| 漏洞类型 | 代码模式 | 利用方式 | |---------|---------|---------| | 路径穿越 | os.path.join(prefix, user_input) | 绝对路径绕过：/flag | | 命令注入 | os.system(f"cmd {user_input}") | ; cat /flag | | SSRF | requests.get(user_input) | http://169.254.169.254/... | | 环境变量泄露 | os.environ['SECRET'] | 错误信息/Stack Trace | | SQL 注入 | 字符串拼接 SQL | ' OR 1=1 -- | | 反序列化 | pickle.loads()/yaml.load() | 构造恶意对象 |

---

Step 5: AWS 服务端点发现

# 从目标页面提取 AWS 相关 URL
curl -s TARGET_URL | grep -oE 'https?://[a-z0-9.-]+\.amazonaws\.com[^"]*'
curl -s TARGET_URL | grep -oE 'https?://[a-z0-9]+\.execute-api\.[a-z0-9-]+\.amazonaws\.com[^"]*'

# 从 JS/HTML 中提取 S3 Bucket、API GW URL
curl -s TARGET_URL | grep -oE 's3\.amazonaws\.com/[^"]*'

# Presigned URL 信息泄露
# X-Amz-Credential 包含 AccessKeyId 和 Region

---

Step 6: 常用辅助工具

# webhook.site — 接收 AWS 服务回调（SNS、S3 Event 等）
# 当需要外部 Endpoint 接收 AWS 推送时使用

# AWS CLI 策略检查
aws iam get-policy-version --policy-arn ARN --version-id v1
aws s3api get-bucket-policy --bucket BUCKET
aws lambda get-policy --function-name FUNC

# ScoutSuite — AWS 安全配置审计
# Prowler — AWS 安全基线检查

---

⚠️ 避免的错误

1. 不要盲目枚举 — 连续 3 次 AccessDenied/404 后应停下来重新分析策略
2. 不要忽略附件 — 附件中的策略文件包含了解题所需的全部信息
3. 不要假设固定攻击链 — 每个场景的服务组合和漏洞点不同，从策略分析出发而非套模板
4. 不要忽略 Condition 字段 — 很多看似安全的策略，其 Condition 可被绕过