8大软件供应链攻击事件概述 8大软件供应链攻击事件概述

在软件开发中所面临的新型威胁已经不仅仅与特定的公司相关，整个软件供应链的上下游都已成为攻击者的目标，因此必须保证每个环节的安全性，因为如果一个环节出现问题，一切都会受到影响。
供应链活动包括将原材料、部件和资源转化为完整产品并交付给最终客户的每一步。每个步骤本身都可能是一个复杂的过程，并且有可能导致安全事故。
什么是软件供应链攻击？我们在之前的文章中已经清楚地了解到什么是软件供应链。那么我们现在继续深入，将重点放在源代码上。
举个例子，你的源代码将存储在私有的Git仓库中，这可能是你的基础设施的一部分，也可能是供应商提供的 SaaS，还有编译器工具、基础容器镜像仓库等。而一些依赖项则托管在公开的代码库中，如 Docker Hub 或 Quay.io，可能会受到损坏。此外，我们也将我们的应用程序作为容器镜像发布在公开的代码仓库中。
那么，在供应链中其中一些组件在你的保护之下，比如你的私有源代码 git 仓库、应用程序代码本身以及最终生产出来的二进制文件或容器镜像。但许多其他的组件或服务是公开的服务和资源，或是由其他公司提供的，完全不在你的掌控范围之内。
所以软件供应链攻击可以直接瞄准你的软件，或它可以瞄准任意上游组件（比如外部的依赖项或第三方服务），进而你会成为受害者，要么直接遭受攻击，要么成为提供受损资源的供应商。
软件供应链攻击事件针对软件供应链的攻击正以每年4-5倍的速度增长，仅在2021年就发生了几千次，最常见的是与依赖项混淆或误值域名（URL劫持）有关的错误，其次是恶意源代码注入。
幸运的是，并不是每次攻击都有巨大的影响范围，下文我们将会介绍其中几个较为知名的攻击事件。CNCF还在其《供应链破坏目录》中收集了各种类型的供应链遭受攻击的事例：
【8大软件供应链攻击事件概述】https://github.com/cncf/tag-s...
CodeCov 源代码泄露具体信息：https://about.codecov.io/secu...
CodeCov是一款用于托管代码测试报告和数据的在线平台，2021年其 Docker 镜像中泄露的凭证使攻击者可以修改一个 bash 脚本。当客户下载并执行该脚本之后，客户的凭证会被泄露，进而攻击者可以访问他们的Git仓库。攻击从当年的1月31日开始，而第一个客户发现凭证遭受泄露时已是3个月之后，这意味着被入侵的软件在长达数月的时间里正常与上下游对接。Hashicorp、Confluent等多个知名企业表示受到影响。
SolarWinds 黑客攻击攻击者渗透到 SolarWinds 的网络中，并设法将恶意软件注入其构建过程。该恶意软件（与 APT29、Nobelium 有关）与 Orion（某个网络管理系统）捆绑在一起，作为产品更新的一部分分发。该 Artifact 经过数字签名，作为构建过程的一部分被数百名客户下载。
一旦恶意软件进入客户网络，攻击者就会监视并窃取他们的信息。这一事件也展示了针对供应链的攻击是如何向下游传播并影响到多个客户。作为被破坏的 Orion 软件的一部分，Mimecast（一家云网络安全服务公司）的邮件服务器的TLS证书私钥被泄露，这使得攻击者可以对邮件服务器进行中间人攻击，进而访问客户的电子邮件获得敏感信息。
我们可能永远也无法了解到 SolarWinds 攻击所产生的真正影响，因为被攻击的软件在有成千上万客户的网络中运行了数月。该事件尚未结束：SolarWinds 背后的攻击者最近仍在试图复制类似的攻击，不过是针对供应链的不同部分，如代理商和某些技术服务提供商。
Kaseya 勒索软件攻击具体信息：
https://helpdesk.kaseya.com/h...
2021年7月，远程IT服务管理软件 Kaseya 遭受勒索软件攻击，攻击者索要7000万美元。这次攻击与 SolarWinds 攻击十分类似，但这次攻击者利用 Kaseya 系统中的零日漏洞。一旦他们控制了系统，他们就可以使用VSA、远程管理和监控工具在客户的系统中执行远程命令。
大约有 50 个客户受到此次攻击的直接影响。但他们的很多客户都是托管服务提供商，专门为其他企业提供 IT 服务，所以 Kaseya CEO Fred Vocola 表示，实际受到影响的企业约达到 800 至 1500 家。
更为关键的事实是，在2017-2020年期间，Kaseya的高管多次收到警告，这些警告称产品存在严重的安全漏洞，但公司高管对此不以为意。
苹果公司的Xcode和XcodeGhost 在这次攻击中，一个合法的Xcode项目 "TabBarInteraction "的木马版本被发布在一个公开的代码仓库中。使用该项目虚假版本的开发人员在每次项目构建时都会无意中执行一个脚本，该脚本会打开与C2（命令和控制）服务器的连接。
带有恶意代码的 Xcode 的重新打包版本被上传到中国的文件托管服务。开发人员从这些镜像中下载被破坏的版本，最终得到的是一个修改过的对象文件。在创建 iOS 应用程序时，该对象文件被连接到最终的可执行文件中。至少有2个知名的应用程序成功通过了苹果的官方认证和代码审查，最终进入了AppStore。
NPM 包 ua-parser-js 2021年10月22日，阿里云安全团队监测到Npm官方仓库 ua-parser-js 疑似被恶意劫持，多个版本被攻击者植入挖矿脚本，其中包含 Linux 和 Windows 的恶意软件，并且能够窃取数据（至少是浏览器的密码和cookies）。
这个 ua-parser-js 库是众多知名软件和企业的供应链的一部分，例如 Facebook、微软、苹果、亚马逊等大型科技公司对其均有依赖。因此它会被用于面向用户的终端应用程序中，从而扩散到数百万台计算机。
Unicode 和代码编译器——看不见的漏洞剑桥大学的一些研究人员表示，他们在文本编码标准（如 Unicode）的细节中发现了一种针对源代码的新型供应链攻击。根据 Unicode 的工作方式，有可能再代码的注释或某些部分添加特殊字符，使代码的“逻辑编码”以与显示方式不同的顺序工作。这使得在一些开起来是正确的代码中隐藏恶意代码成为可能，从而绕过审查程序。但该问题并非新问题，也并不是那么隐蔽，通过建立对代码贡献者的信任并进行适当的审查来预防该类型的攻击。
Wordpress主题和插件攻击 2021年9月有研究人员发现，超过90个WordPress主题、插件被破坏，攻击者在这些组件中植入了PHP后门，使其能够完全访问网站。有超过36万个的活跃网站都在使用这些插件和主题。
据研究人员称，攻击者使用后门将访问者重定向到恶意软件投放和诈骗网站，也有可能使用该恶意软件在暗网上出售对后门网站的访问权限。
Apache Log4j 高危漏洞 2021年12月，Apache软件基金会公开 Apache Log4j2 被曝出高危漏洞，攻击者通过 JNDI 注入攻击的方式，可以远程执行任何代码。漏洞发现以来，Steam、苹果的云服务受到了影响，推特和亚马逊也遭受了攻击，元宇宙概念游戏“Minecraft我的世界”数十万用户被入侵。美联社评论称，这一漏洞可能是近年来发现的最严重的计算机漏洞。
而这一漏洞并非短时间内就能完全解决，其影响可能蔓延至未来十年。因为 Log4j2 是一个非常流行的、基于 Java 的开源日志框架，它已经被嵌入成千上万的软件包中。雪上加霜的是，Log4j经常被深深地嵌入到代码中，由于被间接的依赖项所调用而隐藏起来。
如何保障软件供应链安全针对软件供应链的攻击使得企业受攻击面在扩大，因为它们的安全性不仅取决于内部审查流程，还需要确保第三方（软件、硬件、服务等）不会成为他们被攻击的通道。
因此，不可能像传统安全一样确保所有代码、组件都是安全的，尤其是当下我们仍在不断发现新型的软件供应链攻击。
接下来，我们一起讨论一下，如果要尽可能地保护企业软件供应链，你需要把重点放在哪里。
关注软件开发中的第三方组件如果您的组织采用了来自多个供应商的构件、硬件和服务，那么需要确保这些供应商对安全都保持高度重视。
软件供应链安全正在变得如此重要，以至于2021年5月，美国总统发布了一项旨在改善国家网络安全的行政命令。此后，NIST 根据这一命令发布了《开发者软件验证最低标准指南》，其中建议了开发者验证软件的最低标准。
因为不可能实现和保证100%的安全，所以也需要你关注影响供应商的任何风险和事件，并准备好在发现或报告受破坏的组件时迅速采取纠正措施，以减少损失。
公司内部软件开发的安全意识关于代码和开发过程，上文中所提到的“最低标准指南”中建议软件开发生命周期中需要包含以下技术作为其最低的安全要求：

