【实战日记】从一个 S3 目录遍历，到顺藤摸瓜拿下某海外大厂内部生产权限

0x01 故事背景

最近在对某全球知名酒店集团（下称 Target 集团）进行资产测绘时，我发现了一个非常典型的“云存储配置错误”案例。这不仅仅是一个简单的泄露，它更像是一张多米诺骨牌，推倒后直接暴露出该集团移动端的生产环境、第三方合作凭证、甚至是安全防御的底牌。

今天，就带大家沉浸式还原这起“从 0 到 1”的渗透全过程。

0x02 信息收集

故事的开始，源于对 Target 集团 API 网关的一次常规探测。

资产定位：apcgateway.example-corp.com（该集团的核心 API 接入点）。

我的浏览器插件立刻报警了

一个名为 /mobile/ 的路径引起了我的注意。通常，这种路径是为移动端 App 提供静态资源或配置文件的。我习惯性地随手输入：

GET /mobile/ HTTP/1.1

本以为会收到一个 403 Forbidden 或者 404，但当按下回车键的那一刻，我的屏幕被一大串 XML 数据填满了

S3 存储桶目录列表公开可访问！

通过插件提醒，我确认这是一个名为 mi-mobilefileconfig-prod 的 Amazon S3 存储桶。由于运维配置了 ListBucket 权限，桶内的所有“家底”都毫无保留地呈现在我眼前。

0x03 漏洞利用

既然大门敞开，我开始逐一审计这些文件。每一个文件名都散发着“生产环境”的味道。

1. 深入敌后：挖掘内部基础设施地址

首先引起我注意的是 mobileconfig.json。下载并打开它，我仿佛拿到了对方内部网络的地图：

// mobileconfig.json 关键片段
{
  "internal_gateway": "gatewaydsapprd.example-corp.com", // 生产环境 API 网关
  "cache_server": "cache.example-corp.com",             // 内容缓存服务器
  "environment": "production"
}

逻辑转换瞬间：
通常这些地址是不会对公网暴露的。但我尝试直接访问 gatewaydsapprd.example-corp.com/mobile/，惊喜地发现：这个内部网关竟然同样可以直接从公网访问。这意味着我可以绕过外部网关的某些 WAF 规则，直接与内部业务逻辑对话！

2. 第三方令牌泄露：横向攻击的跳板

紧接着，我打开了 mobilecontent.json。这里简直是“惊喜盲盒”：

Sixt 租车 B2B 合作伙伴令牌：
发现一个 b2b_token=4b11c5e4-xxxx-xxxx-xxxx-xxxxxxxxxxxx。利用这个令牌，攻击者可以直接进入该集团与 Sixt 合作的免密注册通道。
AwardHQ 礼品卡认证令牌：
一段 Base64 加密的令牌字符串，解码后获得：{CCUNWSEQ}993c1a319axxxxxxxxxxxxxxxx。
场景化思考： 拿到这个，我是不是可以随意兑换该集团提供给高级会员的礼品卡？

3. 心理战：通过 Feature Flags 寻找最薄弱点

最让我感到兴奋的是 featureflags_android.json。这份文件记录了 App 各项安全功能的开关状态。

// 关键标志位分析
{
  "MRTMultiFactorAuthenticationFeature": false,  // Android 端 MFA 竟然是关掉的！
  "MRTAkamaiBMPEnabledFeature": true,           // Akamai 机器人保护是开启的
  "MRTHideEnhancedSecuritySwitchFeature": false  // 增强安全开关被隐藏
}

反思： 作为一个攻击者，如果我知道 Android 端的 MFA（多因素认证）是关闭的，而 iOS 端是开启的，那么我会毫不犹豫地选择 Android 端作为暴力破解或撞库的主攻方向。

0x04 漏洞影响

表面上看，这只是 23 个文件、总计 1.2MB 的泄露。但深入挖掘后的后果却令人毛骨悚然：

资产全暴露： 暴露了包括内部 API 网关、缓存服务器在内的敏感基础设施。
供应链风险： 泄露的第三方令牌足以导致合作伙伴的利益受损，甚至引发更广泛的供应链攻击。
安全屏障失效： 密码复杂度规则（password_complexity_rules.json）和 Feature Flags 的泄露，让攻击者可以“有针对性”地构造 Payload，避开 Akamai WAF 的锋芒。

0x05 防御与反思

作为一名开发者或运维，如何避免这种“低级但致命”的错误？

Root Cause 分析：
该漏洞的根源在于 S3 存储桶策略（Bucket Policy）和访问控制列表（ACL）的权限划分过于模糊。运维人员可能为了方便测试，开启了 ListBucket 权限，但在上线生产环境时忘记关闭。

加固建议：

最小权限原则： 立即关闭 S3 的 ListBucket 和公开 GetObject 权限。应使用 CloudFront + OAI (Origin Access Identity) 来分发静态资源，而不是直接暴露存储桶。
敏感信息脱敏： 永远不要在前端配置文件（JSON）中硬编码 Token 或 API 密钥。建议通过动态鉴权的 API 接口按需获取。
灰度与隔离： 测试环境与生产环境的 S3 桶必须严格隔离。
持续监控： 建议接入 AWS Config 或类似的云安全扫描工具，一旦检测到 Bucket 权限变更为 Public，立即触发自动化修复。

结语

这次渗透让我再次感受到，安全是一个整体，任何一个微小的配置疏忽，都可能导致整座堡垒从内部崩塌。

作为研究员，我们要做的不仅是发现漏洞，更是通过这些漏洞去推动企业构建更安全的架构。希望这篇文章能给正在学习云安全的小伙伴们一点启发！

Stay Humble, Stay Hungry. 我们下个漏洞见！