并非所有的软件供应链攻击都是一样的。以下是攻击者目前通过第三方破坏合法软件的惯用方法。

软件供应链事件最近登上了新闻头条，引发了各界广泛关注。尽管这些安全事件有着诸多相似之处，但事实上，并非所有的供应链攻击都是相同的。

“供应链攻击”这一总称涵盖了攻击者干扰或劫持软件制造过程（软件开发生命周期），从而对成品或服务的诸多消费者造成不利影响的任何情况。当软件构建中使用的代码库或单个组件受到感染、软件更新二进制文件被木马化、代码签名证书被盗，甚至托管软件即服务（SaaS）的服务器遭到破坏时，都可能会发生供应链攻击。

对于任何软件供应链攻击，攻击者都会在上游或中游介入，将其恶意活动及其后果向下游传播给众多用户。因此，与孤立的安全漏洞相比，成功的供应链攻击往往规模更大，影响更深远。

下面为大家介绍现实世界中成功的软件供应链攻击活动惯用的6种关键技术：

供应链攻击示例

1. 上游服务器妥协——Codecov攻击

对于大多数软件供应链攻击，攻击者会破坏上游服务器或代码存储库并注入恶意负载（例如，恶意代码行或木马更新）。然后将该有效载荷向下游分发给众多用户。然而，从技术角度来看，情况并非总是如此。

Codecov 供应链攻击就是这样一个例子。尽管该事件与SolarWinds攻击存在相似之处，但两次攻击之间却存在明显差异。SolarWinds 供应链漏洞是技能卓越的威胁行为者的“杰作”，他们更改了合法的更新二进制文件 SolarWinds.Orion.Core.BusinessLayer.dll，其是SolarWinds IT性能监控产品Orion的一部分。

FireEye之前分析过，假冒DLL的RefreshInternal()方法中包含的恶意代码如下所示。当 Orion 加载库存管理器插件时，此方法会调用基于 HTTP 的后门：

带有恶意RefreshInternal方法的后门DLL版本2019.4.5200.9083

然而，只有当修改后的二进制文件向下游传播至包括美国政府机构在内的 18,000 多个 SolarWinds Orion 客户时，SolarWinds 上游攻击才算发挥了全部作用。

而在Codecov攻击案例中，没有恶意代码分发到下游，但却切切实实地产生了攻击后果。根据官方安全公告指出，黑客利用Codecov的Docker映像创建过程中出现的错误，非法获得了其Bash Uploader脚本的访问权限并且进行了修改，以收集从客户的持续集成/持续交付 (CI/CD) 环境上传的环境变量：

尽管Codecov Bash Uploader 脚本在Codecov[.]io/bash 的 Codecov 服务器本身上存在（并继续存在），但数千个存储库已经指向该链接，以将信息从其 CI/CD 环境上游发送到此BashUploader。因此，恶意代码仅存在于（受损的）上游服务器上，而没有发生任何下游代码分发，因为所谓的下游存储库已经指向托管 Bash Uploader 脚本的 Codecov 服务器。然而，这些下游存储库也受到了此次攻击的影响，因为它们被配置为将数据上传到 Codecov 的 Bash Uploader：

事实上，据报道，Codecov 攻击者使用从受损Bash Uploader处收集的凭据破坏了数百个客户网络。最近开源程序工具和保险柜制造商HashiCorp也披露称，Codecov供应链攻击已经致使其GPG签名密钥被泄漏。

2. 中游妥协以传播恶意更新

术语“中游”在这里主要指攻击者破坏中间软件升级功能或 CI/CD工具而非原始上游源代码库的实例。今年4月，许多《财富》500 强公司使用的Passwordstate企业密码管理器的制造商Click Studios通知客户称，攻击者破坏了Passwordstate的升级机制，并利用它在用户的计算机上安装了一个恶意文件。其文件名为“moserware.secretsplitter.dll”，其中一小部分如下所示：

在安全公告中，Click Studios表示，攻击持续了大约28小时才被关闭。只有在此时间段内执行一键升级的客户才会受到影响。而Passwordstate 的手动升级不会受到损害。受影响的客户密码记录可能已被收集。

不出所料地是，Passwordstate攻击事件后就发生了针对Click Studios 用户的网络钓鱼攻击，攻击者在这些钓鱼电子邮件中放置了指向更新的恶意软件版本的非法链接。

