查看原文
其他

探讨:软件厂商Kaseya事件是不是软件供应链攻击?

Matt Howard 代码卫士 2022-04-06

 聚焦源代码安全,网罗国内外最新资讯!

编译:奇安信代码卫士


专栏·供应链安全

数字化时代,软件无处不在。软件如同社会中的“虚拟人”,已经成为支撑社会正常运转的最基本元素之一,软件的安全性问题也正在成为当今社会的根本性、基础性问题。


随着软件产业的快速发展,软件供应链也越发复杂多元,复杂的软件供应链会引入一系列的安全问题,导致信息系统的整体安全防护难度越来越大。近年来,针对软件供应链的安全攻击事件一直呈快速增长态势,造成的危害也越来越严重。


为此,我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯,分析供应链安全风险,提供缓解建议,为供应链安全保驾护航。


注:以往发布的部分供应链安全相关内容,请见文末“推荐阅读”部分。




Kaseya 公司的网络监控和远程管理软件遭大规模且高级别攻击,迅速登上各大新闻头条。在试图了解整个事件时,大家讨论的其中一点是,Kaseya 攻击事件是否为“软件供应链”攻击?


值得注意的是,Kaseya 公司的客户包括多个独立公司以及大量管理服务提供商 (MSPs)。这些 MSPs 为数百甚至是数千家下游商务客户提供 IT 外包服务,这些客户通常是中小型企业,IT 部门数量有限或为零(比如医生、牙医、会计、律师公司等)。


发生了什么?


Kaseya 公司事件刚刚浮出水面时,有人猜测勒索团伙可能已经获得公司后端软件开发管道(包括 build 基础设施在内)的访问权限。获取权限后,攻击者可在运行本地版本的 VSA 软件中注入恶意代码。换句话说,恶意人员可能以 SolarWinds 遭利用的相同方式利用了 Kaseya。

不过,现在我们了解到,Kaseya 和 SolarWinds 并不一样。Kaseya 攻击者利用的是 Kaseya 软件中的 0day (CVE-2021-30116)。最初,只有攻击者才知道这个 0day 漏洞的存在,他们可以利用 Kaseya 软件的本地版本并最终执行勒索攻击。而且,由于Kaseya 如此多的客户都是 MSPs,因此攻击者能够将勒索攻击传递到下游多达1500家将日常 IT 功能外包出去的中小型企业。

Kaseya 公司最初发布的报告指出,“攻击者能够利用 VSA 产品中的 0day 绕过认证机制并执行任意命令。尽管该利用路径可使攻击者利用标准的 VSA 产品功能将勒索软件部署到端点,因此没有证据表明 Kaseya 公司的VSA代码库已被恶意修改。换句话说,攻击者并未像 SolarWinds 攻击中所使用的方法那样投毒 Kaseya 公司的软件(如攻陷上游 build 进程)。


是否为软件供应链攻击?


今天早些时候,一些值得尊敬的安全专业人员以及其他人在 LinkedIn 和推特上表示,有些人认为 Kaseya 勒索事件并非软件供应链攻击。

本文作者基于自身六年来对软件供应威胁演进的经验指出,“软件供应链攻击“包含的攻击类型涵盖针对如下目标的攻击:

1、上游的开源依赖关系 (event stream、octopus scanner/netbeans、命名空间混淆等)

2、上游 build 基础设施 (SolarWinds)

3、上游更新机制 (NoxPlayer)

4、上游 MSPs 及其所选 app (Kaseya)

的确,虽然利用软件供应链的路径各不相同,但它们的共通之处在于,所有攻击向量都旨在上游目标,目的就是扩大下游利用。

因此,一方面,Kaseya 的确不同于 SolarWinds,另外一方面,它们在某种程度上是类似的,作者认为都可归类为“供应链“攻击。

另外,如果 Kaseya 攻击事件不能归属于供应链攻击范畴,那么该归到哪一类呢?它是一种外部服务,是需要购买的服务,也是客户计算机给予高度可信访问权限的服务。这些不正是供应链攻击的定义本身吗?


仍在延续的趋势


实际上,Kaseya 勒索事件是多年来所出现的一种趋势:为了扩大对下游受害者的利用范围,恶意人员不断攻击位于数字值流上游的技术资产和提供商。其中包括开源库、IDE、build 服务器、更新服务器以及 Kaseya 事件中出现的 MSPs。

