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

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%有效的，但可以是一种高效、有效的补充方法，因为它解决了在多云的供应链踪迹中识别相关用户的困难。