涟漪2.0:供应链放大了19个零日漏洞

2020-06-17 04:48:48

Ripple20的故事始于2019年9月,当时我们决定开始对Treck TCP/IP库进行一些兼职研究。在几个月内,我们意识到有一些关于潜在漏洞的令人不安的数据,并联系了Treck分享我们的信息,并启动了协调的漏洞披露(CVD)过程。我们从一开始就知道,Treck与许多不同的供应商合作,有可能影响大量用户。然而,我们根本不知道情况的规模和绝对程度,也不知道供应链已经变得多么复杂。

我们与特雷克的接触最初是具有挑战性的。Treck是一家服务于利基客户的小公司,通常不适用于个人消费者的方式。他们似乎也从未成为独立安全研究的目标。最后,我们设法在Treck找到了一位电子邮件联系人,并收到了一份介绍。我们通知他们,我们在他们的TCP/IP堆栈库中发现了一个严重的安全漏洞,我们倾向于直接与他们合作。最初,我们面临的交流很少。后来我们了解到,特雷克正在内部评估信息,并与他们的法律顾问一起评估信息。(我们还注意到诉讼律师在LinkedIn和其他地方对我们进行了调查)。

随后,我们开始联系几家精选的供应商(如Digi、HP、Intel和Quadros),我们知道他们使用过Treck产品及其易受攻击的TCP/IP堆栈库,并请他们帮助我们与Treck建立适当的连接。在这次供应商推广之后,与Treck的合作开始了。

一旦Treck了解了漏洞的严重性,我们就一起合作,JSOF向他们提供漏洞的描述和其他一些信息。

对我们来说,重要的是Treck将确保他们的客户被告知手头的漏洞。由于NDA和其他复杂性,Treck无法向我们提供代码库的客户和用户列表。这是我们第一次与一些供应链挑战擦肩而过。因此,Treck最终在披露过程中发挥了带头作用,因为他们最适合通知客户并提供适当的补丁。

有趣的是,修复漏洞的过程导致Treck的一些客户续签了支持合同,因此Treck似乎最终从这种情况中获利。当这些公司被告知Ripple20并很好地理解了潜在的风险时,他们很快就意识到持续维护的必要性和访问补丁的重要性。最终,许多公司与特雷克合作,要么续签合同,要么做出其他安排。对于警惕面临安全问题的大小供应商来说,这都是一个发人深省的教训。主动安全响应方法意味着客户有理由支付维护和支持费用,以便使软件保持最新。

标准的行业惯例是,在有修补程序可用来修复漏洞之前,不会公布该漏洞。我们同意了一个标准的90天期限,在这段时间内,Treck将修复漏洞并通知他们的客户端补丁。Treck大约在3月底-距离90天的最后期限还有45天-提供了补丁,并通知我们,他们将联系所有受影响的客户端,通知他们这些漏洞。

在一些参与供应商要求更多时间后,披露被推迟了两次,一些供应商表示与新冠肺炎有关的延迟。基於对这些公司的考虑,有关期限由90天延长至超过120天。尽管如此,一些参与的公司变得很难对付,因为他们提出了额外的要求,而一些公司在我们看来,似乎更关心自己品牌的形象,而不是修补漏洞。

经过深思熟虑后,选择了6月16日作为Ripple20的宣传日。在此期间,一旦我们了解了漏洞的程度和涉及的绝对数量,我们就专注于如何最好地利用我们的时间(120天的耐心)来识别和帮助解决所有可能面临风险的各方。

由于Treck无法向我们提供其客户的全面列表,我们决定创建自己的列表,以便找出受影响的人,并确保每个人都收到通知并修补漏洞。我们使用了一种创造性的供应链跟踪方法,试图了解分销的规模和问题的程度。我们很快就开始意识到并意识到供应链的情况到底有多复杂。

