aws-iam-policy-analysis

name	aws-iam-policy-analysis
description	AWS IAM / Resource Policy 分析方法论。当目标涉及 AWS 云服务且提供了 IAM Policy、Resource Policy、Lambda 代码、CloudFormation 模板等策略文件时使用。覆盖 IAM Policy 危险模式识别、Resource Policy Principal 分析、Condition 键绕过模式、服务信任关系图推导。发现 AWS 策略文件（json/yaml）、*.amazonaws.com 端点、IAM ARN 时应使用此技能
metadata	{"tags":"aws,iam,policy,cloud,resource-policy,principal,condition,trust,策略分析,权限分析","category":"cloud"}

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 = 邮箱 → 必须是 [e-mail]
// 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 可被绕过