深度洞察 | Spring框架及Log4j远程代码执行漏洞影响力分析
随着疫情催化企业数字化转型的脚步，不断变化对的攻击模式催生出新的安全需求。一方面，漏洞也在不断变异和迭代，潜在危害极具破坏性；另一方面，攻击者也在寻找新的漏洞利用模式。
目前，受到Log4j2漏洞影响和威胁的企业与组织数量仍在持续增长，Spring框架远程命令执行漏洞（CVE-2022-22965）事件（官方已发布新版本完成漏洞修复）也成为近期的焦点。依照目前的漏洞披露情况、发现及更新，根据统计数据和现有的漏洞管理实践，我们在此基于Maven Central中发布的第三方库进行Spring-Core及Log4j2供应链传播进行分析。
RCE漏洞影响力分析
作为组件成分分析的重要组成部分，我们长期维护了面向主流语言生态中的第三方库的知识图谱，其中包含了各个组件的发布版本、时间、依赖及已知安全漏洞等相关信息，截止分析时间，Maven知识图谱中共包含超过属于45.6万第三方库的829万个不同版本的相关信息。基于此，我们针对Spring框架远程命令执行漏洞及Log4j2 JNDI RCE两个“核弹级”漏洞在供应链上反向追溯其影响力。
Spring框架远程命令执行漏洞
（官方已发布补丁）
根据最新消息，2022年3月30日，国家漏洞（NVD）收录了Spring框架远程命令执行漏洞（CVE-2022-22965）。NVD对该漏洞的综合评级为“高危”。
目前，Spring官方已发布新版本完成漏洞修复，我们建议受漏洞影响的产品（服务）厂商和信息系统运营者第一时间进行自查，并及时升级至最新版本：
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
针对此次Spring框架远程命令执行漏洞（CVE-2022-22965），Scantist SCA已升级数据库并支持对该漏洞利用攻击的监测，同时提供修复方案及建议。用户可使用我们的SCA工具排查受该漏洞影响的开发项目和代码，及时处理，化解安全隐患。
漏洞影响传播分析
01
直接依赖
Spring Framework作为Java软件开发中最常用的框架之一，从其诞生至今共发布了222个演进版本，而本次安全漏洞事件已发布修复patch及版本，我们也基于之前全部的spring-core版本开展漏洞影响传播分析，供用户参考。下图展示了所有直接依赖于spring-core的第三方下游组件版本的数量，其中，除了少数使用非常广发的版本外，绝大部分版本的直接下游用户组件不超过2000.
02
间接依赖
进一步合并下游受影响组件版本到第三方库级别，如下图所示，在第三方组件包层面的分析结果进一步证实了与log4j-core在供应链中的位置差异。而这种差异可能是由于log4j与spring的功能定位差距造成的。
Spring-core作为JAVA开发中重要的代码框架，往往直接被开发者所使用并基于此开展进一步的开发，使用手段相对直接；而log4j作为重要基础组件，支撑了绝大部分上层应用的日志系统，而正由于其使用的广泛性，供应链上下游中各个位置均可能对其存在依赖。
此外，由于整个生态在log4j2 JDNI RCE漏洞事件中已经汲取了经验，相信在本次Spring-core RCE 漏洞事件中，各方安全团队能有更从容、安全、完备的响应预案。
log4j2 JNDI RCE CVE-2021-44228漏洞
Log4j2 是开源社区Apache旗下的开源日志组件，被广泛应用于各种业务系统开发。2021年11月24日，阿里云安全团队向Apache官方报告了Log4j2远程代码执行漏洞（CVE-2021-44228）。关于该漏洞的分析及解决方案，请参考《》。
漏洞影响传播分析
01
直接依赖
在修复版本[email protected]正式发布前，log4j2共发布了47个版本。下图展示了直接依赖于这47个log4j-core版本的第三方组件版本数量。[email protected]为该漏洞被爆出前的最新版本，而2.15.0，2.16.0，2.17.0则为漏洞爆发后的后续修复版本，而该漏洞在2.17.1中才最终被完全修复。图中可以看出，2.13.3~2.14.1为漏洞发布前广泛使用的版本。
02
间接依赖
以漏洞爆发前的最新版本[email protected]为例，下图展示了所有直接或间接依赖于该版本的下游第三方库版本的数量分布，其中横坐标表示依赖的距离，如A->B->C表示距离为2。由下图可以看出，绝大部分下游组件主要分布在依赖距离为3到7的范围内。
此外，我们进一步将依赖传播分析扩展到所有受改漏洞影响的log4j-core版本，结果如下图所示。其中，我们发现超过158万的第三方包版本直接或间接地依赖了log4j-core，占整个Maven生态中所有组件包的19.06%。而绝大部分的这些下游组件主要分布在依赖距离3~7，与[email protected]的分析中一致。
接着，我们更进一步合并下游受影响组件版本到第三方库级别，如下图所示，其中蓝色部分表示相应距离下有至少一个版本在当前依赖距离下存在对log4j-core任一受漏洞影响版本的依赖关系，而红色部分表示这些第三方库的最新版本当前依赖距离下仍存在对log4j-core任一受漏洞影响的版本。图中可以看出，截止分析时间，绝大部分的受影响第三方组件仍然未对其依赖中存在的log4j-core JNDI RCE漏洞进行相应。
软件供应链漏洞的应对思路
从Log4j到Spring Framework的漏洞攻击，再到各类网络安全事件的频发，软件供应链的治理已成为现代应用安全关注的要点，包括软件成分分析工具（SCA）、模糊测试工具（支持二进制），开源治理平台，开源画像分析等。
Scantist团队对漏洞数据库的建立和维护付出了巨大努力，通过多年的科研经验与数据积累，Scantist SCA能为用户提供更准确，更全面的扫描结果。此外，通过长期对知名开源组件的追踪，我们还拥有许多未被公开的独家漏洞信息，能够最大程度的从用户代码中扫描出正确的组件版本和对应的漏洞信息，让漏洞检测结果更加全面。一般情况下，同一个漏洞可能存在于同一个组件的多个版本中，又或者同一个漏洞可能存在于不同的组件中，经过我们内部反复测试与调试，Scantist SCA能够最准确的找出用户所使用的开源组件，并给出修复信息。
针对最近重要的Log4j和Spring框架远程命令执行漏洞，Scantist SCA已快速响应和支持对该漏洞利用攻击的监测，同时提供修复方案及建议。大家可以在Scantist.io直接进行测试。
关于Scantist
Scantist是从新加坡南洋理工大学孵化出来的一个专注于软件漏洞检测和管理的网络安全公司。其核心产品是一套全方位软件安全分析(SaaS)平台，利用智能漏洞分析引擎确定代码库中的漏洞信息，并提供漏洞修复补丁和建议。Scantist SCA是思探明自主研发的一款支持各类二进制程序扫描和源代码扫描的软件漏洞分析工具，其核心引擎利用深度学习与专家验证等技术来处理万亿字节级别的开源与闭源的漏洞数据，同时利用第三方数据库与开源组件独有的特性和漏洞特性来提升扫描结果的准确率。
备注：Scantist拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经Scantist允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。