这是关于最常见的软件供应链攻击的系列文章的第一部分：那些滥用软件组件公共注册表的攻击，旨在 开源项目 上传可与其他用户共享的工件。当坏人在那里发布恶意软件时，使用注册表作为恶意软件分发的载体，当受害组织安装或运行受感染的软件组件时，我们就会受到供应链攻击。
为了简化讨论，我们将讨论 软件包:，第三方制作的以打包形式存在的组件。这不仅包括 NPM 或 Poetry 等包管理器使用的组件，还包括 操作系统组件 包括库和可执行二进制文件， 容器镜像， 和虚拟机，或 工具扩展 用于开发、构建和部署工具。我们到处都看到过恶意软件包。网络犯罪分子并不介意：他们对现代软件基础设施提供的替代方案感到高兴，并使用最适合他们意图的注册表和工具。因此请记住，软件包是容器映像、二进制包、开源存储库以及各种扩展或插件（IDE、 CI/CD 系统、构建工具）。所有这些都经常受到攻击。
该系列剧共有 5 集：
- 开源软件包存在什么问题？ 这就是这篇文章的主题。为什么各种犯罪分子都在发布恶意软件？我为什么要担心？
- 恶意软件包剖析：有哪些趋势？ 在本集中，我们将重点关注我们日复一日使用 MEW 系统监控的威胁。由于大量使用域名抢注或依赖项混淆的恶意数据包导致背景噪音很大，因此较小比例的攻击更加阴险，风险更大。不良行为者在操作系统方面的行为最近发生了哪些变化？数字是多少？使用的策略、技术和程序是什么，以及看到了哪些有害行为？
- 防范开源恶意软件：哪些方法有效（哪些方法无效）。大多数有安全意识的专业人士都知道如何应对这种威胁。我们听到安全经理毫不犹豫地说 SCA 工具已经告诉您软件包版本是否是恶意软件。或者它们依赖于知名的、经过高度审查的软件组件，任何恶意软件都会被及时检测和删除。他们使用开放的次要/补丁版本来自动获取漏洞修复，这是降低开源依赖项风险的正确、推荐的方法，遵循“尽早修补，经常修补”的原则。在本集中，我们将回顾这些想法为什么是错误的，以及这些误解如何导致这种攻击机制的流行，以及组织正在经历的巨大风险。我们将以哪些是有效的以及哪些是所涉及的努力和资源来结束。
- 开源恶意软件：Xygeni 方法在本集中，我们将介绍 Xygeni 针对恶意软件预警 (MEW) 系统所采用的策略。当发布新的软件包版本时，这个多阶段系统如何实时工作，如何从不同来源获取证据，如何进行分类，我们遵循哪些分类标准，以及为什么还需要进行一些手动分析来确认恶意软件包候选者的性质？我们内部和注册团队的反馈如何帮助系统从过去收集的证据中学习，从而将误报率降至最低。我们将解释我们如何帮助 NPM、GitHub、PyPI 和开源生态系统中的其他关键基础设施减少停留时间.
- 利用开源：坏人会做什么。本系列文章最后重点介绍了攻击者采取的最新行动，这些行动使攻击更加隐蔽、更难检测、更针对特定行业，并从此类攻击中获取更多利益。勒索软件攻击会使用这种手段吗？坏人如何利用人工智能工具来提供更复杂的恶意软件包？最受欢迎的项目是否面临危险？这是为了让读者了解这场军备竞赛，以及短期（2024 年下半年）和中期（2025 年）的预期。我们将了解最近的攻击如何 XZ-Utils 后门或对 电子制造商 2024 年 XNUMX 月的形势表明，我们应该对对手的发展保持警惕。
我们先来揭开本期的序幕：恶意开源软件包到底是怎么回事？
开源软件包存在什么问题？
近年来，各种不法分子利用开源软件注册中心进行恶意行为。这些活动与开源一样古老，但近三年来其发生频率呈爆发式增长。
将恶意组件发布到公共注册表中（基于依赖关系的攻击）是一种非对称游击战，威胁行为者利用这种战法来传播恶意软件，利用组织对来自未知开发者的开源组件的信任（记住 依赖 xkcd 漫画?)。由于您信任软件包并且不介意手动检查软件包内容及其依赖项，因此这些攻击非常有效。不对称性之所以存在，是因为它们可以在很大程度上实现自动化，并且坏人不需要直接与受害者互动。他们只需将软件包上传到公共注册表中，然后放手即可。
恶意软件包 6 年增长 2022 倍，并在 2.5 年继续增长 2023 倍。去年发现了 245,000 个恶意软件包，这一数字是前几年总数的两倍多。这是指数级增长！从 2021 年数百个和 2022 年数千个被确认为恶意软件的软件包中删除来看，我们在 2023 年看到了更多的背景“噪音”，今年的速度也差不多。在这种由不老练的网络犯罪分子遵循“阻力最小的路径”造成的背景中，少数引人注目的攻击甚至登上了大众媒体的头条新闻。
为什么这个问题如此严重？ 过度信任 整个链条中都存在开源软件。开源软件随其源代码一起分发，并根据给定的许可证发布。是的，任何人都可以检查源代码；但是，谁可以自由地检查呢？在检查软件没有恶意软件之后，谁会从源代码构建软件？在将打包的组件（也称为 包) 下游到包管理器或构建工具，确保包中没有恶意软件并且与其应来自的源代码相对应？
为什么基础设施会允许如此轻易的攻击？
软件包注册表 是开放的，通常只需要对发布者的身份进行最低限度的验证。“任何人都可以在这里发布他们的软件！”攻击者的门槛很低：他们使用一次性电子邮件地址和一次性 GitHub 帐户在简短的类似网络钓鱼的活动中创建数百个恶意包。只有针对目标的恶意包才需要更高的复杂程度：我们甚至看到创建一个可信的 GitHub 源代码存储库，其中包含许多星星和 commit来自多个虚假贡献者以及其他受欢迎程度和维护度指标。 虚假贡献的观星者和声誉 自动化并不困难。我们看到各种开放软件基础设施遭到滥用，不仅仅是恶意软件，比如 茶协议事件.
包管理器的设计初衷是为了易于使用，而不是为了安全。它们可以运行安装前和安装后的脚本（有时需要为库编译本机代码）。此外， 包装经理 从多个来源安装包，有时默认使用公共注册表。他们没有检查发布请求中的元数据与包本身中的元数据是否不匹配。
依赖关系是嵌套的，并形成一个图。在某些生态系统（如 Node (JavaScript)）中，小粒度的依赖关系会累积成百上千个。一件事是严格控制我的软件项目声明的直接依赖关系，但 传递依赖 更难控制。开源遵循“朋友的朋友就是我的朋友”。兄弟情谊是远东地区的常态！威胁行为者知道这一点，并将恶意行为深深地隐藏在通常不为人知的模糊依赖关系中。 事件流 针对事件 共付钱包.
这就是开源软件自诞生以来的运作方式。它不会有太大变化。一些软件包注册表最多要求双因素身份验证，而且通常只针对最受欢迎的软件包。一些注册表提供范围，即由经过审查的组织拥有的命名空间，但 悲剧地 其他不支持它（PyPI）或使其成为可选（NPM）。 有趣的是，即使是 简单筛选方案 （基于对与组 ID 匹配的 DNS 或 GitHub 存储库/组织的控制）并制定 强制使用 PGP 签名 除了校验和之外的所有工件，消除了大部分“噪音”，类似域名抢注的恶意程序包，并限制了大部分 依赖混淆。复杂的攻击是可能的，但难度要大得多，只有少数像 com.github.codingandcoding:maven-compiler-plugin 以 Maven Central 闻名。但并非所有的 Maven 注册中心都遵循相同的做法！
包管理器上的安全控制可能会增加依赖性攻击的负担，但不会阻止它。多因素身份验证的问题在于，对于自动化，会为帐户生成派生凭据（如访问令牌或 APIapi 密钥），用于从自动化脚本进行的 APIapi 调用，而没有支持交互式用户提供第二个因素。MFA 可以很好地保护用户帐户免受密码泄露，但生成的访问令牌或 APIapi 密钥需要在活动期间受到保护，否则其所有者将被对手冒充。很大一部分基于包的供应链活动都是从泄露的密钥/令牌开始的。只需记住以下事件 莱杰, 3CX等等，在发起供应链攻击的初步入侵中，非交互式凭证首先被泄露。
对这一威胁的回应不够有力。在第三集中，我们将重点讨论哪些措施奏效，哪些措施惨遭失败。业界需要共同努力 standards、流程、教育和工具来降低全球供应链的风险。这不是一个组织可以单独解决的问题。
为了结束本节，关键的误解是：我们正在谈论 恶意 包，而不是 脆弱 漏洞来自设计或编码错误，无意中引入，并非恶意。漏洞可能会被利用，但很多漏洞不会被利用。恶意软件总是故意的，如果执行，则 100% 可被利用。没有可比的风险！因此 人们在检测和缓解漏洞方面付出了如此多的努力，但对恶意组件却缺乏同等措施，这真是自相矛盾.
“我们非常重视安全”
让我们想象一下习惯 Acme公司。Acme 是 WileCoyote.com 的主要提供商，其大部分软件来自第三方，其中 80% 以上来自开源项目。他们生产供内部使用的软件，但也为合作伙伴、提供商和客户/最终用户提供软件。Acme 的软件使用 Go、JavaScript、Java、C# 和 Python 编写，并在 Kuberneteskubernetes 集群下的云端运行其大部分软件。Acme 从 Docker Hub 和其他注册表中获取的基础映像构建其自定义映像。他们还在公共注册表中共享一些库、包和容器映像。
Acme 非常重视安全。他们非常清楚 open source security以及它所带来的风险。所有开发人员、系统管理员和 DevOpsdevops 工程师都使用这些可爱的小加密密钥作为第二因素身份验证。所有 commit对代码存储库进行签名，启用分支保护并进行强制代码审查， CI/CD 锁定，机密存储在机密库中，并且内部注册表部分镜像外部注册表，其中仅存储允许的白名单组件。要求 Acme 构建的软件必须从此注册表获取第三方依赖项。
可能大多数组织都符合这一概况。亲爱的读者，如果你还在这里，你的组织肯定符合这一概况，不是吗？
然后有一天，一位重要的前端开发人员 在 Acme 运行 npm 安装 acme-cute-lib，忘记了 @acme/cute-lib 是正确的范围依赖项。确切的错误并不重要，即使假设可以完美控制软件生命周期，也可能出现许多问题。我们的开发人员不知道 APT 组织以 Acme 为目标，并以该名称发布了一个恶意组件，而且方式十分狡猾，因此恶意行为仅在软件安装在 Acme 计算机上时才会激活。该软件包在发布数周后才被检测到。
运行安装脚本来搜索凭证（我们开发人员的笔记本电脑中有许多有用的访问令牌），允许访问内部软件存储库和上述内部存储库，当然，后者只能通过 VPN 访问。恶意代码设法使用现有的 VPN 连接，并将第二阶段恶意组件发布到内部注册表中，影响 Acme 提供的大多数软件共享的通用实用程序库。
数周后，其他使用 Acme 发布工具的组织开始发现其网络上出现奇怪的流量，流量使用 Acme 的协议，但指向类似于 Acme 域的主机。流量经过加密，但系统监控工具发现可以访问意外文件，并执行看起来像系统命令但最终运行下载的可执行文件的进程。
剩下的就是历史了：Acme 首先否认这种行为是他们造成的，并表示所有安全措施都已到位。直到网络安全媒体开始询问为什么检测到的行为源自 Acme 的组件，并且安全分析人员公布了这些组件中隐藏着多少隐秘的恶意软件后，Acme 才不得不承认这一事件，并请来了一家事件响应公司。一场负面的营销活动在一秒钟内破坏了来之不易的信心。“Acme 只需安装 npm 即可saster”是一个常见的标题。随后，诉讼和合同取消接踵而至。
您认为这与过去已知的事件有相似之处吗？Acme 遭遇了一起供应链事故，事故分为两个阶段，使用了 依赖性混淆/域名抢注 攻击利用开发人员工作站作为感染组件的滩头阵地，这些组件最终进入第三方使用的软件。如何预防或缓解这种情况？
为何有毒软件包如此受欢迎
这一假设事件表明，即使采用合理的开源安全方法，组织也需要采取特定措施来避免成为开源组件中恶意软件的牺牲品。从图中可以看出，威胁行为者可以：
- 创建一个新的软件包（遵循众所周知的域名抢注或依赖混淆途径，这是坏人最常走的路径）；
- 尝试感染现有的，要么将其注入源代码，要么试图通过以下方式将其伪装成贡献者 pull request或者利用社会工程学成为维护者（就像“Jao Tan”在 XZ Backdoor 中所做的那样） 右9ctrl GitHub 用户在 事件流 2018 年秋季的事件），或者通过获取开源存储库凭证并冒充维护者；
- 在构建软件包期间注入恶意软件，方法是运行恶意构建脚本或者通过中间人拦截来干扰软件包下载（幸运的是，现在大多数注册中心都要求使用 TLS）。
- 将打包的组件直接注入注册表，通常是通过捕获注册表凭据（这是许多复杂攻击的首选方法，例如 Acme 的攻击，其中第一阶段受感染的工作站具有内部注册表访问令牌，例如在通常的 .ENV or ~/.m2/settings.xml：坏人确实知道在哪里寻找秘密）。注册表中的漏洞也被利用了。
用恶意软件毒害注册表是依赖性攻击的基础。这并非新鲜事：这种攻击方式已呈爆发式增长，但如今使用的技术与五年前一样。
来源: 背叛者的刀具收藏.
恶意软件包可以在安装、软件构建或运行时运行。其行为范围从信息泄露（例如提取机密以进行第二阶段尝试）到源代码提取、投放其他恶意软件。在下一集中，我们将剖析恶意软件包及其发布方式。
深入阅读
下一集 恶意软件包剖析：有哪些趋势？ 将重点关注我们日复一日使用恶意软件预警系统监控的真实案例。我们将回顾发现的恶意软件类型，以及哪些策略、技术和程序是最受欢迎的。我们将研究混淆以及它们如何试图躲避潜在审阅者、避免检测的规避技术，以及它们如何随着遥测和横向移动而发展。敬请期待！
案例
- 背叛者的利刃集合：开源软件供应链攻击回顾. M. Ohm 等人，2020 年 XNUMX 月。
- 开源恶意软件防护.Xygeni 的白皮书。
- Software Supply Chain Security 回顾：塑造更安全的2024年. Xygeni 的报告。