除了具备技术要素（例如升级过程被篡改）之外，这种供应链攻击还具备社会工程学因素。在一份大小超过300 MB的伪造更新zip文件中，安全研究人员发现，攻击者已设法更改用户手册、帮助文件和PowerShell构建脚本，以指向其恶意内容分发网络（CDN）服务器：

阐明恶意CDN服务器为官方的帮助手册文档之一

包含恶意CDN服务器链接的PowerShell安装脚本

针对此次攻击的社会工程学手段还说明了另一项弱点：人类（尤其是新手开发人员或软件消费者）可能并不总是对内容分发网络（CDN）链接保持怀疑态度，无论这些链接是否真的可疑。这是因为通常情况下，CDN是被软件应用程序和网站合法同于提供更新、脚本和其他内容的。

Magecart等在线信用卡窃取攻击就是此类供应链攻击的另一个例子。在某些攻击中，Amazon CloudFront CDN存储桶已被攻破，以将恶意JavaScript代码分发到更多依赖此类CDN的网站之中。

3. 依赖项混淆（dependency confusion）攻击

2021年，提及供应链攻击就少不了要提“依赖项混淆”，特别是因为这种攻击的简单化和自动化特质，使其日渐受到攻击者的青睐。得益于在多个开源生态系统中发现的固有设计缺陷，依赖项混淆能够在攻击者端通过最小的努力甚至是自动化的方式发挥作用。

简而言之，如果您的软件构建使用私有的、内部创建的依赖项，而该依赖项在公共开源存储库中不存在，那么依赖项混淆（或命名空间混淆）就会起作用。攻击者能够在公共存储库上以相同的名称注册具有更高版本号的依赖项。然后，很大的可能是，攻击者创建的具有更高版本号的（公共）依赖项——而非您的内部依赖项——将被拉入您的软件构建中。

依赖项混淆攻击示意图

今年2月，通过利用 PyPI、npm 和 RubyGems 等常用生态系统中的这个简单缺陷，道德黑客 Alex Birsan 成功地入侵了35家大型科技公司，并为此获得了超过130,000美元的漏洞赏金奖励。

在Birsan的研究成果披露几天后，数以千计的依赖项混淆模仿包开始涌入 PyPI、npm 和其他生态系统。虽然大多数模仿包都是由其他有抱负的漏洞赏金猎人所创建，但是仍然不乏一些恶意行为者的身影。

解决依赖项混淆的方法有很多，包括在攻击者之前抢先在公共存储库上注册所有（你的）私有依赖项的名称；以及使用自动化解决方案，例如软件开发生命周期（SDLC）防火墙，以防止冲突的依赖项名称进入您的供应链。

此外，开源存储库的所有者可以采用更严格的验证过程并实施命名空间/范围界定。例如，如果想要在“CSO”命名空间、范围下注册依赖项，那么开源存储库可以先验证注册的开发人员是否有权以“CSO”的名义这样做。

Java 组件存储库Maven Central采用简单的基于域的验证方式来验证命名空间所有权——这种做法可以很容易地被其他生态系统建模。

4. 被盗的SSL和代码签名证书

随着HTTPS网站的增加，SSL/TLS证书已经无处不在，它可以保护您的在线通信。因此，SSL 证书私钥的泄露可能会威胁到端到端加密连接为最终用户提供的安全通信和保证。

2021年1月，Mimecast披露其客户用于建立与Microsoft 365 Exchange服务连接的证书遭到破坏，可能影响约10%的Mimecast用户的通信。虽然Mimecast没有明确确认其是否为SSL证书，但正如一些研究人员所怀疑的那样，在很大程度上情况似乎确实如此。

虽然受损的SSL证书存在影响，但被盗的代码签名证书（即受损的私钥）会对软件安全产生更广泛的影响。获得私有代码签名密钥的攻击者可能会将他们的恶意软件签名为由信誉良好的公司提供的真实软件程序或更新。

