供应链攻击的防范

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万美元,这是迄今为止开价最高的赎金。

  • REvil频繁作案:
    • 2020年5月,REvil声称破译了唐纳德·特朗普公司用于保护其数据的椭圆曲线密码术,并为他们盗窃的数据索要4200万美元的赎金。

    • 2021年3月18日,REvil附属公司在网络上声称,他们已从跨国硬件和电子公司宏碁安装勒索软件并盗取大量数据,并为此索取5000万美元的赎金。

    • 2021年3月27日,REvil攻击哈里斯联盟,并在其博客上发布了联盟的多份财务文件。

    • 2021年4月,REvil窃取了广达电脑即将推出的苹果产品的计划,并威胁要公开发布这些计划,除非他们收到5000万美元作为赎金。

    • 2021年5月30日,全球最大肉类供应商JBS受到REvil勒索软件的攻击,该公司不得不将所有美国牛肉工厂暂时关闭,并中断了家禽和猪肉工厂的运营。最终,JBS还是向REvil支付了1100万美元的比特币赎金。

    • 2021年6月11日,全球再生能源巨擘Invenergy证实其作业系统遭到了勒索软件的攻击,REvil声称对此事负责。

2. 近来供应链攻击频繁

  • 2020/12,SolarWinds旗下软件被用于供应链攻击
    SolarWinds公司创办于1999年,总部位于美国德克萨斯州奥斯汀,在多个国家设有销售和产品开发办事处,主要生产销售网络和系统监测管理类的软件产品,为全球30万家客户服务,覆盖了政府、军事、教育等大量重要机构和超过9成的世界500强企业,知名客户清单包括:《美国财富》500强企业中的425家;美国十大电信公司;美军所有五个分支;五角大楼,美国国务院,NASA,NSA,美国邮政局,NOAA,美国司法部和总统办公室;美国前五名会计师事务;全球数百所大学等。
    据析大约有超过250 家美国联邦机构和企业受到影响,其中包括美国财政部、美国NTIA,美国安全公司FireEye等,可以算得上是2020年最具影响力的供应链攻击事件了。

  • 2020/12,黑客组织FIN11利用AccellionFTA服务器的多个0day漏洞攻击全球上百家企业
    黑客利用4个安全缺陷攻击AccellionFTA服务器(FTA服务器是一款在2000年时代开发的文件共享工具,可使企业以简单的方式和员工以及客户共享文件),安装了一个名为“DEWMODE”的webshell,之后用于下载存储在受害者FTA设备上的文件。Accellion公司在新闻稿中指出,”在约300个FTA客户端中,受害者不到100人,而其中不到25个人遭受严重的数据盗取事件。在这25个客户中,某些客户的FTA文件分享服务器遭攻击后收到了勒索留言。攻击者发送邮件要求支付比特币,或者在由Clop勒索团伙运营的网站上公开受害者数据。

  • 2021/03,国际航空电信公司(SITA)受到供应链攻击
    国际航空电信公司(SITA)占据全球90%航空份额的通信和IT厂商,存储在该公司位于美国服务器中的乘客信息遭“高度复杂的攻击”。受攻击的服务器位于亚特拉大,属于SITA乘客服务系统(SITAPSS)。SITAPSS运营该系统是为了处理航空乘客信息,为SITA多家总部位于欧盟的企业所有。星空联盟(国际航空公司联盟)的航空公司成员包括汉莎航空、新西兰航空和新加坡航空以及OneWorld成员国泰航空、芬兰航空、日本航空和马来西亚航空公司已经开始和受影响用户通信,并表示,韩国航空公司济州航空的乘客数据也遭攻陷。

3. 供应链攻击

供应链攻击是一种以软件开发人员和供应商为目标的一种威胁, 攻击者通过感染合法应用来分发恶意软件来访问源代码、构建过程或更新机制从而达到对开发人员和供应商进行攻击的目的。

软件供应链可划分为开发、交付、运行三个大的环节,每个环节都可能会引入供应链安全风险从而遭受攻击,上游环节的安全问题会传递到下游环节并被放大。

黑客往往通过攻陷某知名官网的服务器,篡改其服务器上所提供的软件源代码,使得这些软件在被用户下载后安装时触发恶意行为。这些携带恶意代码的软件来自受信任的分发渠道,携带着相应的供应商数字签名,使得恶意程序的隐蔽性大大增强,安全检测难度加大。

当攻击者通过供应链攻击散播的恶意软件是以加密技术锁住系统资料,并藉此勒索企业,就构成了勒索软件攻击。通常当供应链攻击和勒索软件攻击被一起使用时,会造成更大的危害。

