把家门钥匙交给犯罪分子绝对不是个好主意。但这却是大多数开发现代软件的组织经常发生的情况。
在这篇有关机密泄露的第一篇文章中，我们将分析为什么这种情况经常发生，会产生什么后果，以及应采取哪些措施来防止或减轻问题并处理机密泄露事件。
天哪！我把我的云访问密钥推送到了公共存储库
硬编码的秘密 源代码或 DevOps 工具中的配置文件中的机密信息可能会落入坏人之手。如果机密信息 commit如果你将数据存放在公共源存储库中，你肯定会失败。但即使是私有存储库也不安全，因为机密也会通过应用程序二进制文件、日志或被盗源代码泄露。
回想起来，这令人不安 一个简单的疏忽经常会导致严重的安全漏洞。 只需谷歌一下“AWS 密钥泄露“，”GitHub 访问令牌泄露“等等。不要把这些例子当作对这个或那个供应商的隐藏推荐。用你自己的！
例如，臭名昭著的 Codecov 攻击 2021 年 XNUMX 月发生的事件之所以发生，是因为 Codecov Docker 镜像包含 git 凭据，允许攻击者访问 Codecov 的私有 git 存储库，并在 Codecov 的 bash 上传程序脚本中添加一行来收集环境变量和 git 存储库 URL。
提醒一下，攻击赏金的一部分是获取其他系统访问权限的秘密，许多攻击在凭证、加密密钥和令牌泄露方面投入了大量资金。
问题是这样的 硬编码的秘密很常见. 2022 年 XNUMX 月，Lapsus$ APT 泄露189GB 三星源代码和其他敏感文件。分析显示，其中包含一些 6,600 个硬编码秘密：90% 用于内部系统，但 10% 用于外部服务和工具，如 GitHub、AWS 或 Google。这些机密包括 AWS / Twilio / Google API 密钥、数据库连接字符串和其他敏感信息。这是大多数代码库中最先进的技术。
机密泄露是供应链攻击最简单的途径
软件包依赖关系是供应链攻击最常见的目标，尽管它并不是唯一的目标。攻击者可以创建一个新的软件包，最终将其安装到受害者的软件中（使用 注册近似域名 和其他技术），但通常他们会尝试通过在软件存储库中对源代码进行修改来感染现有软件包（SCM) 如 GitHub、GitLab 或 BitBucket，或者通过将恶意版本添加到公共注册表（如 NPM、PyPI、RubyGems、Maven Central）来实施攻击。
但注入恶意代码或隐藏在复杂依赖关系图中的恶意依赖关系需要 login 用户名/密码、令牌或访问密钥等凭证（我们称之为“键”简称），表示目标源存储库或公共注册中心。
坏人有时会通过以下方式获取钥匙 社会工程学。 该 攻击 event-stream 流行的 NPM 包提供了一个很好的例子。但是搜索泄露的 login 凭证或访问密钥是软件供应链攻击最常见的攻击技术。
源存储库和包注册表是软件构建过程中的两个重要系统 pipeline。但是 DevOps 中有很多工具： CI/CD 系统、运行测试的工具、配置和配置自动化或部署和发布。所有这些都可能被滥用来在软件中注入恶意代码。泄露这些工具的有效密钥会直接导致痛苦和折磨。想象一下，泄露了可以完全控制您的公共云资源的根访问密钥……
通常的建议
我们在这里不说任何新东西，你们都知道这一点。但要采取行动！请记住，机器人会定期扫描所有公共 SCM 存储库。以下是一些建议，无特定顺序。
- 如果你负责 IT 安全管理， 定义如何处理秘密 在安全策略中。但政策只有在执行时才有效：确保在您的组织中执行机密处理指南 - 不仅包括您的 DevOps 团队，还包括您的软件供应商，并且您的组织的事件响应计划包含机密泄露事件的规定。
- 实施和执行 多因素认证 （MFA、2FA 或任何缩写）。而且安全性不会降低：USB 安全密钥值得花费几美元。您必须将数千个凭证中的任何一个推送到 git-push（很容易），然后喝醉并将密钥留在酒吧里，以便找到与您有联系的东西（可能性稍微小一点，特别是如果您是戒酒者）。
- 使用密码管理器，设置强密码，不保存密码。在系统中处理机密时，使用 秘密金库. CI/CD 系统、云提供商、 SCMs 和其他 DevOps 工具提供此服务，但您可以选择通用的 Secret Vault 解决方案。
- 比较喜欢 短命 令牌变为长期访问密钥。它们更容易被撤销，并且为邪恶势力提供更有限的攻击机会。
- 限制凭据重复使用：攻击者会将收集到的目标凭证重新用于其他系统，这是使用密码管理器的另一个好处。密码管理器和秘密保险库应该让凭证重用成为过去。
- 限制和监控使用 管理员 密码。它们的威力足够大，值得进行特殊跟踪。
- 实施 强哈希和加密. 回到 USB（加密）密钥、与合作伙伴和同事传输凭证的严格程序等等。
- 使用 秘密扫描仪，例如在 pre-commit 钩 避免版本控制系统的泄漏，作为安全门。 事情发生之前 这一点很重要。或者，使用事后扫描来检测泄露的机密，例如在 pull request 合并。注意：我们的 Xygeni 平台包含一个秘密扫描器，允许两种操作模式。
- 手动替代使用 代码审查 搜索硬编码的秘密成本更高，而且需要commit （但希望至少在秘密被外界知晓之前）。但审查可能会发现可能逃避秘密扫描器的非传统秘密。
- 避免意外 commit将带有机密的公共文件纳入适当的版本控制 排除模式 （如 `gitignore` 模板），考虑到像这样的文件
.env,.npmrc,.pypirc、临时文件...... 这确实是安全洋葱中的额外一层。 - 这份长长的清单中的最后一项是：让云提供商在可用时扫描其密钥是否泄漏。至少，这 五月 让你知道泄漏发生的时间，但安全对于云提供商来说是必不可少的。这 事后 秘密扫描对于扫描的地点和频率不太透明，并且通常需要明确设置，但当所有其他方法都失败时，它无疑是最后的资源。
天哪！我已将云访问密钥推送到公共存储库，请采取 #2
即使我们当中最好的人也可能遇到这种情况。撸起袖子吧！
立即更新/撤销/禁用泄露的机密！如果帐户具有良好的 MFA，则风险会低得多。例如，对于网站中的私钥，这可能会更加困难（您需要为新私钥发出新证书并撤销现有证书），但现代工具可以快速更新凭据或撤销令牌。
按照提供商建议的步骤操作，例如 本示例中的 AWS.
确定泄漏原因。了解泄漏原因对于披露、分析、遏制和吸取教训至关重要。
然后向受影响方报告泄漏情况，解释你为堵住泄漏和减少损害所采取的措施。造成的损害无法挽回，泄漏的已经泄漏。保持透明并告知其他人，以便他们采取行动。
然后开始 取证。 该 曝光窗口 是泄漏与密钥无效之间的时间。准备好读取日志并跟踪受影响帐户在此时间段内的异常活动。删除使用受影响帐户生成的帐户和密钥。提醒一下，如果受影响帐户具有管理员权限，则修复会复杂得多。
重写（版本控制）历史 很复杂。即使是极权主义国家也尝试过这种方法，但都无济于事（双关语）。而且可能无关紧要：黑客或公共回购中的机器人可能已经克隆了回购或已经提取了黄金，特别是如果曝光窗口足够大的话。
如果你喜欢冒险，想亲自看看机器人需要多长时间才能检测到泄露的秘密，那么可以尝试以下方法 金丝雀代币 让你试验一下。请记住，机器人会将默认 canarytokens.org 领域…
| 阅读更多Kovacs，E.“三星源代码泄露 数千个密钥被揭秘“。安全周刊，2022 年 XNUMX 月。Dyjak，A。“几天前，我进行了一个小实验，WRT secrets commit添加到公共 git 存储库…”。推文主题，2020 年 XNUMX 月。Rzepa, P.“GitHub 存储库中的 AWS 访问密钥泄露以及 Amazon Reaction 的一些改进“。Medium，2020 年 XNUMX 月。 |
