有消息报道，俄罗斯Cozy Bear团体通过破坏SolarWinds公司旗下的Orion软件更新，获得了对政府和其他系统的访问权限。大多数组织并没有为应对这种软件供应链攻击做好准备。
前段时间民族国家黑客（nation-state hackers）对大型网络安全公司FireEye发起的入侵，属于一场大规模攻击的一部分，该攻击通过对一款流行的网络监控产品进行恶意更新，影响了主要的政府机构和公司。本次事件被称作是网络领域的“珍珠港”事件，凸显了软件供应链攻击可能产生的严重影响，以及大多数组织在预防和检测此类威胁方面准备不足的不幸事实。
据信，一个与俄罗斯政府有关联的黑客组织在一场始于2020年3月的长期活动中，获得了包括美国财政部和商务部在内的多个美国政府部门的电脑系统权限。这一消息促使美国国家安全委员会于周六召开紧急会议。
在此次攻击中，黑客入侵了SolarWinds公司（该公司生产一种名为Orion的网络和应用监控平台）的基础设施，然后利用这一权限制作并向软件用户分发含有木马的更新程序。在消息传出后被撤下的网站页面上，SolarWinds表示，其客户包括美国财富500强中的425家、美国十大电信公司、美国五大会计师事务所、美国军方所有部门、五角大楼、国务院以及全球数百所大学和学院。
SolarWinds软件供应链攻击还使黑客进入了美国网络安全公司FireEye的网络，这起入侵事件已于上周官宣。尽管FireEye没有指明具体的攻击组织，但《华盛顿邮报》报道称，该组织是俄罗斯对外情报局SVR的黑客部门——APT29或称Cozy Bear。
"FireEye已经在全球多个实体中检测到这一攻击活动，"该公司在一份咨询报告中表示，"受害者包括北美，欧洲，亚洲和中东的政府、咨询、科技、电信和采矿业实体。我们预计在其他国家和垂直行业还有更多的受害者。FireEye已经通知了所有已知受影响的实体。"
2020年3月至2020年6月期间发布的Orion 2019.4 HF 5至2020.2.1版本的软件可能含有木马组件。然而，FireEye在其分析中指出，每一次攻击行为都需要攻击者精心策划和手动交互。
攻击者设法篡改了一个名为SolarWinds.Orion.Core.BusinessLayer.dll的Orion平台插件，该插件作为Orion平台更新的一部分被分发。该木马组件经过数字签名，并包含一个后门，可以与攻击者控制的第三方服务器通信的。FireEye将该组件命名为SUNBURST进行追踪，并在GitHub上发布了该组件的开源检测规则。
"在长达两周的初始休眠期之后，它会检索并执行名为'Jobs'的命令，该命令具有传输文件、执行文件、配置系统、重启机器和禁用系统服务等能力，"FireEye分析师说，
"该恶意软件将其网络流量伪装成Orion改进计划(OIP)协议，并将侦察结果保存在合法的插件配置文件中，使其能够隐匿于合法的SolarWinds活动中。该后门使用多个混淆的黑名单列表来识别以进程、服务和驱动程序等方式运行的取证和反病毒工具。"
攻击者尽可能让恶意软件匿影藏形，他们更倾向于使用窃取来的凭证在网络中进行横向移动，并开放合法的远程访问权限。后门被用来传送一个前所未见的轻量级恶意软件dropper， FireEye将其称为TEARDROP。该dropper直接在内存中加载，不会在磁盘上留下痕迹。
研究人员认为，它被用来部署定制版的Cobalt Strike BEACON 载荷。Cobalt Strike是一种为红队设计的商业渗透测试框架和后攻击代理程序，也受到黑客和老练的网络犯罪集团青睐。
为了规避检测，攻击者使用临时文件替换技术来远程执行他们的工具。这意味着他们用自己的恶意工具修改了目标系统上的合法工具，执行它，然后用替换回合法工具。类似的技术还包括临时修改系统计划任务，方法是更新一个合法任务来执行一个恶意工具，然后将任务恢复回原来的配置。
"防御者可以检查显示访问合法目录的SMB会话日志，查找短时间内遵循“删除-创建-执行-删除-创建”模式的日志，"FireEye研究人员说，"此外，防御者还可以通过频率分析来识别任务的异常修改，从而监控现有计划任务的临时更新。还可以监控任务本身，观察是否有合法的Windows任务执行新增或未知的二进制文件。"
该攻击者专注于规避检测，并利用已有的信任关系，在FireEye所观察到的所有威胁者展现出的操作安全性中鹤立鸡群。然而，该公司的研究人员认为，这些攻击可以通过持续防御来检测，并在其咨询报告中介绍了多种检测技术。
SolarWinds建议客户尽快升级到Orion Platform 2020.2.1 HF 1版本，以确保他们运行的是无害版本的产品。该公司还计划在发布一个新的热补丁2020.2.1 HF 2，该补丁将替换受损组件，并进行额外的安全增强。
美国国土安全部也已经发出紧急指令，要求政府机构检查自己的网络是否存在木马组件，并进行汇报。
软件供应链攻击并不是一个新生事物，安全专家多年来一直警告说它们是最难防范的威胁类型，因为它们利用了供应商和客户之间的信任关系，以及机器与机器之间的通信渠道（如软件更新机制），而这些渠道本身就受到用户信赖。
早在2012年，研究人员就发现，网络间谍恶意软件Flame背后的攻击者利用一种针对MD5文件散列协议的密码学攻击，使他们的恶意软件看起来好像是由微软合法签署的，并通过Windows更新机制向目标分发。这并不是软件开发商微软本身受到攻击，而是攻击者利用了Windows Update文件检查中的一个漏洞，表明软件更新机制可以为虎作伥。
2017年，卡巴斯基实验室的安全研究人员发现了一个APT组织（被称为Winnti）的软件供应链攻击，该攻击入侵了NetSarang公司的基础设施。而NetSarang公司是一家生产服务器管理软件的公司，这使得攻击者能够分发带有该公司合法证书数字签名的含有木马的产品。同一批攻击者后来又侵入了Avast子公司CCleaner的开发基础设施，并向超过220万用户分发了含有木马的程序。去年，攻击者劫持了电脑制造商ASUSTeK Computer的更新基础设施，并向用户分发了恶意版本的ASUS Live Update Utility。
"据我所知没有任何组织已将供应链攻击纳入威胁建模中，"前NSA黑客、安全咨询公司TrustedSec的创始人David Kennedy告诉CSO。"说到SolarWinds发生的事情，这是一个典型的例子，攻击者可以从字面意义上“选取”任意部署了其产品的目标，而这些目标是许多来自全球各地的公司，且从检测和预防的角度来看大多数组织并没有能力做出响应。这不该是当今安全领域发生的讨论。"
虽然部署在组织中的软件可能会进行安全审查，以了解其开发人员在修补可能被利用的产品漏洞方面是否具备良好的安全实践。但组织并没有考虑到如果其更新机制被破坏，该软件会如何影响其基础设施，肯尼迪说道。"关于这点我们还不够成熟，也不存在一劳永逸的解决方案，因为公司需要软件来维持他们组织的运行，他们需要技术来扩大影响力并保持竞争力，但提供这些软件的组织却没有把这个作为威胁模型来考虑。"
肯尼迪认为，首先软件开发人员应该深入考虑如何始终保护其代码的完整性，同时还需要考虑如何在设计产品时将客户面临的风险降到最低。
"通常在构建软件时，你会从外向内考虑威胁模型，而不是由内而外，"肯尼迪说，"这是很多人都需要关注的领域：如何设计我们的架构基础设施以对此类攻击更具抵抗力？我们是否有办法通过最大限度地减少[产品]架构中的基础设施来阻止诸多此类攻击？例如，将 SolarWinds Orion限制在独立的环境中，仅开放其正常运行所需的通信流量。一般来说，为对手带来尽可能多的麻烦是一种很好的安全实践，这样即使他们成功攻陷了你正在运行的代码，他们也很难达到他们想要的目的。"
企业作为软件的使用者，也应当开始考虑不仅仅将零信任网络原则和基于角色的访问控制应用于用户，还应当应用于应用程序和服务器。正如不是每个用户或设备都应该能够访问网络上的任意应用程序或服务器一样，不是每个服务器或应用程序都应该能够与网络上的其他服务器和应用程序进行通信。在将任何新的软件或技术部署到网络中时，公司应该扪心自问如果该产品由于恶意更新而导致失陷的后果将会如何，并尝试将控制措施落实到位，以尽可能降低影响。
未来软件供应链攻击的数量很可能会持续增加，尤其是该类攻击的成功性和广泛性有目共睹。在2017年的WannaCry和NotPetya攻击之后，针对组织的勒索软件攻击数量爆炸性增长，因为它们向攻击者表明，企业网络并不像他们认为的那样具有抵抗此类攻击的弹性。从那时起，许多网络犯罪团伙开始采用先进的技术，使他们可以与民族国家的网络间谍行为者比肩。
勒索软件团伙也已经明白利用供应链的价值，并开始入侵托管服务提供商，利用漏洞接入到客户的网络。NotPetya本身就含有供应链成分，因为该勒索蠕虫最初是通过一款流行于东欧名为M.E.Doc的会计软件中含有后门的软件更新服务器发起的。
有组织的犯罪团伙和其他民族国家集团现在都将这次攻击视为"哇，真是一次非常成功的行动，"肯尼迪说。从勒索软件的角度来看，如果同时攻击所有安装了SolarWinds Orion的组织，他们原本可以加密世界上绝大部分基础设施，并赚取足以金盆洗手的资金。"他们或许明白，倘若要进行上述这种攻击，他们的精细化程度还有待提高。但考虑到勒索软件组织有目共睹的进步以及他们在开发上投入的巨额资金，这种攻击并不会很遥远。所以我坚信我们会亲眼见证其他类型的团体也将发动此类攻击，而不仅仅是民族国家集团。"
原文链接：https://www.csoonline.com/article/3601508/solarwinds-supply-chain-attack-explained-why-organizations-were-not-prepared.html
本文始发于微信公众号（互联网安全内参）：“网络珍珠港”事件再反思：为何供应链攻击如此难以防范？
评论