例如,对于Kaseya的攻击,安全公司Huntress Labs在Reddit上发布了一篇帖子,详细介绍Kaseya VSA入侵的工作原理,该木马软件以Kaseya VSA Agent Hot-fix的形式发布,通过Kaseya的MSP管理平台,将补丁分发到Kaseya用于客户管理的虚拟机VSA上,从而完成恶意软件对客户关键信息的加密和勒索。

  • 供应链攻击的典型攻击方法
攻击方法 攻击举例 攻击环节 防范难度
利用供应商的产品进行注入 SolarWinds,Kaseya事件 供应链上游
恶意接管(担任社区项目维护者,注入恶意代码) 人为 供应链上游
攻击者破坏中间软件升级功能或 CI/CD工具而非原始上游源代码库的实例 Passwordstate攻击事件 供应链中游
依赖关系混淆 道德黑客 Alex Birsan攻击事件 开发、交付 中等
利用第三方应用程序 邮件/浏览器漏洞 运行 中等
利用开放源代码库中包含的漏洞 - 开发 相对简单

《2020年中国网络安全报告》称供应链攻击已成为2020年最具影响力的高级威胁之一。

4. 供应链攻击的防范

4.1. Google的SLSA供应链完整性框架

6月16日,Google在安全博客上发表了一篇《Introducing SLSA, an End-to-End Framework for Supply Chain Integrity》博客,介绍了一个叫SLSA(莎莎(读音salsa))的用来检测端到端供应链完整性的框架。

  • SLSA解决的问题:

    • 软件生产商想要保护他们的供应链,但不知道具体如何;
    • 软件消费者希望了解并限制他们遭受供应链攻击的风险,但没有办法这样做;
    • 单独的工件签名只能防止我们关心的攻击的一个子集

  • SLSA制定的标准是软件生产者和消费者的指导原则:

    • 软件生产者可以遵循这些准则来使他们的软件更加安全;
    • 软件消费者可以根据软件包的安全状况做出决定。

SLSA是一套可逐步采用的安全指南,由行业共识建立。SLSA是用来防止普通供应链攻击,明确列举了开发过程中各个环节可能受到的攻击,并将这些攻击点标注为A到H共8个攻击点;同时对开发过程中的三个输出中间件:原码(source)、依赖(dependency)和包(package)通过安全等级的划分来体现供应链的完整性强度。SLSA的四个级别旨在增量和可操作,并防止特定的完整性攻击。SLSA 4代表理想的最终状态,较低的级别代表具有相应完整性保证的里程碑。

4.2. 开发过程供应链威胁

  • 开发过程供应链威胁图
    SALA

  • 图中的相关定义

术语 描述 举例
中间件(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 2 还提供了到SLSA 3 的简单升级路径.
SLSA 3 进一步要求源和构建平台满足特定的保证来源的可审计性和完整性的标准的出处。 我们设想了一个认证过程,审计师证明平台满足要求,然后消费者可以依赖这些要求。SLSA 3提供比早期级别更强大的防篡改保护通过防止特定类别的威胁,例如交叉构建污染.
SLSA 4 目前是最高级别,需要两个人审核所有变化和密封的、可重复的构建过程。 两人评审是一个发现错误和阻止不良行为的行业最佳实践。密封的构建保证出处的依赖列表是完全的。 可重现的构建,虽然不是严格要求的,但提供了许多可审计性和可靠性优势。 总体而言,SLSA 4 给消费者带来了高软件未被篡改的置信度.

4.4. SLSA安全级别的要求

SLSA给达到每个级别定义了实现要求,具体如下:
level requirement

4.5. 应用举例

下图是SLSA给出的应用举例,可以看到每个交付的中间件都有一个自身的hash值和出处的定义,从而保证整个中间件的可追溯和可验证。
case

5. 总结

  • 供应链攻击正成为危害最大的网络威胁之一,且发生的频率正在上升;
  • 供应链攻击由于拥有上游的正式发布渠道和有效的签名,作为下游的使用者防范困难;
  • 作为软件的开发者,在做好开源软件缺陷的管理之外,还要提高自身的风险管理能力,能够识别开发过程中恶意的变动,并触发追查和防范措施;
  • Google的SLSA供应链完整性框架,全面的考虑了供应链的各个环节可能引入的安全威胁,提供了防止供应链攻击的一种有效的方法;
  • Google的SLSA供应链完整性框架,可以成为我们开发过程中防范供应链攻击的一个很好的借鉴;

6. 参考

(完)