JFrog安全研究团队近期发现并报告了一起严重的安全事件，一个具有管理员权限的访问令牌在Docker Hub上托管的某个公共Docker容器中意外泄露，该令牌可访问Python、PyPI及Python软件基金会（PSF）的GitHub仓库。
作为一项针对线上社区的服务，JFrog安全研究团队持续扫描Docker Hub、NPM和PyPI等公共仓库，旨在识别恶意软件包和泄露的密钥。一旦发现潜在威胁，团队会立即通知相关维护人员，确保漏洞在攻击者对其进行利用之前便得到修复。尽管JFrog团队以往已多次检测到相似方式泄露密钥的安全隐患，但由于此次事件潜在后果影响广泛，因此尤为严重——假设攻击者将恶意代码注入PyPI软件包，或者将所有Python包替换为恶意软件包，这将可能影响到Python语言本身！
JFrog安全研究团队迅速锁定泄露的密钥，并即刻向PyPI安全团队报告，PyPI安全团队仅在短短17分钟内便撤销了该令牌，有效遏制了潜在安全危机。
如今，Python编程语言被广泛应用于绝大多数的数字系统中，包括：
l YouTube、Instagram、Facebook、Reddit、Pinterest以及其他各类社交媒体网站
l 所有机器学习和人工智能程序
l 金融支付系统，如Venmo、Zelle以及摩根大通和高盛等银行的内部操作系统
我们将深入剖析JFrog是如何发现并阻止一起可能危及整个Python基础设施的GitHub个人访问令牌（PAT）泄露事件，同时借此案例强调在密钥检测中“右移”策略的重要性，该策略保证了不仅在源代码中查找密钥，还将在二进制文件和生产制品中加强防范。
我们发现了什么
我们的密钥扫描引擎在Docker Hub上的一个公共仓库中检测到了一个“传统”的GitHub令牌。与更新的细粒度令牌不同，传统GitHub令牌的风险在于，它们授予用户访问所有仓库相似的权限。
在本次的案例中，该事件主角拥有对Python核心基础设施仓库（包括PSF、PyPI、Python语言及CPython）的管理员权限。
可能引发的后果
如果有他人发现了这一泄露的令牌，将造成后果极其严重的安全隐患。该令牌的持有者将拥有访问所有Python、PyPI和Python软件基金会存储库的管理员权限，并可能借此实施大规模的供应链攻击。
如果出现这一情况，可能会发生各种形式的供应链攻击。其中一种可能的攻击方式是，攻击者将恶意代码藏匿于CPython中，该组件包含Python语言的核心库，由C语言编写。鉴于Python的广泛应用，恶意代码一旦混入Python分发版，其潜在影响将波及全球数以千万计的计算机。
另一种可能遭受攻击的场景是，向PyPI的Warehouse代码中渗透恶意代码，该代码用于管理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安全团队的迅速响应。
面对难以规避的泄露风险，企业和相关组织应以最快速度采取行动，评估并减轻潜在损害。
在此次事件中，在发现令牌后，JFrog立即将这一情况通知了PyPI的安全团队和令牌的所有者。PyPI的安全团队迅速响应，仅在17分钟后就做出回应，撤销了这一具有安全隐患的令牌。与此同时，PyPI进行了全面的检查，确认该令牌尚未涉及任何具有安全威胁的可疑活动。
我们可以从密钥检测中汲取哪些经验？
从此次事件中，我们汲取了宝贵经验：
1. 在源代码和文本文件中扫描密钥已经不足以排除安全隐患。现代集成开发环境（IDE）和开发工具虽然可以有效地在源代码中检测密钥并防止其泄露，但它们的范围仅限于代码，却往往忽略由构建和打包工具生成的二进制制品。我们在开源注册表中遇到的大多数密钥都位于环境、配置和二进制文件中。
2. 用新的令牌替换老式的GitHub令牌以实现更好的可见性。最初，GitHub 使用的是十六进制编码的 40 个字符的令牌字符串，与 SHA1 哈希字符串无异，大多数密钥扫描工具都无法捕捉到这种字符串。2021年，GitHub改用了一种新的令牌格式，该更新并未强制要求所有用户重新生成他们的令牌。新格式的令牌包含可识别的前缀 ghp_，同时还嵌入了校验和，允许密钥检测工具能更轻松、更准确地识别它们。
3. 您的令牌只能访问使用它的应用程序所需的资源。将令牌权限设置为最大并非明智决定。两年前，GitHub引入了新的细粒度令牌。与传统令牌不同，它们允许用户选择个人访问令牌可用的权限和仓库，并将其范围限制为相应任务所需的最小范围。我们强烈建议使用此功能，从而最大程度避免类似于对整个基础设施具有最终访问权限的令牌在一个辅助项目或临时的“hello-world”应用程序中被泄露的情况。
JFrog Secrets Detection – 二进制优势
即使关键令牌被泄露在一个编译后的Python二进制文件（.pyc）中，JFrog的密钥检测引擎依然能够将其识别。我们能够检测到泄露的令牌主要得益于两个重要原因：
1. JFrog Secrets Detection在开发人员的IDE内部实现左移运行，也可以在已部署的Docker容器内部进行右移运行。
2. JFrog Secrets Detection能够实现在文本文件和二进制文件中搜索泄露的密钥，实现全方位的保护。
JFrog的检测基于JFrog Xray针对配置文件、文本文件和二进制文件进行扫描，查找纯文本凭据、私钥、令牌和类似的密钥信息。通过利用持续更新且拥有超过150种特定类型证书列表，以及专有的通用密钥匹配器，JFrog将尽可能的在扫描过程中实现最佳的文件覆盖范围。
作者：Yoav Landman，JFrog联合创始人兼首席技术官、Shachar Menashe, JFrog安全研究高级总监
（新闻稿 2024-08-16）