应用威胁模型以识别关键或潜在的被忽视的测试目标
自动化测试
基于代码的静态分析，使用代码扫描工具并且审查硬编码的密钥
动态分析、内置检查、保护措施、黑箱和模糊测试以及网络应用扫描工具等
对于供应链中的软件进行相似性检查（包括第三方依赖项）
尽快修复重要漏洞

随着基础设施即代码（IaC）的出现，软件供应链中的威胁现在有可能针对软件、应用程序以及底层基础设施。同样的软件验证原则应适用于部署和管理作为代码的基础设施，实现“安全左移”。
仅确保代码和开发过程的安全是远远不够的，还需要让安全必须在所有的开发阶段和公司文化及实践中普遍存在。
CNCF社区保留了一份实时更新的、由社区维护的文件，软件供应链安全文件。该文件旨在通过“一系列推荐的实践、工具选项和设计考虑，来减少供应链攻击的可能性和整体影响”，为社区做出贡献。
文件地址：
https://github.com/cncf/tag-s...
此外，CNCF、Linux基金会、VMWare、英特尔、谷歌和其他机构也在研究 SLSA，这是一个软件供应链安全框架，用于提高软件的安全性和供应链的完整性，可以供任何开发软件的人使用。该框架中的每个级别都提供了越来越高的信任度，说明软件没有被篡改，可以安全地追溯到它的来源。
Kubernetes 和容器在企业中应用也十分广泛，NSA/CISA 发布了 Kubernetes加固指南，强调“供应链风险”是三个泄露源之一，并提出了以下加固措施和缓解办法：

