JFrog：二进制机密扫描帮助我们防止了（可能是）你能想象到的最严重的供应链攻击

JFrog安全研究团队最近发现并报告了一个泄漏的访问令牌，该令牌具有对Python、PyPI和Python软件基金会GitHub存储库的管理员访问权限，该令牌在Docker Hub上托管的公共Docker容器中泄漏的。

作为一项社区服务，JFrog 安全研究团队持续扫描 Docker Hub、NPM 和 PyPI 等公共软件源，以识别恶意软件包和泄漏的机密。团队会在攻击者有机可乘之前向相关维护者报告任何发现。虽然我们遇到过很多以同样方式泄露机密的情况，但这次的情况比较特殊，因为如果落入不法分子之手，其潜在后果难以估计——据说有人可以将恶意代码注入 PyPI 软件包（想象一下用恶意软件替换所有 Python 软件包），甚至 Python 语言本身！

JFrog 安全研究团队发现了泄漏的机密，并立即向 PyPI 的安全团队报告，后者在短短 17 分钟内就撤销了令牌！

本篇文章将介绍我们是如何发现 GitHub PAT 的，它提供了对整个 Python 基础架构的访问权限，并避免了一场供应链灾难。通过这个案例，我们将讨论机密检测（也）向右转移的重要性——在二进制文件和生产工件中搜索机密，而不仅仅是在源代码中。

我们的发现

我们的机密扫描引擎在一个公共 Docker Hub 资源库中检测到了一个“经典” GitHub 令牌。“经典” GitHub 令牌的风险在于，与较新的细粒度令牌不同，它们会在用户访问的所有存储库中授予类似的权限。

在我们的案例中，用户拥有 Python 基础架构核心资源库的管理员访问权限，包括 Python 软件基金会 (PSF)、PyPI、Python 语言和 CPython。

GitHub 组织	# 具有管理员访问权限的存储库数量
python	91
pypa	55
psf	42
pypi	21

 

会发生什么？

如果有人发现了这个泄露的令牌，其影响可能极其严重。这种令牌的持有者可以通过管理员权限访问 Python、PyPI 和 Python 软件基金会的所有资源库，据称这样就有可能实施极其大规模的供应链攻击。

在这种情况下，可能会出现各种形式的供应链攻击。其中一种可能的攻击方式是在 CPython 中隐藏恶意代码，CPython 是 Python 编程语言核心的一些基本库的存储库，由 C 代码编译而成。由于 Python 的流行，如果在 Python 的可发布程序中插入恶意代码，就意味着将你的后门传播到全球数千万台机器上！

Python 语言供应链攻击向量

另一种可能的情况是在 PyPI 的仓库代码中插入恶意代码，该代码用于管理 PyPI 软件包管理器。想象一下，攻击者插入的代码可以为他们提供 PyPI 存储的后门，让他们可以操纵非常流行的 PyPI 软件包，在其中隐藏恶意代码，或者完全替换它们。虽然这并不是最复杂的攻击方式，但这无疑是一个可怕的场景。

PyPI 供应链攻击向量

为什么只在二进制文件中发现了令牌？

在 Docker 容器中的一个编译 Python 文件 __pycache__/build.cpython-311.pyc中发现了验证令牌：

 

 

然而，在匹配的源代码文件中，同样的函数却不包含该令牌。

看来原作者：

1. 在其源代码中简要添加授权令牌

2. 运行源代码（Python 脚本），并将其编译成带有授权令牌的 .pyc 二进制文件

3. 从源代码中删除了授权令牌，但没有清理 .pyc

4. 将干净的源代码和不干净的 .pyc 二进制文件推送到 docker 镜像中

以下是反编译后的 build.cpython-311.pyc 文件与 Docker 容器上的源代码的对比：

 

从二进制文件 "build.cpython-311.pyc "中重建源代码

 

Docker 容器中匹配文件的实际源代码

 

