作者 | 褚杏娟 燕珊
5 月 26 日，GitHub 披露了 4 月中旬一次安全漏洞的更多调查细节，描述了攻击者如何抓取包括大约 10 万个 npm 用户的详细登录信息。同时，这也显示了在将 JavaScript 包注册中心整合到 GitHub 的日志系统后，GitHub 在内部日志中存储了 “npm 注册中心的一些明文用户凭证”。
“明文密码”的发现过程
今年 4 月 15 日，GitHub 披露了有攻击者通过偷来的 OAuth 用户令牌（原本发放给 Heroku 和 Travis-CI），可以有选择地从私人仓库下载数据。自官方在 4 月 12 日首次发现这一活动以来，攻击者已经从几十个使用 Heroku 和 Travis-CI 维护的 OAuth 应用程序的组织中访问并窃取数据，其中包括 npm。
该行为被发现后，GitHub、Travis CI 和 Heroku 撤销了所有 OAuth 令牌，以阻止进一步的黑客攻击。
5 月 26 日，GitHub 产品安全工程高级总监 Greg Ose 表示，该公司在调查期间发现，攻击者可以获得 npm 的内部数据和客户信息，比如 AWS 访问密钥。通过访问 npm 的 AWS 基础设施，攻击者能够窃取 skimdb.npmjs.com 镜像的旧备份信息，具体包括：
一份来自 2015 年的用户信息存档，包含大约 10 万个 npm 用户名、密码哈希和电子邮件地址。截至 2021 年 4 月 7 日的所有私有 npm 包清单和元数据。截至 2022 年 4 月 10 日的所有私有 npm 包的已发布版本的名称和版本号 semVer。来自两个组织的私人包。
经过日志和事件分析以及检查所有 npm 软件包版本的哈希值后，GitHub“目前确信攻击者没有修改注册表中的任何已公开的软件包，也没有对现有软件包发布任何新版本”。GitHub 重置了所有受影响用户的密码，并向受影响组织和用户发送了通知。
GitHub 强调，攻击者不是通过入侵 GitHub 或其系统获得了这些令牌，因为 GitHub 未以原始可用的格式存储相关令牌。由于 npm 使用与 GitHub.com 完全独立的基础架构，GitHub 在这次原始攻击中没有受到影响。
另外，在这次的事件调查中，GitHub 还表示发现了存储在 npm 注册表内部日志中的一些明文凭证。
按照 GitHub 的说法，“经过内部发现和与 OAuth 令牌攻击无关的额外调查，GitHub 发现将 npm 整合到 GitHub 日志系统后，在内部日志中发现了一些 npm 注册表的明文用户凭证。”具体内容包括“npm 访问令牌和少量用于尝试登录 npm 账户的明文密码，以及一些发送到 npm 服务的 GitHub 个人访问令牌。”
不过，只有 GitHub 员工可以访问这些信息。“这个问题已经得到缓解，在对 npm 的攻击之前，包含明文凭证的日志已经被清除了。”
“虽然这种记录凭证的做法违背了我们的安全最佳实践，但 GitHub 或 npm 并没有遇到会暴露这些含有纯文本凭证日志的损害或数据泄露问题。”GitHub 在报告中补充道。
这是由来已久的安全隐患。在 github 上执行一次搜索删除密码操作可以发现，在 repo 中存储密码的情况非常普遍，简单的搜索就返回来 51 万次 commit 记录，这还没有覆盖到没有填写详细的 commit 信息，或者已经通过删除历史记录来掩饰活动的情况。
GitHub 安全问题不断
GitHub 在全球拥有超过 8000 万个存储库，无疑是最受欢迎的开源代码管理系统。但不断爆出的安全问题也一直困扰着 GitHub。
2021 年，Github 日前遭到大规模暴力破解密码的攻击，一些帐号被成功攻破；2020 年，Github 存储库中发现了臭名昭著的 Octopus Scanner 恶意软件；2018 年，Github 更是遭遇了大规模 DDoS 攻击。
根据北卡罗来纳州立大学的研究，通过对超过 100 万个 GitHub 帐户为期六个月的连续扫描，发现包含用户名、密码、API 令牌、数据库快照、加密密钥和配置文件的文本字符串可通过 GitHub 公开访问。
今年 GitHub 在安全问题上再次加码。5 月初，GitHub 宣布在 2023 年之前，所有使用 GitHub 平台存储代码、做贡献的开发者都需要启动一种或多种形式的双因素身份验证（2FA），否则将无法正常使用该平台。促使 GitHub 做出这项决策的直接原因便是，未启用 2FA 的开发人员帐户去年遭到入侵，导致 npm 包被接管。
“大多数安全漏洞并非来自非常复杂的攻击事件或是零日漏洞，相反，往往是一些低成本的攻击，如社会工程、密码泄露，以及其他为攻击者提供访问受害者账户的攻击。”GitHub 首席安全官 (CSO) Mike Hanley 在发布的博文中写道。
虽然有很多场景已经验证了 2FA 的有效性，但是 2FA 在整个软件生态系统中的采用率仍然很低。GitHub 内部研究表明，目前只有大约 16.5% 的活跃用户（大约六分之一）对其帐户启用了增强性的安全措施，只有 6.44% 的 npm 用户启用了 2FA。
使用 GitHub 的一些建议
即便 GitHub 自身在不断加强安全防护，但是每个 GitHub 用户也应该了解一些安全常识，尽量避免因为个人疏忽等原因造成不必要的损失。
- 切勿将凭据和敏感数据存储在 GitHub 上
GitHub 的目的是托管代码存储库。除了设置账户权限外，没有其他安全方法可以确保密钥、私人凭据和敏感数据可以一直处于可控和安全的环境中。
git 代码提交会维护已添加和删除内容的历史记录，从而使敏感数据永久保存在分支上。当分支被合并和再分叉时，潜在的数据或基础设施泄露问题可能会呈指数级增长。
减轻这种风险最简单方法是在提交到分支之前不在代码中存储凭据和敏感数据。但是，可能会发生一些错误。为从编程层面防止错误情况的发生，可以在 CI 和 CD 管道中使用 git-secrets 等工具，通过中断构建过程来防止带有敏感数据的代码到达 GitHub。另外，也可以使用机密和身份管理工具，例如 Vault 和 Keycloak。
- 删除文件中的敏感数据和 GitHub 历史记录
一旦在 GitHub 仓库中发现了敏感数据，就需要采取一些应急处理措施。首先要使曾经公开的令牌和密码无效。一旦秘密公开就要做好已被攻击者掌握的准备。
当然，肯定需要从存储库中删除敏感数据。但 GitHub 非常擅长保留所有提交的完整历史记录，包括敏感信息的变更日志。有关详细信息，可以参阅“从存储库的历史记录中清除文件”。
- 限制访问控制
开发者专注在分析更复杂的攻击手段时，往往一些最简单的事情都没有做好，比如在显示器上贴着记录密码的便利贴等。
无论是在 GitHub 平台，还是一般的场景，开发者都应当遵守基本的安全准则：在每个贡献者的 GitHub 帐户上启用双因素身份验证、永远不要让用户共享 GitHub 帐号和密码、必须适当保护任何可以访问源代码的笔记本电脑或其他设备等等。
- 严格验证 GitHub 上的应用程序
所有好的平台都可以扩展，GitHub 及其应用程序市场也不例外。在将它们添加到代码仓库时要记住第三方应用扩展是由组织和第三方开发人员编写的。
在选择和安装 GitHub 应用程序时注意：不要给应用程序过多的访问权限、询问应用所需访问级别的原因及可能带来的危害、在让应用背后的作者或组织访问代码库之前验证他们的合法性和可信性等。
安全性取决于最薄弱的环节，因此，如果要访问的应用的安全性较差，那么攻击者可以通过攻击它们的应用来访问你的代码——这是开发者最敏感的资产之一。最后，确保定期检查或审计第三方应用及其贡献者，以确保仍然需要他们、信任他们、认为他们值得赋予权限去访问代码。
- 及时更换 SSH key 和个人访问 token
GitHub 访问通常使用 SSH 密钥或个人用户令牌 (代替密码，因为已启用了双因素身份认证) ，开发者可以定期更新密钥和 token，来降低密钥泄露造成的任何损失。
参考链接：
https://www.bleepingcomputer.com/news/security/github-attackers-stole-login-details-of-100k-npm-user-accounts/
https://www.theregister.com/2022/05/27/github_publishes_a_post_mortem/?td=rt-3a
https://snyk.io/blog/ten-git-hub-security-best-practices/