扫描容器和Pod的漏洞或错误配置
以尽可能小的权限运行容器和Pod
使用网络隔离来控制恶意破坏可能造成的损害程度
最后，借助防火墙限制不需要的网络连接和加密以保护机密性
使用强大身份认证和验证来限制用户和管理员的访问并修改攻击面
最后，使用日志审计使管理员可以监控活动并且在发现潜在的恶意行为时收到告警
周期性检查所有 Kubernetes 设置并且使用漏洞扫描来帮助确定风险等级，并应用安全补丁

你的软件需要对下游安全负责当你在选择供应商时，你应该意识到你不仅仅是为自己选择，也是在为你的客户、终端用户进行选择。因此，即使你在软件供应链生命周期的每个步骤和流程中都严格地实施了安全策略，你仍然需要将其表现出来并为交付的产品添加具体的安全措施：

提供您的组织内适用于软件供应链的监管合规性和安全认证的证据
增加一个软件材料清单（SBOM），以跟踪软件中的依赖项和第三方损害源
包括数字签名，以防止篡改和验证你的工件来源
使用安全的分发渠道、加密的通信和可信的托管或存储基础设施

总结软件供应链攻击并非新兴事物。在1984年与丹尼斯·里奇一起获得图灵奖后，肯·汤普森写了一篇关于信任代码提供商的重要性的演讲。他展示了一个木马化的编译器二进制版本如何产生带有后门的 “login” Unix命令的修改版本。
“人们应该在多大程度上相信一个程序没有特洛伊木马的声明？也许相信编写软件的人更重要。”
随着软件、基础设施和依赖项的复杂性不断增加，以及针对供应链的攻击事件在指数级增长，使得各行业和组织越来越关注软件供应链的安全性。
你应该已经意识到软件供应链是一个极其复杂的网络，从代码和库到硬件组件，都是相互连接但本质不同的事物。因此，确保每一个单件和环节安全性的方法是不同的，不能作为一个统一的整体来对待。
无论你是甲方还是乙方，是终端用户还是服务提供商，你都需要专注于保护你的流程，并且与可信任的、经过验证的供应商建立强大的联系。因为即使你采纳了最佳的安全实践，并在代码、基础设施等方面投入了全部精力，你仍然依赖于完全不受控制的第三方组件。而软件供应链的安全取决于每一个单独的环节。