从 .pyc 缓存文件反编译出来的代码与原始代码相似，但包含了一个带有有效 GitHub 标记的授权头。

仅扫描源代码中的机密是不够的

从我们看到的情况来看，这种情况下的解决方案显然是同时审计源代码和已发布的 Docker 镜像中的二进制数据。虽然在二进制文件中搜索泄漏的机密比基于文本的文件更困难，但有时关键数据只存在于二进制数据中：

 

PyPI 的快速响应
我们要感谢 PyPI 的安全团队，他们紧急处理了这个问题。
泄漏是不可避免的，因此我们不能期望任何组织都能做到 100% 的防泄漏，而是要在发现泄漏时迅速采取行动，并评估泄漏是否造成了任何损失。
在这种情况下，发现令牌后，我们立即通知了 PyPI 安全团队和令牌所有者。PyPI 的安全团队反应非常迅速，在我们联系他们 17 分钟后就撤销了令牌并回复了我们。幸运的是，PyPI 进行了彻底检查，并得出结论：该令牌不存在任何可疑活动。
PyPI 还在博客中发布了更多有关泄密和事件响应的详细信息。

 

我们能从机密探测中学到什么？

虽然这个案例令人震惊，但我们可以从使用访问令牌的工作中学到宝贵的经验。

1.仅仅扫描源代码甚至文本文件中的机密是远远不够的。现代集成开发环境和开发工具能有效检测源代码中的机密并防止其泄漏。然而，它们的检测范围仅限于代码，并不包括构建和打包工具创建的二进制工件。我们在开源注册表中遇到的大多数机密都位于环境、配置和二进制文件中。

2.用新的 GitHub 令牌替换旧式的 GitHub 令牌，以获得更好的可见性。最初，GitHub 使用的是十六进制编码的 40 个字符的令牌字符串，与 SHA1 哈希令牌串无异，大多数机密扫描工具都无法捕捉到。

'Authorization': 'Bearer 0d6a9bb5af126f73350a2afc058492765446aaad'

2021 年，GitHub 改用了新的令牌格式，但并没有要求所有用户重新生成令牌，这也是可以理解的。除其他特点外，新格式的令牌包含可识别的前缀 ghp_，甚至还嵌入了校验和，使机密检测工具能更轻松、更准确地检测到它们。

3.令牌只能访问使用它的应用程序所需的资源。 创建 "一环套一环 "总是个坏主意。两年前，GitHub 推出了新的细粒度令牌。与 "经典 "令牌不同，它们允许用户选择个人访问令牌可使用的权限和资源库，并将其范围限制在特定任务所需的最小范围内。我们强烈推荐使用这一功能，因为我们经常会遇到这样的情况：提供对整个基础架构的最终访问权限的令牌在一个辅助项目或临时的“hello-world”应用程序中被泄露。

 

 

JFrog 机密检测 - 二进制优势

JFrog 的机密检测引擎能够发现这个关键令牌，尽管它是在一个编译过的 Python 二进制文件 (pyc) 中泄露的。我们之所以能够检测到泄漏的令牌，有两个重要原因：

1. JFrog Secrets Detection 既可左移（如在开发人员的集成开发环境中）运行，也可右移（如在部署的 Docker 容器中）运行。

2. JFrog Secrets Detection 可查找文本文件和二进制文件中的泄密内容--让您在所有方面都得到保护。

我们的检测基于 JFrog Xray 对配置文件、文本文件和二进制文件的扫描，以查找纯文本凭据、私钥、令牌和类似机密。我们同时利用不断更新的 150 多种特定类型的凭证列表和专有的通用机密匹配器来实现最佳的覆盖范围。

 

了解 JFrog 安全研究的最新动态

安全研究团队的发现和研究成果在提高 JFrog 软件供应链平台的应用软件安全能力方面发挥了重要作用。

在我们的研究网站和 X @JFrogSecurity 上关注 JFrog 安全研究团队的最新发现和技术更新。