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等往往更有可能出现在员工的个人资料文件当中。

常见的开源情报与域侦查工具包括：

Subbrute - 用于蛮力破解子域的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

创作场景

我在 GitHub 找 Bug：如何轻松赚到 10000 美元