Github代码安全监控

0x00 背景

  Github 类的代码平台是个研发和安全人员的大宝库，阿里云效平台的代码权限事件历历在目,密码泄露到公开代码平台的事件层出不穷，为企业内外部的各种源代码管理系统（gitlab\stash\github\gitee）做好合理配置是新生事物。开发各种 github 敏感信息监控工具均属于事后管理，做好安全配置和培养员工良好的习惯才是安全管理的重中之重。Unit 42研究人员（以下简称我们）使用eth0izzle开发的shhgit来近实时读取GitHub事件，研究人员发现了一些潜在的敏感数据条目，包括：

• 4109个配置文件

• 2464个API密钥

• 2328个硬编码的用户名及密码

• 2144个私钥文件

• 1089个OAuth令牌

0x01 安全管理要求

1. 不要将凭证作为代码 / 配置存储在 GitHub 中。

    在 github 上执行搜索最近操作：https://github.com/search?o=desc&q=password&s=updated&type=Repositories。删除密码操作 https://github.com/search?q=removed+password&type=Commits 。可以发现在 repo 中存储密码的情况是如此普遍，简单的搜索就返回来47万次 commit 记录，这还没有覆盖到没有填写详细的commit 信息，或者已经通过删除历史记录来掩饰活动的情况。

2. 删除文件中的敏感数据和 GitHub 历史记录

   如果已经在 GitHub 仓库中发现敏感数据就需要应急处理。

第一步是需要将曾经过公开的 token 令牌和密码停用或者更改密码。一旦一个口令在互联网上公开，应该假设它已经被掌握在攻击者的手中，并做出相应动作。
第二部是从仓库中删除敏感数据，例如 repo 中删除敏感数据时要清除保存所有 commit 的完整历史记录、敏感信息的修改日志、 GitHub 历史记录。在从，清除非常重要。有关更多信息，参考 https://help.github.com/en/articles/removing-sensitive-data-from-a-repository 。总是有通过git修改了密码，但是commit记录还存在的情况。

3. 限制访问控制

无论是在 GitHub 平台上，还是在一般场景下都应当遵守基本的安全设置，要求研发人员遵循以下基本实践:

1. 禁止研发人员上传代码到 GitHub 。

2. 永远不要让用户共享 GitHub 帐号 / 密码。

3. 仓库配置管理员应该管理团队对数据的访问。只允许研发人员访问他们工作所需的数据。

4. GitHub 账户通常是个人账户，研发人员离开公司后不会自然注销。确保及时检查离职研发人员的访问权限。

5. 严格验证 GitHub 上的应用程序

    所有好的平台都可以扩展，GitHub 及其应用程序市场也不例外。在将它们添加到代码仓库时要记住第三方应用扩展是由组织和第三方开发人员编写的。在选择和安装 GitHub 应用程序时，请考虑以下几点:

• 不要给应用程序过多的访问权限。

• 询问为什么应用需要它所要求的访问级别，并考虑这种访问级别可能造成的危害。

• 在让应用背后的作者或组织访问代码库之前，验证他们的合法性和可信性，就像引入一个新的提交者一样。

• 安全性取决于最薄弱的环节，因此，如果要访问的应用的安全性较差，那么攻击者可以通过攻击它们的应用来访问你的代码——这是开发者最敏感的资产之一。

• 最后，确保定期检查或审计第三方应用及其贡献者，以确保仍然需要他们、信任他们、认为他们值得赋予权限去访问代码。

6. 向 PR 阶段添加安全性测试

    GitHub 有一个功能强大的事件驱动 Git hook 框架，它允许在触发事件时向所选择的服务器发送 HTTP POST 请求。你可以选择处理大量事件，但是对于测试增量代码更改最有用的事件之一是 pull_request 事件。有许多静态代码分析工具支持 Git Hook，当创建 PR 时，会触发一个 HTTP POST 来提示它们测试最新更新的代码。这是确保正在进行的代码和配置更改符合安全预期的最佳时机。
    除了方便地集成到 GitHub 之外，pull request 请求比 “中断构建” 更好，因为它们不必阻止 merge（合并），以及 pr 阶段的这些能力用来测试代码变更，而不是已存在的代码（例如，如果你引入了一个易受攻击的库就 pr 会失败，而不是去检测历史已经存在的高危组件）。
    Snyk、SonarCloud 和 CodeClimate 工具都可以在自动进行代码 review 审核，自研也是一个出路，可以更好兼容于研发流程。

