6种最常见的软件供应链攻击类型

“软件供应链攻击”是指攻击者干扰或劫持软件制造过程（软件开发生命周期），从而对成品或服务的用户产生不利影响的任何情况。当软件构建过程中使用的代码库或单个组件被篡改、软件更新二进制文件被植入木马、代码签名证书被窃取，甚至软件即服务（SaaS）托管服务器被入侵，都会发生此类情况。

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

任何代码库都可能包含恶意代码，尽管GitHub等代码库正在采取积极措施防止恶意软件进入其网站，但攻击者仍在想方设法地向开发人员提供他们的代码。

Phylum的《2023年第三季度软件供应链安全演变报告》显示，大多数不同类别的可疑软件包都在增加。在扫描的300万个软件包中，有1万多个文件引用了已知的恶意URL。近86000个软件包包含预编译二进制文件，因此很难对其进行恶意软件扫描。另外有5500个文件试图混淆代码，还有5000个文件是作者用废弃的电子邮件账户注册的。

更重要的是，越来越多的恶意软件作者将目标锁定为特定公司，而不是采取更广泛的策略。近1000个恶意程序包以特定团体或企业为目标，比2023年第二季度增加了47.4%。这些针对性攻击的目标包括获取凭证、窃取源代码或知识产权。

然而，开发人员的做法似乎并没有使软件供应链更加安全。Phylum指出，开发人员每周从Javascript软件包注册中心Npm下载约240亿个软件包，但几乎没有人验证下载代码的完整性。报告指出，这一行为可能会鼓励攻击者在未来发起更广泛的活动，如大规模勒索软件攻击或僵尸网络。

在此，我们研究了近几年成功的软件供应链攻击中使用的六种不同技术。

1. 入侵上游服务器：Codecov攻击

在大多数软件供应链攻击中，攻击者会入侵上游服务器或代码库，并注入恶意有效载荷（如恶意代码行或木马更新）。然后，这些有效载荷会被分发到下游的许多用户。然而，从技术角度来看，情况并非总是如此。

Codecov供应链攻击就是这样一个例子。尽管该事件与SolarWinds的漏洞事件相类似，但这两次攻击却有着明显的不同。SolarWinds供应链漏洞是由复杂的威胁行为者所为，他们篡改了合法的更新二进制文件SolarWinds.Orion.Core.BusinessLayer.dll，该文件是SolarWinds IT性能监控产品Orion的一部分。

根据FireEye之前的分析，伪造DLL的 RefreshInternal() 方法中包含的恶意代码如下所示。当Orion加载Inventory Manager插件时，该方法会调用基于HTTP的后门：

版本2019.4.5200.9083的后门DLL使用恶意RefreshInternal方法

然而，SolarWinds的上游攻击只有在被篡改的二进制文件流向包括美国政府机构在内的18000多名SolarWinds Orion客户时才会全面爆发。

在Codecov的案例中，恶意代码没有向下游传播，但攻击造成的影响却传播了下去。根据官方安全公告，Codecov攻击者从有缺陷的Docker映像创建过程中获得了凭证，可用于修改Codecov Bash Uploader。攻击者随后修改了托管在Codecov服务器本身的Codecov Bash Uploader，以收集从客户的持续集成/持续交付（CI/CD）环境上传的环境变量：

修改了Codecov的Bash Uploader行，该行收集环境变量并将其发送到攻击者的IP地址

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

据报道，Codecov的攻击者使用从被黑的Bash Uploader收集到的凭证入侵了数百个客户网络。不久之后，HashiCorp披露，Codecov事件导致其用于签署和验证软件包的GPG私钥曝光。Twilio也披露了此次攻击造成的一些影响，其他公司也在进行类似披露。

2. 利用中游漏洞发送恶意更新

这里的“中游”一词指的是攻击者入侵中间软件升级功能或CI/CD工具，而非原始上游源代码库的情况。上个月，Click Studios（许多财富500强企业都在使用的Passwordstate企业密码管理器的制造商）向客户通报了一起供应链攻击事件。攻击者破坏了Passwordstate的“就地升级功能”，向Passwordstate用户分发恶意更新。

非法更新包含一个修改过的DLL文件，名为Moserware.SecretSplitter.dll，其一小部分如下所示：

Click Studios在一份安全公告中指出：在关闭之前，该漏洞存在了大约28个小时。据悉，只有在上述时间段内执行就地升级的客户才会受到影响。Passwordstate的手动升级不会受到影响。受影响客户的密码记录可能已被获取。

不出所料，针对Click Studios用户的网络钓鱼攻击很快接踵而至，攻击者在这些电子邮件中放置了指向更新恶意软件版本的非法链接。

除了技术方面（即升级过程被篡改），这次供应链攻击还涉及社会工程方面。在超过300MB大小的伪造升级压缩文件中，我发现攻击者设法修改了用户手册、帮助文件和PowerShell构建脚本，使其指向恶意内容分发网络 (CDN) 服务器：

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

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

这种攻击的社会工程方面还显示了另一个弱点：人类（尤其是新开发人员或软件用户）可能并不总是怀疑内容分发网络（CDN）的链接，无论这些链接是否可疑。这是因为软件应用程序和网站会合法使用CDN来分发更新、脚本和其他内容。

在线信用卡盗刷攻击（如Magecart）是此类供应链攻击的另一个例子。在某些攻击中，亚马逊 CloudFront CDN 存储桶被攻破，从而将恶意JavaScript代码传播到依赖此类CDN的更多网站。

3. 依赖混淆攻击

2021年，任何关于供应链攻击的文章都不能不提到依赖混淆，尤其是因为这种攻击的简单化和自动化性质。由于在多个开源生态系统中发现的固有设计缺陷，依赖关系混淆攻击只需攻击者付出极少的努力就能以自动化的方式生效。

