从供应链角度看Log4j2 0day漏洞

Log4j2漏洞甫一爆发，便在全球掀起轩然大波，影响范围之广，危害性之大无出其右。Log4j2事件是一场典型的开源软件导致的供应链事件，上游软件提供商的漏洞殃及下游产业的产品提供者，依赖关系的错综复杂使影响范围扩大，最终遍及整个网络空间。Log4j2事件为安全厂商与网络安全从业者敲响了警钟，必须警惕开源软件的供应链中暗藏的危机，并采取有效行动。

本文将从软件供应链角度审视Log4j2漏洞如何被引入，并在整个软件生命周期造成深远的影响。通过对开源组件中Log4j2二级传播的分析，我们将理清Log4j2漏洞的感染路径，并基于此思考可能的攻击场景。开源软件的加入为软件供应链安全带来的新挑战，呼唤各方协同作战，构筑一套行之有效的供应链安全方案。

Log4j2漏洞在软件供应链各阶段的影响

Log4j2作为一个堪比标准库的基础日志库，无数的开源 Java 组件直接或间接依赖于它。作为软件供应链中的核心原始组件，组件自身的漏洞带给整个软件供应链的影响是最为直接、隐秘，也是影响最为深远的。

在组件的集成构建阶段，当 Log4j2 作为基础组件集成到一些核心业务组件的同时，漏洞也就在有意无意之间传播到了更为上层的核心业务当中，使产品的核心业务暴露出了一个附加的攻击面。在此阶段，由于组件之间的依赖关系相对来说还较为清晰，所以当漏洞被引入时，受到的影响面也较为容易排查。我们往往只需要将代码仓库中的受影响的组件版本更换为安全的补丁版本或直接移除更换掉即可。

在组件的依赖使用阶段，随着当前软件系统架构复杂性的提升，组件之间依赖的深度也逐渐增加。当 Log4j2 这类核心组件受到漏洞影响时，软件系统自身的复杂性就会掩盖影响，导致整个软件系统的攻击面被隐藏起来，从而容易被人忽略。所以在这个阶段排查漏洞影响是最为艰难的，往往需要安全工程师们进行大规模的分析排查、抽丝剥茧，将软件系统的各种依赖关系梳理清楚。站在攻击、防御的角度也同样如此，攻击者及防御者往往需要通过 hook、fuzz 等方式测试组件的调用深度，从而找出被隐藏的漏洞触发点。

在下游用户使用阶段，受到的影响则是更为被动的。因为复杂软件系统对于身处下游的用户来说就是一个黑盒，普通用户对于其包含的组件风险一无所知，此时只能靠有责任心的软件提供商来提供运维支持服务。如果遇到不负责任或者漏洞应急不及时的供应商，则只能依靠社区建议及旁路的安全设备来进行临时缓解。

Log4j2漏洞传播渠道分析

根据Log4j2漏洞组件引入的不同方式，可分为直接依赖与间接依赖这两种情况。前者是指项目开发时直接使用Log4j2作为日志记录框架；而后者则是使用的第三方组件或框架使用了Log4j2，使有漏洞的组件间接引入项目。

相较于直接依赖，间接依赖更不易为开发者所知悉，在发生漏洞事件时更不易得到修复。Sonatype在2020年度发布的软件供应链报告中的数据指出：随着时间推移，开源组件在项目中使用的频次不断增加，但开发人员所能察觉的开源组件比例却显著下降。

目前我们注意到Maven库中受此漏洞影响的组件较多，除此之外许多独立的框架与应用也受到了影响。为研究Log4j2漏洞的二级传播途径，绿盟科技研究团队对Maven仓库中部分受影响的项目进行了统计。依据已有的统计数据，我们发现Log4j2漏洞的二级传播主要依靠开源框架与组件。

Log4j2漏洞对供应链下游的潜在影响

此次漏洞的涉及范围广泛且危害严重，因此各个场景领域都应该重点关注。为了保护客户业务的运转和资产的安全，各个领域应该意识到该漏洞的严重性，并及时排查可能受到影响的部分；同时面对资产繁杂的场景，应分清楚优先级，从对业务的对业务影响严重性高的入手逐步剥除该漏洞威胁的可能。以下是几个场景领域的典型案例，帮助安全从业人员总结归纳，尽可能减少漏洞对供应链下游可能造成的影响。

安全产品

