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
核心原则
- 策略文件优先 — 拿到 IAM Policy / 源代码 / CloudFormation 模板时，第一时间分析，不要先盲目枚举
- 从策略推导攻击面 — 策略告诉你"允许什么"，攻击面就在"允许范围的边界"
- Principal 是入口 —
"Principal": "*"意味着跨账户/匿名访问，是最高优先级检查项 - Condition 可能被绕过 —
StringLike通配符在不同协议/上下文中含义不同 - 信任关系 > 单个权限 — 关注服务之间的信任链（谁能调用谁、谁能传递角色给谁）
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 绕过
json// StringLike 通配符 — 不同上下文含义不同 "Condition": {"StringLike": {"sns:Endpoint": "*@company.com"}} // email 协议: Endpoint = 邮箱 → 必须是 xxx@company.com // 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 服务端点发现
bash# 从目标页面提取 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: 常用辅助工具
bash# 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 安全基线检查
⚠️ 避免的错误
- 不要盲目枚举 — 连续 3 次 AccessDenied/404 后应停下来重新分析策略
- 不要忽略附件 — 附件中的策略文件包含了解题所需的全部信息
- 不要假设固定攻击链 — 每个场景的服务组合和漏洞点不同，从策略分析出发而非套模板
- 不要忽略 Condition 字段 — 很多看似安全的策略，其 Condition 可被绕过
