作者 | Tillson Galloway
译者 | 核子可乐
策划 | 陈思
Bug 赏金猎人，不用流血牺牲，只需轻敲键盘就可完成赏金任务。这些人通过发现企业的安全漏洞以获得赏金，企业也非常欢迎这样的赏金猎人“找茬”。今天这篇文章主要送给 Bug 赏金猎人以及企业信息安全团队，我们将探讨用户意外发布至公开 GitHub 库内的常见敏感信息（即“秘密”）类型，以及查找这些秘密的启发性方法。
每一天，都有 API 密钥、密码以及客户数据被意外发布到 GitHub 之上。恶意人士当然可以利用这些密钥登录服务器、窃取个人信息，或者给用户带来数额高到不可思议的 AWS 服务成本。GitHub 泄露事故可能令企业蒙受数百甚至数千万美元的损失，而从 GitHub 上收集开源情报也已经成为每一位安全研究者都不能错过的重要信息来源。来自北卡罗来纳大学的研究人员，甚至专门就此撰写了学术论文。
今天这篇文章主要送给 Bug 赏金猎人以及企业信息安全团队，我们将探讨用户意外发布至公开 GitHub 库内的常见敏感信息（即“秘密”）类型，以及查找这些秘密的启发性方法。当然，本文中提到的技术手段也适用于 GitHub Gist 片段。
就在去年，我凭借着这些技巧从 HackerOne（一个对接白帽黑客和企业的平台）上的几个 Bug 赏金计划中轻松拿到了接近 1 万美元的奖励。我还发布了 GitHound这是一款开源 dork，能够自动在 GitHub 上查找不慎外泄的密钥。GitHound 所针对的可不仅仅是单一用户或组织：它能够遍历整个 GitHub，使用代码搜索查询作为项目库的入口点中，而后利用上下文、正则表达式及其他一些巧妙的“歪脑筋”快速批量查找秘密。
GitHub 代码搜索
GitHub 提供丰富的代码搜索功能，可用于扫描公开 GitHub 库（这里忽略 fork 及非默认分支等因素）。查询方式可以简单如 uberinternal.com，也可以包含类似 "Authorization: Bearer"这样的多单词字符串。搜索操作甚至可以指向特定文件（filename: vim_settings.xml）或者特定语言（language:SQL）。另外，搜索也能包含某些布尔限定符，例如 NOT 与 >。
在了解到 GitHub 的代码搜索规则之后，我们就可以设计出搜索 dork，借此实现对敏感信息的查询。大家当然可以从网上寻找现成的程序，但最好的工具永远出自我们自己的双手。
举例来说， filename: vim_settings.xml 指向的就是 IntelliJ 设置文件。有趣的是， vim_settings.xml 文件当中还包含最近刚刚复制 - 粘贴完成的 Base64 编码字符串。凭借着这一发现，我从 Bug 赏金计划中获得了 2400 美元，具体上报形式为：vim_settings.xml 中会暴露 SaaS API 密钥与客户信息。
vim_settings.xml 中只包含最近复制 - 粘贴的字符串，但我们可以利用代码库的提交历史记录来查找完整的复制 - 粘贴历史记录。只需要克隆代码库并运行这份仅为 14 行的脚本，用户的活动就将完全呈现在你的面前。
顺带一提：利用这款 GitHub 提交搜索 dork，我们可以快速扫描曾对 vim_settings.xml 进行编辑的全部 50 万条提交。
搜索与 vim_settings.xml 相关的提交内容
写给各位 Bug 赏金猎人的心得
GitHub dork 只能实现较为宽泛的敏感信息搜索，但如果我们想要查找关于特定公司的内容，又该怎么操作？GitHub 上承载着数百万个代码库，以及与之相关的大量文件，因此我们需要一点启发式的方法来缩小搜索空间。
我发现，最好的办法就是先从目标公司基础架构中的域或子域下手。搜索 company.com 可能帮助不大，因为很多公司发布的开源项目都经过了审核，其中不太可能包含秘密。反而是使用频率较低的域和子域中没准存在着有趣的内容。例如 jira.company.com 等特定主机，以及更为通用的第二级乃至层级更低的域。另外，从模式入手也要比从单个域入手更有针对性：corp.somecompany.com、 somecompany.net 或者 companycorp.com 等往往更有可能出现在员工的个人资料文件当中。
常见的开源情报与域侦查工具包括：
Subpute - 用于蛮力破解子域的 Python dork。
ThreatCrowd - 通过多种 OSINT 技术，查找与给定域相关联的其他域。
Censys.io - 给定一个域，查找使用该域的 SSL 证书。
在找到目标主机或者模式之后，接下来就是在 GitHub 上进行实际搜索了（在使用自动化之前，我总会先手动搜索一次）。在这个阶段，我希望回答以下几个问题：
出现了多少条结果?如果页面超过 100 页，那我可能需要寻找更好的查询切入点（GitHub 将代码搜索结果限制在 100 页）。
出现了什么样的结果?如果这些结果主要是开源代码项目以及使用公共 API 的人员（存在明显的倾向性），那么我可能需要优化搜索以排除这些无用项。
如果更改语言，会产生怎样的影响?language:Shell 与 language:SQL 可能会带来有趣的结果。
这些结果中是否包含其他域或者主机?前几页的结果中通常包含对另一个域的引用（例如，搜索 jira.uber.com 时可能会显示另一个域的存在，例如 uberinternal.com）。
我在这一步上投入了不少时间，最重要的是，搜索空间的定义必须恰当而且准确。只有查询方式正确，自动及手动搜索的效率才能更高，得出的结果也才会更有价值。
在根据上述标准找到有趣的结果之后，接下来就是运行带有 --dig-files 及 --dig-commits 参数的 GitHound，旨在查看整个代码库及其历史记录。这步操作将显示出单凭搜索所无法找到的有趣文件，例如.zip 或者.xlsx 文件。更重要的是，由于自动化 dork 往往会错过某些客户信息、敏感代码与用户名 / 密码组合，因此我常常会手动查看结果。这一般能为我带来更多子域信息或者其他有趣的模式，并帮助我确定下一步搜索查询的规划思路。最重要的，开源情报收集是一种递归过程，请千万勿急勿躁。
这个过程几乎从来不会让人失望。最终泄露内容大多属于以下类型之一（按影响程度由高到低排序）：
SaaS API 密钥- 企业很少会对 API 施加 IP 限制。AWS、Slack、谷歌以及其他 API 密钥可以说是最直接的财富，我们一般可以从配置文件、bash 历史记录文件以及脚本当中找到。
服务器 / 数据库凭证- 这些凭证通常位于防火墙之后，因此影响较校我们一般可以从配置文件、bash 历史记录文件以及脚本中找到。
客户 / 员工信息- 这些信息往往隐藏在 XLSX、CSV 以及 XML 文件当中，具体内容可能涵盖往来电子邮件、账单信息乃至员工绩效评估。
数据科学脚本- SQL 查询、R 脚本以及 Jupyter 项目等都有可能暴露敏感信息。这些库中也往往带有“测试数据”文件。
主机名称 / 元数据- 这也是最常见的结果类别。大多数企业认为它们不属于安全漏洞，但恶意人士确定可以利用这些信息完善后续搜索。
针对特定 API 提供程序的入侵流程
我们也可以针对特定的 API 提供程序及其端点创建专用 dork，并借此敲开那些自动检查用户 API 密钥的企业的大门。通过解析 API 密钥的上下文与语法，我们可以大大缩小搜索空间。
凭借着对于特定 API 提供程序的了解，我们可以从 API 调用中获得与 API 提供程序正则表达式相匹配的密钥，而后利用内部数据库或者 API 端点验证其有效性。
针对单一 API 提供程序进行秘密查找的工作流
例如，假定一家公司（HalCorp）为用户提供读取并写入其账户的 API。那么通过创建自己的 HalCorp 账户，我们会发现其 API 密钥格式为 [a-f]{4}-[a-f]{4}-[a-f]{4}。
凭借这些信息，我们就可以为 HalCorp API 响应编写自己的 GitHub dork 了：
借助 GitHound 这类工具，我们可以使用正则表达式匹配来查找与目标 API 密钥正则表达式相匹配的字符串，并将其输出至文件当中：
echo "HALCorp-Key" | git-hound --dig-files --dig-commits --many-results --regex-file halcorp-api-keys.txt --results-only > api_tokens.txt
现在，我们已经拥有了一个包含潜在 API 令牌的文件，接下来就是针对数据库验证这些令牌的有效性（如果您没有获得 API 提供方的书面许可，请不要这样做）。
仍以 HalCorp 为例，我们可以编写一个 bash 脚本，该脚本从 stdin 读娶检查 api.halcorp.biz/userinfo 端点，而后输出响应结果。
cat api_tokens.txt | bash checktoken.bash
总 结
虽然人们对于 GitHub 上的秘密暴露问题越来越重视，但每天泄露在其上的敏感数据仍然有增无减。Amazon Web Services 已经开始向用户通报其 API 密钥是否被发布至线上，GitHub 也添加新的安全功能，负责扫描公开库中的通用密钥。但是，这些解决方案仅仅是权宜之计，无法彻底解决问题。为了限制源代码发布导致的秘密泄露，我们必须更新 API 框架与 DevOps 方法，彻底防止将 API 密钥直接保存在 Git/SVN 库当中。Vault 等软件已经能够安全存储生产密钥，而某些 API 提供方案（例如 Google Cloud Platform）也更新了自家库，强制要求用户将 API 密钥默认存储为文件形式。
但归根结底，完全消除敏感信息的暴露可能是一项极度困难的挑战：我们要如何全面检查客户信息？如果这些信息被填写在 Word、Excel 或者编译文件中，又该怎么办？我们有必要在这一领域进行更多研究，深入了解由此带来的威胁并制定出行之有效的解决方案。
参考阅读：
https://tillsongalloway.com/finding-sensitive-information-on-github/index.html
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！
