并非所有的软件供应链攻击都是一样的。以下是攻击者目前如何利用第三方来破坏合法软件。近日，软件供应链事件频频登上头条，引起社会各界广泛关注。尽管这些安全事件之间有许多相似之处，但事实是并非所有供应链攻击都是一样的。总称“供应链攻击”涵盖了攻击者干扰或劫持软件制造过程（软件开发生命周期）的任何情况，从而对成品或服务的许多消费者产生不利影响。当代码库或软件构建中使用的单个组件被感染、软件更新二进制文件被木马化、代码签名证书被盗，甚至托管软件即服务(SaaS)的服务器受到损害时，就会发生供应链攻击。与任何软件供应链攻击一样，攻击者进入上游或中游，将他们的恶意活动及其后果传播给下游的众多用户。因此，与孤立的安全漏洞相比，成功的供应链攻击往往规模更大、影响更深远。以下是现实世界中成功的软件供应链攻击常用的6种关键技术：供应链攻击示例1.上游服务器妥协——Codecov攻击对于大多数软件供应链攻击，攻击者会危及上游服务器或代码存储库并注入恶意软件有效载荷（例如，恶意代码行或木马更新）。然后将此有效负载分发给下游的众多用户。然而，从技术角度来看，情况并非总是如此。Codecov供应链攻击就是这样的一个例子。尽管该事件与SolarWinds攻击之间存在相似之处，但两次攻击之间存在明显差异。SolarWinds供应链漏洞是技术娴熟的威胁行为者所为，他们更改了合法的更新二进制文件SolarWinds.Orion.Core.BusinessLayer.dll，它是SolarWindsIT性能监控产品Orion的一部分。FireEye之前分析过，伪造DLL的RefreshInternal()方法中包含的恶意代码如下所示。当Orion加载InventoryManager插件时，此方法会调用基于HTTP的后门：带有恶意RefreshInternal方法的后门DLL版本2019.4.5200.9083但是，只有当修改后的二进制文件向下游传播到包括美国政府机构在内的组织时，SolarWinds上游攻击才不会直到超过18,000名SolarWindsOrion客户全面生效。在Codecov攻击的案例中，并没有向下游分发恶意代码，但实际发生了攻击的后果。根据官方安全公告，黑客利用Codecov的Docker镜像创建过程中的错误，非法获取其BashUploader脚本的访问权限，并对其进行修改，以从客户的持续集成/持续交付(CI/CD)环境中收集数据。上传的环境变量：虽然CodecovBashUploader脚本在Codecov[.]io/bash中的Codecov服务器本身存在（并将继续存在），但成千上万的存储库已经指向此链接以从上游发送的CI/CD环境导入信息到这个BashUploader。因此，恶意代码仅存在于（受损的）上游服务器上，没有发生任何下游代码分发，因为所谓的下游存储库已经指向托管Bash上传器脚本的Codecov服务器。然而，这些下游存储库也受到了攻击的影响，因为它们被配置为将数据上传到Codecov的Bash上传器：事实上，据报道，Codecov攻击者破坏了数百个客户网络。开源编程工具和保险箱制造商HashiCorp最近也披露了Codecov供应链攻击导致其GPG签名密钥泄露。2.中游妥协传播恶意更新这里的“中游”主要是指攻击者破坏中间软件升级功能或CI/CD工具而不是原始上游源代码存储库的情况。4月，许多财富500强公司使用的Passwordstate企业密码管理器的制造商ClickStudios通知客户，攻击者已经破坏了Passwordstate的升级机制，并使用它在用户的计算机上安装恶意文件。它的文件名为“moserware.secretsplitter.dll”，其中的一小部分如下所示：在安全公告中，ClickStudios表示攻击持续了大约28小时后才被关闭。只有在此期间执行过一键升级的客户才会受到影响。Passwordstate的手动升级不会受到影响。受影响的客户密码记录可能已被收集。不出所料，Passwordstate攻击之后是针对ClickStudios用户的网络钓鱼攻击，攻击者在这些网络钓鱼电子邮件中放置了指向较新恶意软件版本的非法链接。除了具有技术元素（例如被篡改的升级过程）之外，这种供应链攻击还具有社会工程元素。在一个超过300MB的虚假更新zip文件中，安全研究人员发现攻击者已经设法更改用户手册、帮助文件和PowerShell构建脚本以指向他们的恶意内容分发网络(CDN)服务器：阐明恶意CDN服务器一个PowerShell安装包含指向官方帮助手册文档之一的恶意CDN服务器链接的脚本这种攻击的社会工程还说明了另一个弱点：人类（尤其是新手开发人员或软件消费者）可能并不总是对内容分发网络(CDN)持怀疑态度链接，无论它们是否真的可疑。这是因为软件应用程序和网站通常使用CDN来传送更新、脚本和其他内容。Magecart等在线信用卡盗窃攻击是此类供应链攻击的另一个例子。在某些攻击中，AmazonCloudFrontCDN存储桶遭到破坏，将恶意JavaScript代码分发到更多依赖此类CDN的网站。3.依赖混淆（dependencyconfusion）攻击2021年，提到供应链攻击，就不得不提“依赖混淆”，尤其是因为这种攻击的简单性和自动化，越来越受到攻击者的青睐。由于在多个开源生态系统中发现了固有的设计缺陷，依赖混淆在攻击者端以最小的努力甚至自动化工作。简而言之，如果您的软件构建使用私有的、内部创建的依赖项，而这些依赖项在公共开源存储库中不存在，那么依赖项混淆（或命名空间混淆）就会发挥作用。攻击者能够在公共存储库上以相同的名称注册具有更高版本号的依赖项。然后，很有可能，攻击者创建的具有更高版本号的（公共）依赖项——而不是您的内部依赖项——将被拉入您的软件构建中。依赖混淆攻击示意图今年2月，通过利用PyPI、npm和RubyGems等常用生态系统中的这个简单缺陷，道德黑客AlexBirsan成功入侵了35家大型科技公司，利用漏洞获得了超过130,000美元的赏金奖励。在Birsan的研究被披露几天后，数以千计的依赖混淆包开始涌入PyPI、npm和其他生态系统。虽然大多数模仿包是由其他有抱负的漏洞赏金猎人创建的，但仍然存在一些恶意行为者。有很多方法可以解决依赖混淆问题，包括在攻击者之前抢先在公共存储库上注册所有（您的）私有依赖项的名称；并使用自动化解决方案，例如软件开发生命周期(SDLC)防火墙，以防止冲突的依赖项名称进入您的供应链。此外，开源存储库的所有者可以采用更严格的验证过程并强制执行命名空间/范围界定。例如，如果想要在“CSO”命名空间、范围下注册依赖项，开源存储库可以首先验证注册开发人员是否有权以“CSO”名称这样做。Java组件存储库MavenCentral使用简单的基于域的验证来验证命名空间所有权——一种可以很容易地被其他生态系统建模的实践。4.被盗的SSL和代码签名证书随着HTTPS网站的兴起，SSL/TLS证书已无处不在，以保护您的在线通信。因此，SSL证书私钥的泄露可能会威胁到端到端加密连接为最终用户提供的安全通信和保证。2021年1月，Mimecast披露其客户用于与Microsoft365Exchange服务建立连接的证书已被盗用，可能会影响大约10%的Mimecast用户的通信。虽然Mimecast没有明确确认它是否像一些研究人员所怀疑的那样是SSL证书，但在很大程度上似乎是这样。虽然受损的SSL证书会产生影响，但被盗的代码签名证书（即受损的私钥）对软件安全具有更广泛的影响。获得私人代码签名密钥的攻击者可以将他们的恶意软件签名为正版软件程序或由知名公司提供的更新。尽管“Stuxnet”事件至今仍是复杂攻击的一个重要例子，攻击者使用从两家著名公司窃取的私钥将其恶意代码标记为“可信”——但此类攻击早在Stuxnet之前就很普遍，并且仍在在Stuxnet之后的今天流行。这也解释了为什么前面提到的Codecov供应链攻击中HashiCorp的GPG私钥泄露事件备受关注。虽然目前还没有迹象表明HashiCorp的泄露密钥被攻击者滥用来签署恶意软件，但这种事件肯定有可能在泄露的密钥被撤销之前发生。5、面向开发者的CI/CD基础设施如今，软件供应链攻击盛行，这些攻击不仅依赖于向用户的GitHub项目引入恶意拉取请求，还滥用GitHub的CI/CD自动化基础设施GitHubActions来挖掘加密货币。GitHubActions为开发人员提供了一种为GitHub上托管的存储库安排自动化CI/CD任务的方法。攻击方式主要是攻击者克隆一个使用GitHubActions的合法GitHub仓库，对仓库中的GitHubAction脚本稍作改动，然后向项目所有者提交拉取请求，将此改动合并回原仓库。攻击者(edgarfox1982)为合法的项目所有者提交拉取请求以合并更改的代码如果项目所有者任意批准更改的拉取请求，那么供应链攻击就成功了，后果远不止于此。恶意拉取请求包含对ci.yml的修改，一旦攻击者提交拉取请求，GitHubActions就会自动运行这些修改。修改后的代码实质上是滥用GitHub的服务器来挖掘加密货币。这种攻击一箭双雕：它诱使开发人员接受恶意拉取请求，如果失败，它会滥用现有的自动化CI/CD基础设施进行恶意活动。2021年1月，樱花武士安全人员在研究联合国漏洞披露计划范围内的资产安全漏洞时，发现了一个暴露大量Git账户信息的ilo.org子域，从而成功黑掉了联合国(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如有转载，请注明原文地址。