7. 选择合适的 GitHub 来满足安全需求

    根据项目或组织制度，开发者可能被限制使用只能在本地运行的软件。或者这些限制可能是针对源代码存储在何处、哪些其他组织也可以访问。金融机构、政府部门或其他受到严格监管行业的普遍限制如此。然而这并不意味着你不能使用 GitHub!
    考虑下完整版的 on-prem GitHub 企业版，它允许在组织中完全托管 GitHub 仓库。这意味着可以断开与 internet 的连接，并且仍然可以访问 GitHub 企业仓库中的项目。甚至 GitHub 都不能访问你的代码库!

8. 及时更换 SSH key 和个人访问 token

    GitHub 访问通常使用 SSH 密钥或个人用户令牌 (代替密码，因为已经启用了双因素身份认证!) 但是如果这些 token 被窃取了但你不知道如何处理? 请确保定期更新密钥和 token以降低密钥泄漏造成的任何损失。

9. 在创建新项目时考虑到安全性

    当创建一个新项目时，开发人员通常会很愉快地去进行修改、走捷径以便让应用程序启动并运行。这可能会导致开发人员草率处理密码之类的敏感信息，密码可能是硬编码的或者存储在本地配置中比如属性文件。不那么安全的认证措施包括：依赖一个私有加密算法来授权输入，或者暴露如何选择的随机种子。即使对于一个私有的源代码项目，用开源的思想来选择随机数也是一个很好的实践。如果时刻想着去编写其他人将看到并可能去复用的代码，才更有可能编写出更安全的代码。
    此外，如果曾经想过要开放源代码，那么就会更容易、更安全，因为已经在以更安全的开放心态考虑问题，所以不会错过隐藏在代码中的密码或密钥。对于数据安全的敏感性组织可以自助度量，有的公司不容许泄露任何个人，但是笔者看到谷歌的项目里甚至都有作者的邮箱地址。

10. 审核导入 GitHub 的任何代码

    当你将项目或大量代码引入到 GitHub 时，这里将很好地引导了你要做的事情。 导入到 GitHub 的源代码可能已存在数月或数年，并且可能已在封闭的源代码仓库中开发。 这可能导致在封闭源代码环境中做出的许多曾经合理的假设现在都是无效的。在将任何内容引入 GitHub 之前，一定要确保进行了完整的审计。对于较小的项目来说这可能是个顺手的测试，但是一旦代码库达到一定的大小，团队可能需要花费数周或数月的时间来完全审计、更新和导入一个开源仓库。
    要进一步了解 GitHub 安全性，请确保阅读了 GitHub 安全文档和 GitHub 业务安全站点，以获得诸如外部 auth/SAML 支持等额外特性。

0x02 发现工具

• GSIL：GitHub敏感信息泄漏工具。

• Hawkeye：监控github代码库，及时发现员工托管公司代码到GitHub行为并预警，降低代码泄露风险。

• x-patrol：GitHub的泄露扫描系统--MiSecurity。

• Github-Monitor：用于监控Github代码仓库的系统。

• gshark：轻松有效地扫描Github中的敏感信息。

• GitGuardian：实时扫描GitHub活动的解决方案。

• code6：码小六 - GitHub 代码泄露监控系统。

• GitHound：GitHound：一款针对GitHub的API密钥和敏感数据搜索工具

0x03 参考

Github敏感数据分析：https://www.freebuf.com/articles/network/226672.html

旧树开新花：再谈GitHub监控：https://www.freebuf.com/articles/network/226672.html

自己动手打造Github代码泄露监控工具：https://www.freebuf.com/articles/web/173479.html

如何利用GitHub搜索敏感信息：https://www.freebuf.com/column/192643.html