基于JDK9的Spring内核爆RCE 0-day漏洞 - Cyber


今天,研究人员发现了一个可能破坏互联网的最严重漏洞之一,这个漏洞目前没有 CVE id(当时是待确认,3月31日已经确认 CVE-2022-22965),但我们可以将其 称为 Spring4Shell
该漏洞存在于JDK版本大于等于9.0的Spring内核中。
这个漏洞可能类似2021年底Log4j RCE 0-day 漏洞:Log4Shell

漏洞详情和调查
(1).检查JDK版本号 
在系统的运行服务器上,运行“ java -version ”命令查看运行的JDK版本。如果版本号小于等于8,则不受漏洞影响。

(2) 检查 Spring 框架的使用情况
1.如果系统项目以war包的形式部署,请按照以下步骤进行判断。

  • 解压war包。将war文件的后缀改为.zip,并解压压缩文件
  • 在解压目录中搜索spring-beans-*.jar格式的jar文件(例如,spring-beans-5.3.16.jar)。如果它存在,说明该业务系统是使用spring框架开发的。
  • 如果spring-beans-*.jar文件不存在,在解压目录下搜索CachedIntrospectionResuLts.class文件是否存在。如果它存在,说明该业务系统是使用Spring框架开发的。

2. 如果系统项目以jar包的形式直接独立运行,则按照以下步骤判断。

  • 解压缩jar包。将jar文件的后缀改为.zip,并解压压缩文件。
  • 在解压目录中搜索spring-beans-*.jar格式的jar文件(例如,spring-beans-5.3.16.jar)。如果它存在,说明该业务系统是使用spring框架开发的。
  • 如果spring-beans-*.jar文件不存在,在解压目录下搜索CachedIntrospectionResuLts.class文件是否存在。如果它存在,说明该业务系统是使用spring框架开发的。


(3) 全面调查
在完成以上两步排查后,同时满足以下两个条件,就可以确定是受此漏洞影响。

  • JDK版本号为9及以上。
  • 使用spring框架或衍生框架。

 
漏洞修复指南
目前,官方还没有针对的补丁。但建议使用以下两种临时解决方案进行防护,并及时关注官方补丁的发布,根据官方补丁修复漏洞。

从 Git Repository来看,Spring 开发者似乎正在着手修复远程代码执行漏洞,但我们必须等待官方确认。
 
更新:
用于测试是否易受Spring4Shell攻击的工具

另外一个测试工具:使用嵌入式 Tomcat 的 Spring 应用程序似乎并不容易受到攻击,但构建为 .war 文件并部署到独立 Tomcat 的应用程序可能容易受到攻击。在 JDK 11.0.14、Spring Boot 2.6.5 和 Tomcat 9.0.60 上测试。

其他细节:

更新:
Spring Framework RCE官方公告

3月31日已经确认 CVE-2022-22965  严重性程度:危急Critical

漏洞暴露的先决条件:

  • JDK 9 或更高版本
  • Apache Tomcat 作为 Servlet 容器
  • 打包为 WAR
  • spring-webmvc 或 spring-webflux 依赖项

受影响Spring版本:
  • Spring Framework
    • 5.3.0 to 5.3.17
    • 5.2.0 to 5.2.19
    • 旧的、不受支持的版本也会受到影响

为什么只影响WAR而不影响Jar发布包
这与WAR包中的类加载器权限开放有,,因为嵌入式 servlet 使用了更严格的类加载器。
这一切都是因为几年前基于另一个 CVE 的工作,它变成了一个更广泛开放的类加载器。

更准确地说,多年前的CVE修复阻止了通过类对象访问类加载器。Java 9通过模块又暴露了类加载器,模块可以从类中访问,因此提供了一种绕过旧的CVE修复的方法。
结合这一点,独立的Tomcat的网络应用程序类加载器有写到webapps目录的权限,你就得到了当前的POCs。
嵌入式Tomcat的类加载器没有这样的权限,因此不能写出用于在这些POCs中触发RCE的jsp文件。
然而,如果这个问题的根本原因是Spring对表单参数绑定的处理,可能与war/jar文件的格式,或Tomcat的存在,或Java版本有什么关系。
就我们所知,可能还有其他尚未公布的漏洞途径。但它们不一定像RCE那样严重。

因此,虽然公布的概念证明只适用于基于WAR包的部署,但完全有可能发现另一种不存在这种限制的攻击,但是使用了相同的机制。