对我们来说,跟踪Treck库分发的范围对于一个小团队来说太大了,这一点对我们来说变得很明显。我们可以追踪供应链的踪迹,但我们需要与国际组织合作,在我们无法进入的组织和领域内扩大我们的触角。

这就是为什么Ripple20披露过程由多个国家计算机应急响应小组(CERT)组织和监管机构协调和监督的原因。所有人都在合作,以便在漏洞公之于众之前,尽可能多地接触到受影响的供应商。我们的合作者最初包括:

CERT协调中心(CERT/CC),卡内基梅隆大学的全球互联网安全信息协调中心。这是第一次(也是最广为人知的)CERT。

隶属于国土安全部(DHS)的网络安全和基础设施安全局(CISA)。

CERT小组专注于识别和减轻安全风险的方法。例如,他们可以通过BLAST公告接触到更大的潜在用户目标群体,即向一长串参与公司广播的“群发邮件”,以通知他们潜在的漏洞。一旦确定了用户身份,缓解措施就开始发挥作用。虽然最好的响应可能是安装原始的Treck修补程序,但在许多情况下无法安装原始修补程序。CERTS致力于开发可用于最小化或有效消除风险的替代方法,即使打补丁不是一个选项。

JSOF协助协调披露过程,包括为一些漏洞提供概念验证脚本、建议缓解措施以及提供Treck库的其他用户列表。我们以各种创造性的方式追踪到了这些用户,包括与合作伙伴的合作以及一些有趣的开源情报收集。

在这种情况下,与国际集团合作是至关重要的,这是出于另一个原因。早在20世纪90年代,特雷克就与一家名为ELMIC系统的日本公司合作。公布的信息表明,这两家公司共同开发了TCP/IP协议栈,尽管我们不确定这种合作是如何在多年来发展起来的。特雷克和埃尔米克后来分道扬镳,分道扬镳。Treck现在在美国以Treck TCP/IP的名称销售这一堆栈,而ELMIC系统公司(现在称为Zuken Elic)在亚洲以Kasago TCP/IP的名称销售它。这导致TCP/IP堆栈设备的两个独立分支-一个由Treck管理,另一个由ELMIC Systems管理-在完全不同的地理区域销售,据我们所知,它们之间没有合作,直到我们报告了漏洞。我们早些时候曾试图联系祖肯·埃尔米奇,但没有成功;他们在一封简短的电子邮件通信后停止了回复。(我们甚至尝试用日语发送一些电子邮件!)。后来,CERT/CC能够与日本全国性CERT组织JPCERT/CC进行协调,JPCERT/CC正在处理与ELMIC系统公司和日本/亚洲供应链中其他受影响公司的后续工作。我们已与Zuken Elic确认他们的TCP/IP堆栈受到某些Treck漏洞的影响。初步研究表明,Kasago正在广泛使用,为一条完全不同的供应链提供了开端。

我们一直在与安全供应商CyberMDX(医疗设备网络安全解决方案)和ForeScout(设备可见性和可控性)合作。在我们的实验中,我们使用Treck TCP/IP库来识别相关的网络签名。然后,我们与CyberMDX和ForeScout共享网络签名。每个人都检查自己广泛的客户端网络中的这些签名,以确定更多受影响的设备和组件。

请注意,网络安全社区中的这种类型的协作使所有参与者受益,而且是我们所知的第一种此类协作。我们扩大了可以识别的公司和设备的范围,而CyberMDX和ForeScout甚至在问题公布之前就已经能够为他们的客户提供缓解和可见性。其他要求不具名的公司也参与其中。这些合作被证明是有效的,尽管它们在披露过程中开始得很晚。我们毫不怀疑,未来这种类型的合作可以更早开始,并为各方提供巨大的价值。

我们还开发了一个脚本,公司可以自己运行,在自己的网络中识别Treck产品。这在现阶段不是100%有效的,但可以是一种高效、有效的补充方法,因为它解决了在多云的供应链踪迹中识别相关用户的困难。