简单地说，如果您的软件构建使用了内部创建的私有依赖项，而该依赖项并不存在于公共开源资源库中，那么依赖项混淆（或命名空间混淆）就会起作用。攻击者可以在公共软件源上注册一个版本号更高的同名依赖项。这样，攻击者版本号较高的（公共）依赖项就很有可能被拉入您的软件构建中，而不是您的内部依赖项。

依赖混淆弱点的例证困扰着多个生态系统

通过在PyPI、Npm和RubyGems等常用生态系统中利用这个简单的弱点，黑客Alex Birsan成功入侵了35家大型科技公司，并获得了超过13万美元的漏洞赏金奖励。

在Birsan的研究披露后几天，成千上万个依赖性混乱的山寨软件包开始涌入PyPI、Npm和其他生态系统。

有多种方法可以解决依赖关系混乱的问题，包括在攻击者之前在公共软件源上注册（保留）所有私有依赖关系的名称，以及使用自动化解决方案，如软件开发生命周期（SDLC）防火墙，防止相互冲突的依赖关系名称进入供应链。

开源软件源的所有者可以采用更严格的验证流程，并在适当的地方执行命名/范围界定。例如，要在“CSO”命名空间或范围下发布软件包，开源资源库可以验证上传软件包的开发人员是否有权以“CSO”的名称上传软件包。

Java组件资源库Maven Central采用了一种简单的基于域的验证方法来验证命名空间所有权，这种做法很容易被其他生态系统效仿。

同样，发布到Go软件包仓库的软件包也是以其GitHub仓库的URL命名的，这使得依赖关系混淆攻击更具挑战性，甚至完全不可能。

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

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

2021年1月，Mimecast披露其客户用于与Microsoft 365 Exchange服务建立连接的证书遭到泄露，可能影响约10%的Mimecast用户的通信。虽然Mimecast没有明确证实这是否是SSL证书，但一些研究人员根据事实推测，实际情况大致如此。

SSL证书泄露固然有问题，但代码签名证书（即私钥泄露）被盗会对软件安全造成更广泛的影响。拿到私有代码签名密钥的攻击者有可能将其恶意软件签名为信誉良好的公司提供的正版软件程序或更新。

尽管Stuxnet仍是一个复杂攻击的重要案例，攻击者利用从两家知名公司窃取的私有密钥将其恶意代码签署为“可信”，但此类攻击在Stuxnet之前就已盛行，甚至在多年后仍在继续。这也是前面提到的HashiCorp在Codecov供应链攻击中暴露GPG私钥的例子存在问题的原因。虽然目前还没有迹象表明HashiCorp被泄露的密钥被攻击者滥用来签署恶意软件，但在被泄露的密钥被撤销之前，这种事件确实有可能发生。

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

Sonatype最近观察到一种多方面的软件供应链攻击，这种攻击不仅依赖于向用户的GitHub项目引入恶意拉取请求，而且还滥用GitHub的CI/CD自动化基础架构GitHub Actions来挖掘加密货币。GitHub Actions为开发人员提供了一种为托管在GitHub上的软件仓库安排自动化CI/CD任务的方法。

攻击者通过克隆使用GitHub Actions的合法GitHub仓库，稍微修改仓库中的GitHub Action脚本，然后向项目所有者提交拉取请求，将这一修改合并回原始仓库。

攻击者（edgarfox1982）向合法项目所有者提交拉取请求以合并更改的代码

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

这种攻击一石二鸟：它可以诱使开发人员接受恶意拉取请求，如果拉取请求失败，它还可以滥用现有的自动化CI/CD基础设施来进行恶意活动。

同样，研究人员之所以能成功入侵联合国（UN）域并访问10万多条联合国环境规划署（UNEP）员工记录，主要是因为他们在这些域上发现了暴露的Git文件夹和 "git-credentials "文件。获得Git凭据访问权限的威胁行为者不仅可以克隆私有Git资源库，还有可能在上游引入恶意代码，引发供应链攻击，从而造成更严重的后果。

防范供应链攻击的主要重点是向开发人员推荐安全编码实践或在开发环境中使用DevSecOps自动化工具。然而，确保CI/CD管道（如Jenkins服务器）、云原生容器以及辅助开发人员工具和基础设施的安全现在变得同样重要。

6. 利用社交工程投放恶意代码

安全专家都知道，安全的强度取决于最薄弱的环节。由于人的因素仍然是最薄弱的环节，因此漏洞利用可能来自最意想不到的地方。最近，Linux基金会禁止了明尼苏达大学的研究人员，因为他们提出了故意制造漏洞的“补丁”，而这些“补丁”反过来又在Linux内核源代码中引入了漏洞。

虽然这一事件已被发现，并已得到处理，但它说明了几个简单的事实：开发人员精力分散，不一定有足够的带宽来审查每一个代码提交或提议的代码变更，因为它们可能存在漏洞或完全是恶意的。更重要的是，社交工程可能来自最不值得怀疑的来源，在这个案例中，使用“.edu”电子邮件地址的大学研究人员看起来是可信的。

另一个最近的例子包括，任何为GitHub项目做出贡献的合作者都可以在发布之后修改发布版本。同样，项目所有者的期望是，大多数贡献者都能真诚地为项目提交代码和提交内容。只要有一个合作者叛变，就会危及许多人的供应链安全。

在过去的一年中，创建错别字抢注和品牌劫持软件包的攻击者多次以开源开发者为目标，在他们的上游构建中引入恶意代码，然后传播给许多用户。

所有这些真实案例都展示了威胁行为者在成功的供应链攻击中采用的不同弱点、攻击载体和技术。随着这些攻击不断演变并带来挑战，在处理软件安全问题时需要更多创新的解决方案和策略。