尽管存在很多旨在保护下游技术资产外围的工具,但实际上它的本质是:软件本身就越来越多地称为数字化风险的软肋。如果说几个月来发生的事情说明了什么,那么就是攻击者将继续攻击上游软件供应链资产,作为大规模利用下游受害者的偏好路径。

我们行业和网络防御团队是时候将注意力左移了。和同事一起构建代码,我们可以以保护下游数字化供应链的能量和敏锐来保护数字化供应链上游部分的安全。简言之,我们需要更多地专注于设计安全的构建和维护软件应用程序上。

要点:

  • 速度至关重要。由于0day攻击不断涌现,快速行动至关重要。这意味着要在开发周期、网络安全策略和最佳实践方面左移。

  • 知道自己的供应链至关重要。开源和第三方依赖关系是构成现代软件开发的庞大组成部分。了解第三方依赖关系的来源和清洁度对于良好的开发进程起着根本作用。

  • 更新软件至关重要。使用的开源依赖关系越老旧,它们越可能具有缺陷(安全缺陷、架构缺陷、许可证缺陷)。如果不经常更新,则可能来不及。就像我们常说的那样,软件变旧就像牛奶变质,而非陈酿酒,所以软件的保鲜很重要。






推荐阅读
NIST 按行政令关于加强软件供应链安全的要求,给出“关键软件”的定义及所含11类软件
在线阅读版:《2021中国软件供应链安全分析报告》全文
Atlassian 域名被曝一次点击账户接管漏洞 可导致供应链攻击
Linux 应用市场易受RCE和供应链攻击,多个0day未修复
给开发者的9个安全建议:既能保护供应链安全,也不会拖慢开发进程
微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析
速修复!热门npm 库 netmask 被曝严重的软件供应链漏洞,已存在9年
SolarWinds 供应链事件后,美国考虑实施软件安全评级和标准机制
找到软件供应链的薄弱链条
GitHub谈软件供应链安全及其重要性
揭秘新的供应链攻击:一研究员靠它成功入侵微软、苹果等 35 家科技公司
谷歌Linux基金会等联合推出开源软件签名服务 sigstore,提振软件供应链安全
Linus Torvalds 警告:勿用 Linux 5.12 rc1,担心供应链攻击?
微软和火眼又分别发现SolarWinds 供应链攻击的新后门
找到恶意软件包:Go 语言生态系统中的供应链攻击是怎样的?
拜登签署行政令,要求保护美国关键供应链(含信息技术)的安全
坐火车太无聊,我溜入微软 VS Code官方GitHub仓库,但没敢发动供应链攻击
SolarWinds 供应链攻击中的第四款恶意软件及其它动态
OpenWRT开源项目论坛遭未授权访问,可被用于供应链攻击
FireEye事件新动态:APT 攻击 SolarWinds 全球供应链(详解)
FireEye 红队失窃工具大揭秘之:分析复现SolarWinds RCE 0day (CVE-2020-10148)
FireEye红队失窃工具大揭秘之:分析复现Zoho ManageEngine RCE (CVE-2020-10189)
FireEye 红队失窃工具大揭秘之:分析复现 Zoho 任意文件上传漏洞(CVE-2020-8394)
FireEye 红队失窃工具大揭秘之:分析复现 Confluence路径穿越漏洞 (CVE-2019-3398)
FireEye 红队失窃工具大揭秘之:分析复现 Atlassian RCE (CVE-2019-11580)
Ripple 20:严重漏洞影响全球数十亿IoT设备,复杂软件供应链使修复难上加难
被后爹坑:开源 JavaScript 库沦为摇钱树
速修复!开源企业自动化软件 Apache OFBiz 出现严重的 RCE 漏洞
谷歌提出治理开源软件漏洞的新框架:知悉、预防、修复
开源软件漏洞安全风险分析
开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析
集结30+漏洞 exploit,Gitpaste-12 蠕虫影响 Linux 和开源组件等




原文链接

https://blog.sonatype.com/kaseya-ransomware-supply-chain



题图:Pixabay License



本文由奇安信编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。



奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错,就点个 “在看” 或 "” 吧~



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存