1. 历史上最大的勒索软件攻击
7月2日勒索组织REvil，攻击了一家来自瑞典的IT管理服务提供商(managed service providers(MSP)) – Kaseya。
Kaseya的VSA(虚拟系统管理)是一个基于云的管理服务提供商(MSP)平台，该平台为客户提供了一套基于Web的新一代自动化IT系统管理解决方案。MSP通过建立自己的 络运作中心(Network Operating Center(NOC))来为企业提供 24×7×365 的系统管理服务的业务。MSP可以实现对客户的IT系统的进行远程的管理、实时的监控、对企业系统运作情况进行统计，以及执行补丁管理等。
Kaseya在全球已经拥有了超过10000家客户，其中包括50%以上的全球100强IT管理服务提供商及各大龙头企业，分别来自银行业、金融业、零售业、贸易业、教育机构、政府机构、医疗机构和交通运输业等领域。全球有超过1300万台以上的终端和设备通过Kaseya的软件进行管理。
REvil利用零日漏洞(CVE-2021-30116)攻陷MSP平台之后，向VSA内部推送了恶意更新，在企业 上部署了勒索软件，导致Kaseya遭受工具链攻击。REvil宣称锁定了超过一百万个系统，并愿意就通用解密器进行谈判，起价为7000万美元，这是迄今为止开价最高的赎金。
图中的相关定义
| 术语 | 描述 | 举例 |
|---|---|---|
| 中间件(Artifact) | 是一个不可变的数据块，主要指软件的中间件，但可以用于任何类型的中间件. | 文件、git提交、文件目录（以某种方式序列化）、容器映像、固件映像. |
| 源(Source) | GitHub（平台）上的Git提交（源代码）. | |
| 构建(Build) | 将一组输入的中间件转换为一组输出中间件的过程。输入可以是源、依赖项或短暂的构建输出. | travis CI（平台）运行.travis.yml（进程）. |
| 包(Package) | 为他人使用而发布的中间件。在本模型中，它始终是构建过程的输出，尽管该构建过程可以是无操作的. | 分发在DockerHub（平台）上的Docker映像（包）. |
| 依赖(Dependency) | 作为构建过程的输入但并不是源的中间件。在模型中，它始终是一个包. | 分布在Alpine Linux（平台）上d的Alpine包（package）. |
-
特例:
- 包含源码的zip包是一个包，不是源。因为这个文件是由其他源码构建产生的。例如一个git提交的zip文件.
-
开发过程供应链威胁描述
| 威胁 | 案例 | SLSA 的消减措施 | |
|---|---|---|---|
| A | 将恶意代码提交到代码仓 | Linux 恶意提交: 研究人员通过邮件列表补丁的方式，故意将缺陷引入到Linux内核. | |
| B | 源码管理平台泄漏 | PHP: 攻击者攻破了PHP的git托管服务器，并注入了两个恶意提交. | 一个更安全的保护源码平台将使攻击者更难攻击. |
| C | 篡改参与构建的源码 | Webmin: 攻击者篡改了构建的基础源码. | 一个符合SLSA的构建服务器会识别实际使用的源代码，从而允许使用者检测此类篡改. |
| D | 构建平台泄漏 | SolarWinds: 攻击者攻破构建平台，安装了一个植入程序在每次构建过程中注入恶意行为. | 更高的SLSA级别需要对构建平台进行更强大的安全控制，使得被攻陷和得到控制更加困难. |
| E | 使用错误的依赖关系（即会对A到H的依赖关系，进行递归查找） | event-stream: 攻击者添加了一个无害的依赖项，然后更新该依赖项以添加恶意行为。更新与提交给GitHub的代码不匹配（即攻击F）. | SLSA会递归地应用到所有依赖项来阻止这个特定的问题，依赖的起源能够指示出问题的依赖不是由正确的生成器构建的，或者源代码不是来自GitHub. |
| F | 上传不是由CI/CD系统生成的中间件 | CodeCov: 攻击者使用泄漏的凭据将恶意中间件上传到GCS存储桶，用户可以从中直接下载. | GCS bucket中中间件的出处会显示中间件不是以预期的方式从预期的源repo构建的. |
| G | 篡改包托管到仓库 | 攻击包镜像: 研究人员为几个流行的包存储运行镜像，这些库被篡改后可能被用来提供恶意包服务. | 与上面的（F）类似，恶意中间件的出处会显示它们不是按照预期构建的，或者不是从预期的源repo构建的. |
| H | 欺骗开发者使用恶意包 | Browserify typosquatting: 攻击者上传了一个与原始文件同名的恶意软件包. | SLSA不能直接解决这个威胁，但是源代码管理的源代码链接可以启用和增强其他解决方案. |
4.3. SLSA的安全级别
中间件的SLSA级别描述了其直接供应链的完整性强度，主要有四个SLSA级别。SLSA 4是当前最高级别，代表理想的终极状态。SLSA 1–3提供较低的安全保证，但更容易满足要求。根据Google的经验，实现SLSA 4可能需要很多年和大量的努力，因此中间里程碑是重要的。
- 级别定义
| 级别 | 描述 |
|---|---|
| SLSA 1 | 要求构建过程完全脚本化/自动化，并且产生出处。 出处是关于如何构建工件的元数据，包括构建过程、顶级源代码和依赖项。知道出处允许软件消费者做出基于风险的安全决策。虽然 SLSA 1 的出处不能防止篡改，但它提供了一个代码源识别的基本级别，可能有助于漏洞管理. |
| SLSA 2 | |
| SLSA 3 | |
| SLSA 4 |
4.4. SLSA安全级别的要求
SLSA给达到每个级别定义了实现要求，具体如下：
5. 总结
- 供应链攻击正成为危害最大的 络威胁之一，且发生的频率正在上升；
- 供应链攻击由于拥有上游的正式发布渠道和有效的签名，作为下游的使用者防范困难；
- 作为软件的开发者，在做好开源软件缺陷的管理之外，还要提高自身的风险管理能力，能够识别开发过程中恶意的变动，并触发追查和防范措施；
- Google的SLSA供应链完整性框架，全面的考虑了供应链的各个环节可能引入的安全威胁，提供了防止供应链攻击的一种有效的方法；
- Google的SLSA供应链完整性框架，可以成为我们开发过程中防范供应链攻击的一个很好的借鉴；
6. 参考
- 微软安全供应链攻击
- Google:IntroducingSLSA,anEnd-to-EndFrameworkforSupplyChainIntegrity
- 2021-07-05勒索组织REvil发起供应链攻击，索要7000万美元赎金
- 2021-03-07大规模供应链攻击攻陷了数家航空公司
- 2020-12-16SolarWinds旗下软件被用于供应链攻击事件分析
- 洞见RSA2021｜备受热捧的“供应链攻击”如何防御li>
- 5-ways-your-software-supply-chain-is-out-to-get-you-part-5-hostile-takeover
- rsa创新沙盒盘点-apiiro-代码风险平台
- top-5-tips-to-prevent-the-solarwinds-solorigate-attack
- 解读6种最常见的软件供应链攻击类型
文章知识点与官方知识档案匹配，可进一步学习相关知识 络技能树首页概览22789 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！