尽管“震网”（Stuxnet）事件时至今日仍然是复杂攻击的一个重要案例——在此次攻击中，攻击者使用了从两家著名公司窃取的私钥将其恶意代码签名为“受信任”——但此类攻击其实早在Stuxnet事件前就已经盛行，甚至在Stuxnet事件发生后数年的今天仍在盛行。这也解释了前面提到的Codecov供应链攻击中HashiCorp的GPG私钥泄露事件之所以备受关注的原因。虽然目前还没有迹象表明HashiCorp的泄露密钥被攻击者滥用来签署恶意软件，但在泄露的密钥被撤销之前，这种事件确实有可能发生。

5. 针对开发者的CI/CD基础设施

如今，软件供应链攻击盛行，这些攻击不仅依赖于向用户的GitHub项目引入恶意拉取请求，还会滥用GitHub的CI/CD自动化基础设施GitHub Actions来挖掘加密货币。GitHub Actions为开发人员提供了一种为GitHub上托管的存储库安排自动化CI/CD任务的方法。

攻击方式主要包括攻击者克隆使用GitHub Actions的合法GitHub存储库，稍微更改存储库中的GitHub Action 脚本，并向项目所有者提交拉取请求以将此更改合并回原始存储库。

攻击者 (edgarfox1982) 为合法项目所有者提交拉取请求以合并更改的代码

如果项目所有者随意批准更改的拉取请求，那么供应链攻击就会成功，而且后果远不止于此。恶意拉取请求包含对 ci.yml 的修改，一旦攻击者提交拉取请求，GitHub Actions 就会自动运行这些修改。修改后的代码实质上是滥用 GitHub 的服务器来挖掘加密货币。

这种攻击可谓是一举两得：它诱使开发人员接受恶意拉取请求，如果失败，它就会滥用现有的自动化CI/CD基础设施进行恶意活动。

2021年1月，Sakura Samurai安全人员在研究联合国漏洞披露计划范围内的资产安全漏洞时，发现了一个ilo.org子域，该子域暴露了大量Git账户信息，使得他们能够成功入侵联合国（UN）域并访问超过 100,000 份 联合国环境规划署（UNEP）工作人员记录。这些记录包括姓名、员工ID号、员工组、旅行理由、旅行的开始和结束日期、批准状态、停留时间和目的地。

更糟糕的是，获得Git凭证访问权限的威胁行为者不仅可以克隆私有Git存储库，还可能在上游引入恶意代码以触发供应链攻击，从而产生更严重的后果。

想要阻止此类攻击，开发人员需要践行安全编码或在开发环境中使用DevSecOps 自动化工具。同时，保护 CI/CD 管道（例如 Jenkins 服务器）、云原生容器以及附加开发人员工具和基础设施现在也变得同样重要。

6. 使用社会工程学来引入恶意代码

任何安全专业人员都知道，安全性取决于其最薄弱的环节。由于人为因素仍然是最薄弱的环节，因此泄露往往来自最意想不到的地方。最近，明尼苏达大学的研究人员被踢出了 Linux 贡献群体，Linux 内核社区也撤销了他们之前提交的所有Linux内核代码，原因在于他们故意提出有缺陷的“补丁”，而这些“补丁”又会在 Linux 内核源代码中引入漏洞。

尽管该事件被积极制止，但还是证实了一个结论：开发人员分布广泛，并且没有足够的宽带来审核他们提交的每一个代码，这些代码可能是存在缺陷的或完全是恶意的。

更重要的是，社会工程学可能来自最不受怀疑的来源——在上述案例中，具有“.edu”后缀的电子邮件地址就看似来自可信的大学研究人员。

另外一个突出案例是，任何为GitHub项目做出贡献的合作者都可以在发布后更改版本。在此需要强调，GitHub项目所有者的期望是大多数贡献者都能真诚地提交代码到他们的项目之中。但正可谓“一个老鼠坏一锅汤”，只要一个合作者不规矩就会损害许多人的供应链安全。

在过去一年中，攻击者创建了域名抢注和品牌劫持包，一再针对开源开发人员在其上游构建中引入恶意代码，然后传播给众多消费者。

所有这些真实世界的例子都展示了威胁行为者在成功的供应链攻击中所采用的不同漏洞、攻击媒介和技术。随着这些攻击不断发展演进并带来挑战，在考虑软件安全性时，必须纳入更多创新的解决方案和策略。

本文翻译自：https://www.csoonline.com/article/3619065/6-most-common-types-of-software-supply-chain-attacks-explained.html?nsdr=true&page=2如若转载，请注明原文地址