安全产品作为企业抵御入侵者的甲胄，时刻保护着企业的资产安全。一旦安全产品的防护被突破，企业资产便唾手可得。同时出于防护的需要，某些安全产品对于企业资产拥有监视和管控的权限，如果被攻破则会帮助攻击者进一步扩大对企业的危害。

Bitdefender中的云产品GravityZone Cloud包含被Log4j2漏洞攻击的潜在风险，该产品能够对云环境下的主机集中管理，一旦被攻击会导致攻击者直接接管整个云环境。

大数据

数据往往是攻击者入侵的首要目标，大数据平台中往往包含大量用户隐私数据，平台沦陷所致的隐私数据泄露会造成不可估量的影响。

ElasticSearch作为一个功能强大的开源数据库，由于搜索速度快和配置灵活等优点被广泛应用于各种企业和组织，往往存储着海量的数据。2019年10月和12月由于暴露于公网的ElasticSearch没有配置密码保护，导致几十亿用户信息泄露。ElasticSearch5以上版本的插件XenForo Enhanced Search中包含了可利用的Log4j2。攻击者利用Log4j2漏洞将导致大量暴露在公网的ElasticSearch数据库沦陷，造成海量的数据泄露。

虚拟化平台

虚拟化产品中部署的虚拟容器中常常包含某些重要的用户业务，一旦虚拟容器被攻击后会造成用户的业务中断或数据泄露和加密，更甚者如果虚拟平台中的管理服务被攻击后，会造成整个虚拟化平台的沦陷。

VMWare vCenter作为VMWare vSphere云计算基础架构虚拟化平台中的核心组件，可用于集中管理VMWare vSphere环境。3月14日针对VMWare虚拟化环境的勒索病毒攻击导致大量用户在虚拟机中的生产业务受到影响，部分Windows系统的数据也被加密。一旦攻击者能够成功利用Log4j2漏洞攻击vCenter服务器，便能够通过vCenter服务器管理整个虚拟环境中的所有虚拟机，导致vSphere环境中虚拟机的业务中断或数据泄露。

软件供应链安全呼吁各方行动

开源软件的开发方应该具备漏洞情报收集、影响范围定位和及时提供修复补丁的能力。但开源软件项目的维护者却经常以疲于奔命的状态义务维护着项目，无暇顾及潜在的安全风险。本次事件中Log4j2项目组仅有三位社区贡献者进行开源与漏洞修复，维护着足以撼动互联网大厦的项目。使开源项目维护者的角色专业化，在项目开发过程中采取保障供应链安全的有效措施，或是解决开源软件供应链安全的必经之路。

企业在选择开源软件时应该关注开发方的能力，这就会衍生出对开发方能力评价的服务，也同时衍生了开发方能力建设的服务，这种服务一部分可以来自于安全公司，也可以是直接购买分发方提供的SaaS服务（比如漏洞情报）。

对于分发方，应该要跟开发方和用户建立直接的联系，及时提供更新补丁和最新修复的版本，并通知下载过原版本的用户进行修复。那么分发方应该也是要做一个能力建设和评价。

作为用户方在收到漏洞情报后要及时修复闭环，这里用户也可能是使用开源组件进行开发的一个软件集成商，那么对于软件集成商的能力评价和建设也会是一个重要方面。

因此漏洞威胁情报、各方软件供应链安全能力评估、漏洞闭环管理和安全能力平台建设会是一些通用的供应链安全方案。

总结

开源软件的引入在减少开发时间的同时，增加了软件供应链安全的复杂度，类似Log4j2这样应用广泛的基础组件在供应链的各阶段均存在深入的影响。大型项目中依赖关系数量与依赖层级数量的复杂度，增加了厂商对漏洞的排查难度。对漏洞组件间接依赖的开源组件及框架所导致的二级传播大大扩充了Log4j2漏洞的影响范围。上游软件供应链产品中漏洞累积的影响，最终会在下游应用场景中浮现，下游产品服务提供商应当采取有效手段，对涉及漏洞的资产进行排查。

产品开发中复杂多层级的依赖关系，与客户资产的纷繁复杂均呼唤一种行之有效的解决方案。目前绿盟科技的代码安全审计产品SDA，通过多维BOM分析技术，丰富的漏洞知识库，能够准确检测代码中所使用的Log4j2组件2.0到2.15-rc1版本中的远程代码调用漏洞，防止漏洞在代码中被利用。