遗忘的子域名 = 1000 美元 “AWS 入侵” 漏洞赏金遗忘的子域名1000美元AWS入侵漏洞赏金大海捞针猎捕开始每

官网：http://securitytech.cc/

遗忘的子域名 = 1000 美元 “AWS 入侵” 漏洞赏金

大海捞针！

猎捕开始

每个安全研究员都懂那种感觉：盯着一个目标域名，心里想着漏洞会藏在哪里。有时，最具破坏性的发现并不来自主应用程序，而是来自组织被遗忘的数字角落。这就是一个关于通配符子域名如何让我掉进兔子洞，最终拿到整家公司 AWS 基础设施和数百万用户个人数据的故事。

使用 crt.sh 之类的工具进行子域名枚举，可以帮助绘制目标的地图。

第一章：野生的通配符

一切像常规侦察一样开始。对 redacted.com 做子域名枚举，返回的都是常见的东西：www、mail、blog。但随后我注意到了一件有趣的事：*.corp.redacted.com。一个通配符子域名。在安全世界里，通配符就像一条长廊里的未标记门，没试过把手，你永远不知道里面是什么。

我启动了暴力破解工具，喂给它一个精心准备的常见企业服务词表：

jenkins.corp.redacted.com
- gitlab.corp.redacted.com
- jira.corp.redacted.com
- redmine.corp.redacted.com

中奖了。 redmine.corp.redacted.com 返回了 200 OK。

redmine.corp.redacted.com 允许注册功能

第二章：没有锁的门

Redmine —— 一款流行于开发团队的项目管理工具。登录页看起来挺正常，但有个细节：一个“注册”按钮。我心跳加速。内部工具很少允许公众注册。

注册表单有一个有趣的要求：“仅允许 @redacted.com 邮箱地址。” 看起来像个合理的安全措施，对吧？

我输入了一个测试账号：testuser@redacted.com

接下来发生的事情简直违反逻辑。没有邮箱验证。没有管理员审批。就……直接进去了。我已经登录到公司内部项目管理系统。这个认证绕过简单得几乎让人失望——他们检查了邮箱域名，但从未验证邮箱所有权。

用 poc@redacted.com 在 redmine.corp.redacted.com 上创建的 PoC 账号

第三章：掉进兔子洞

Redmine 门户是信息的金矿，但不是你想象中的那种。这里不是马上找到“王冠上的宝石”，而是考验耐心，不断筛查。

几个小时过去，我翻阅了：

过去三年的开发工单
- 包含完整堆栈信息的 Bug 报告
- 部署时间线与服务器配置
- 功能实现的内部讨论

这就像在读某人的日记，只不过这本日记记录的是整个组织的技术秘密。

注册后能看到的功能请求、支持工单等

平台上的内部 Bug 工单和讨论

第四章：第一根针

然后我找到了——第一根针。在几个工单中，开发者在排查认证问题。对话大概是这样：

Dev1: “测试账号无法复现问题”

Dev2: “试试这些生产账号：”

user: customer1@redacted.com / pass: Winter2023!
- user: customer2@redacted.com / pass: SecurePass123$

Dev1: “谢谢，现在能复现了”

Bug 工单中出现明文用户名和密码 #1

Bug 工单中出现明文用户名和密码 #2

生产凭证明文暴露！而且是几个月前的工单，从未被清理。

第五章：自动化的启示

手动找凭证虽然有冲击力，但效率太低。Redmine 里有数千条工单、数百个 Wiki 页面、无数评论。我需要更好的方法。于是写了个爬虫。

（省略代码，原文已给出简化版）

爬虫运行一个小时，系统地保存了所有能访问的页面、评论和代码片段。现在我有了一大堆数据需要分析。

第六章：终极之针

开始做模式匹配，先从常见的关键词：

grep -r "password" ./crawled_data/
grep -r "api[_-]?key" ./crawled_data/
grep -r "secret" ./crawled_data/

结果太多，噪音太大。于是我改用特定正则匹配 AWS Key：

grep -rE "AKIA[0-9A-Z]{16}" ./crawled_data/
grep -rE "[0-9a-zA-Z/+=]{40}" ./crawled_data/

果然找到了。埋在某个给开发者调试用的数据库转储页面里：

export AWS_ACCESS_KEY_ID=AKIAIOSFODNNREDACTED
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYREDACTED

我的心脏狂跳。

第七章：王国的钥匙

我小心翼翼地用 AWS CLI 配置：

aws configure set aws_access_key_id AKIA[REDACTED]
aws configure set aws_secret_access_key [REDACTED]
aws sts get-caller-identity

返回结果确认了我的猜测：有效的生产凭证。

第八章：王国揭晓

简单清点了一下：

EC2 实例若干
- S3 存储桶若干
- RDS 数据库若干

真正让我震惊的是 S3 存储桶：里面装满了数百万用户的 KYC 文档、发票、邮件、地址、电话和身份证明——彻底的 PII 宝库。

部分关联的 S3 存储桶列表

负责任的退出

我并没有深入利用，而是：

记录所有发现（截图、笔记）
1. 停止测试，避免任何损害
1. 撰写详细漏洞报告
1. 向公司安全团队负责披露

干草堆里的教训

这次从一个通配符子域到 AWS 基础设施访问的旅程，揭示了几个关键教训：

通配符子域的风险
1. 认证 ≠ 验证
1. 内部工具不等于安全
1. 开发者也是人
1. 秘密不会一直保密
1. 级联效应：小漏洞串联成大灾难

公司的响应

值得称赞的是，公司反应迅速：

1 小时内确认报告
- 4 小时内轮换 AWS 凭证
- 2 天后 Redmine 增加邮箱验证
- 3 天后决定发放 1000 美元赏金（史上最高赏金！）

总结

这不仅仅是找到一根针，而是意识到现代应用中充满了“针”。通配符子域 → 注册绕过 → 明文凭证 → AWS Key → 完全接管。

真正的教训是：每个干草堆里都有针。 问题不是漏洞是否存在，而是谁先找到它。

作为安全研究员，我们的责任是 负责任且合乎道德 地揭示这些漏洞，帮助组织构建更坚固的“干草堆”。

本次研究遵循道德规范，已立即负责任披露。未导出、修改或越权访问任何数据。

遗忘的子域名 = 1000 美元 “AWS 入侵” 漏洞赏金

官网：http://securitytech.cc/