最近软件供应链事件屡屡成为头条新闻。尽管这些安全事件有相似之处，但并非所有的供应链攻击都是一样的。
“软件供应链攻击”这个统称涵盖了攻击者干扰或劫持软件制造过程（软件开发生命周期）的任何情况，从而使最终的产品或服务的多个消费者受到不利影响。当软件构建中使用的代码库或单个组件被污染、软件更新二进制文件被植入木马、代码签名证书被窃取，甚至托管软件即服务（SaaS）的服务器被闯入时，都可能会发生供应链攻击。
对于任何软件供应链攻击，攻击者潜伏于供应链上游或中游，导致其恶意活动及后续影响波及下游的许多用户。因此，与孤立的安全攻击相比，成功的供应链攻击规模大得大，影响也深远得多。
任何代码存储库或库都可能含有恶意代码，尽管我们努力监视并删除可疑的软件包。虽然像GitHub这样的代码存储库正在采取积极的措施，防止恶意软件进入其网站，但攻击者正在想方设法，将其代码成功地分发给毫无戒备的开发人员。
这个问题越来越严重。Phylum公司的《2023年第三季度软件供应链安全演变报告》显示，大多数类别的可疑软件包都有所增加。在扫描的300万个软件包中，1万多个文件引用了已知的恶意URL。近86000个软件包含有预编译的二进制文件，这使得它们很难扫描出恶意软件。另有5500个软件包企图混淆其代码，还有5000个软件包是作者用一次性电子邮件帐户注册的。
更重要的是，报告显示了攻击手法上的转变，更多的恶意软件编写者瞄准特定的公司，而不是采取更广泛的方法。近1000个恶意软件包针对特定组织或企业，比2023年第二季度猛增47.4%。这些针对性攻击的目标包括收集凭据、窃取源代码或知识产权。
开发人员似乎并没有通过安全实践提高软件供应链的安全性。Phylum特别指出，开发人员每周从JavaScript软件包注册中心npm下载大约240亿个软件包，但几乎没有人验证所下载代码的完整性。报告称，攻击者知道这一点，这可能会鼓励他们在未来发起更广泛的活动，比如大规模勒索软件攻击或僵尸网络。
下面我们分析最近实际的成功软件供应链攻击中使用的六种不同技术。
就大多数软件供应链攻击而言，攻击者入侵上游服务器或代码仓库，并注入恶意载荷（比如一行恶意代码或被植入木马的更新版），然后载荷被分发到下游的许多用户。然而从技术的角度来看，实际情况并非始终如此。
Codecov供应链攻击就是这样一个例子。虽然这起事件与SolarWinds事件相似，但两种攻击还是存在显著的差异。SolarWinds供应链攻击是复杂攻击者的杰作，他们篡改了合法的更新二进制文件：SolarWinds.Orion.BusinessLayer.dll，这是SolarWinds IT性能监控产品Orion的一部分。
正如FireEye之前所分析，这个假冒DLL的RefreshInternal()方法中所含的恶意代码如下所示。当Orion加载Inventory Manager插件时，这种方法调用基于HTTP的后门。
图1. 被植入后门的DLL的版本2019.4.5200.9083，附有恶意的RefreshInter
然而，只有当被篡改的二进制文件一路进入到下游的18000多个SolarWinds Orion客户（包括政府部门），SolarWinds上游攻击才完全发威。
然而以Codecov为例，没有恶意代码向下游分发，但攻击的余波却向下游波及。按照官方的安全公告，Codecov攻击者从有缺陷的Docker镜像创建过程获得了凭据，可以用来篡改Codecov Bash Uploader。攻击者随后篡改托管在其Codecov服务器上的Codecov Bash Uploader本身，以收集从客户的持续集成/持续交付（CI/CD）环境上传的环境变量：
图2. 被篡改的一行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也披露受到了这起攻击的一些影响，其他公司纷纷披露类似的情况。
术语“中游”在这里主要指攻击者破坏中间软件升级功能或 CI/CD工具而非原始上游源代码库的情况。近日，Click Studios通知客户遭到了供应链攻击，这家公司开发的Passwordstate企业密码管理器被许多《财富》500强公司所使用。攻击者破坏了Passwordstate的“原地升级功能”，将恶意更新分发到Passwordstate用户。
非法更新含有一个经过篡改的DLL文件，文件名为Moserware.SecretSplitter.dll，其一小部分如下所示：
Click Studios在安全公告中表示：“攻击持续了大约28小时才被关闭。只有在此时间段内执行原地升级的客户才受到影响。手动升级Passwordstate 并不受到攻击。受影响的客户密码记录可能已被收集。”
不出所料，此后就发生了针对Click Studios 用户的网络钓鱼攻击，攻击者将指向更新后的恶意软件版本的非法链接放入到这些电子邮件中。
除了涉及技术方面（比如升级过程被篡改）外，这起供应链攻击还涉及社会工程方面。在一份大小超过300 MB的伪造的更新zip文件中，研究人员发现，攻击者设法更改了用户手册、帮助文件和PowerShell构建脚本，以指向其恶意内容分发网络（CDN）服务器：
图5. 阐明恶意CDN服务器为官方CDN服务器的帮助手册文档之一。
图6. 含有恶意CDN服务器链接的PowerShell安装脚本。
这起攻击的社会工程方面还表明了另一个弱点：人类（尤其是新手开发人员或软件消费者）可能并不总是怀疑内容分发网络（CDN）链接，无论这些链接是否真的可疑。这是由于CDN被软件应用程序和网站合法用于提供更新、脚本及其他内容。
Magecart等在线信用卡窃取攻击是这类供应链攻击的另一个例子。在一些攻击中，Amazon CloudFront CDN存储桶受到攻击，将恶意JavaScript代码分发到数量更多的依赖这类CDN的网站。
2021年，说到供应链攻击免不了提及“依赖项混淆”，特别是由于这种攻击的简单化和自动化特性。由于多个开源生态系统存在固有的设计缺陷，依赖项混淆攻击不需要攻击者花多大的力气，就能自动执行。
简而言之，如果您的软件构建使用私有的、内部创建的依赖项，该依赖项在公共开源代码存储库中又不存在，依赖项混淆（或命名空间混淆）就会起作用。攻击者能够在公共代码存储库上以相同的名称注册版本号更高的依赖项。然后，攻击者创建的拥有更高版本号的公共依赖项（而不是您的内部依赖项）很有可能被拉入到软件构建中。
图7. 困扰多个生态系统的依赖项混淆弱点。
利用 PyPI、npm和RubyGems等常用生态系统中的这个简单弱点，道德黑客Alex Birsan 成功地入侵了35家大型科技公司，为此获得了超过130000美元的漏洞赏金。
在Birsan的研究成果披露几天后，成千上万个依赖项混淆山寨软件包开始涌入PyPI、npm 及其他生态系统。虽然其中大多数山寨软件包由其他志在必得的漏洞赏金猎人创建，但其中一些甚至恶意攻击知名公司。
有多种方法可以解决依赖项混淆，包括在攻击者之前抢先在公共代码存储库上注册（预留）你的所有私有依赖项的名称，并使用自动化解决方案，比如软件开发生命周期（SDLC）防火墙，以防止冲突的依赖项名称进入到供应链中。
此外，开源代码存储库的所有者可以采用更严格的验证过程，并实施命名空间/范围界定。比如说，如果想要在“CSO”命名空间或范围下注册依赖项，开源代码存储库可以验证上传软件包的开发人员是否有权以“CSO”之名来上传。
Java 组件代码存储库Maven Central采用了一种简单的基于域的验证方式来验证命名空间所有权——这种做法很容易被其他生态系统所仿效。
同样，发布到Go软件包存储库的软件包以指向其GitHub代码存储库的URL命名，从而使得依赖项混淆攻击即使并非完全不可行，至少难度大大加大。
随着HTTPS网站不断增加，SSL/TLS证书现在无处不在，保护你的在线通信。因此，SSL 证书私钥泄露可能会危及端到端加密连接为最终用户提供的安全通信和保证。
2021年1月，Mimecast披露其客户用于建立与Microsoft 365 Exchange服务连接的证书遭到了破坏，可能影响约10%的Mimecast用户。虽然Mimecast没有明确证实这是不是SSL证书，但正如一些研究人员所怀疑的那样，情况似乎基本属实。
虽然受攻击的SSL证书问题严重，但被盗的代码签名证书（即受攻击的私钥）会对软件安全产生更广泛的影响。获得代码签名私钥的攻击者可能会签名其恶意软件，冒充由信誉良好的公司交付的真实的软件程序或更新。
虽然Stuxnet仍然是一例典型的复杂攻击——攻击者使用了从两家知名公司窃取的私钥将其恶意代码签名为“受信任代码”，但这类攻击早在Stuxnet之前就已盛行，甚至在Stuxnet之后多年仍在盛行。这也解释了前面提到的HashiCorp的GPG私钥在Codecov供应链攻击中泄露这个例子为什么事关重大。虽然目前还没有迹象表明HashiCorp的泄露密钥被攻击者滥用以签名恶意软件，但除非泄露的密钥被吊销，否则这类事件确实有可能发生。
Sonatype最近观察到一起多管齐下的软件供应链攻击：不仅依赖向用户的GitHub项目引入恶意合并请求，还滥用了GitHub的CI/CD自动化基础设施GitHub Actions来挖掘加密货币。GitHub Actions为开发人员提供了一种为GitHub上托管的代码存储库安排处理自动化CI/CD任务的方法。
攻击包括攻击者克隆了使用GitHub Actions的合法GitHub代码存储库，对代码存储库中的GitHub Actions 脚本稍加改动，并向项目所有者提交合并请求，以便将此变更合并回到原始代码存储库中。
图8. 攻击者（edgarfox1982）为合法项目的所有者提交合并请求，以合并更改后的代码。
如果项目所有者随意批准更改的合并请求，供应链攻击就会得逞，而这甚至不是这里的前提。恶意合并请求含有对ci.yml的修改，一旦攻击者提交合并请求，GitHub Actions 就会自动运行这些修改。修改后的代码实际上滥用GitHub的服务器来挖掘加密货币。
这种攻击可谓是一举两得：它诱使开发人员接受恶意合并请求，如果开发人员未接受，它就滥用现有的自动化CI/CD基础设施从事恶意活动。
同样，研究人员之所以成功地闯入联合国域名，并访问了10多万条联合国环境规划署员工记录，主要是由于他们在这些域名上发现了暴露的Git文件夹和“git凭据”文件夹。获得Git凭据访问权限的攻击者不仅可以克隆私有Git代码存储库，还可能在上游引入恶意代码以触发供应链攻击，从而酿成极严重的后果。
对于想要阻止供应链攻击的那些人来说，注意力主要放在向开发人员推荐安全编码实践或在开发环境中使用DevSecOps 自动化工具。然而，为CI/CD 管道（比如Jenkins服务器）、云原生容器以及补充性的开发者工具和基础设施确保安全现在也变得同样重要。
任何安全专业人员都知道，安全取决于最薄弱的环节。由于人为因素仍然是最薄弱的环节，因此威胁可能来自最意想不到的地方。最近，Linux基金会封杀了明尼苏达大学的研究人员，起因是他们提议故意有缺陷的“补丁”，而这些“补丁”进而在Linux内核源代码中引入了漏洞。
虽然该事件被发现，现已得到了处理，但它表明了几个简单的事实：开发人员分散在各处，没有足够的能力来审核提交的每个代码或提议的代码变更，它们可能存在缺陷或完全是恶意的。更重要的是，社会工程学可能来自最不受怀疑的来源——这里来自电子邮件地址使用“.edu”后缀的看似可靠的大学研究人员。
另一个近期的例子包括任何为GitHub项目贡献代码的合作者在即便发布后都可以更改版本。项目所有者以为，大多数贡献者真诚地为其项目提交代码。但只要一个合作者不守规矩，就会损害许多人的供应链安全。
在过去一年中，攻击者创建了误植域名和品牌劫持软件包，一再针对开源开发人员，在其上游构建中引入恶意代码，然后传播给众多使用者。
所有这些实际的例子都表明了威胁分子在成功的供应链攻击中采用了不同的漏洞、攻击途径和技术。随着这些攻击不断变化并带来挑战，在对待软件安全时，需要更多的创新解决方案和策略。
本文翻译自：https://www.csoonline.com/article/570743/6-most-common-types-of-software-supply-chain-attacks-explained.html如若转载，请注明原文地址
本文链接：http://www.28at.com/showinfo-26-19018-0.html详解六种最常见的软件供应链攻击
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
