SpringShell (Spring4Shell)零日漏洞CVE-2022-22965:所有你需要知道的

3月29日，Cyberkendra安全博客发了一条耸人听闻的帖子Log4ShellSpring Framework中存在等效远程代码执行(RCE)零日漏洞，但没有任何关于漏洞本身的可靠细节。的安全漏洞它的绰号是“SpringShell”(或“Spring4Shell”)，因为它的意义与臭名昭著的“Log4Shell”相似。一天后，3月30日，推特上发布了一个0天的概念验证，这让研究人员争相验证它的真实性。3月31日，该漏洞被官方确认春天的维护者并给予CVE ID -cve - 2022 - 22965， Spring框架的固定版本随后发布。

在使用Spring框架的web应用程序中，在某些条件下，该安全漏洞被正式发布为严重级别的远程代码执行问题。

是什么原因导致SpringShell (Spring4Shell)漏洞?

SpringShell漏洞CVE-2022-22965存在于Spring框架的“数据绑定”机制中。

这种机制从请求URL或请求体中获取参数，并将它们分配给函数参数或在某些情况下Java对象．

公共类Greeting {private long id;private字符串内容;

+

@GetMapping("/endpoint") public字符串greetingSubmit(@ModelAttribute问候语，模型模型){

+
http://www.myapp.com/endpoint?内容和id = 5 =你好
＝

greeting.getId() == 5 greeting.getContent() == "hello"

当将请求参数分配给Java对象时，存在固有的安全风险，因为所构建对象的一些“内部”参数永远不应该被外部控制，这包括类，类加载器而且ProtectionDomain参数。

春天包含具体代码这将阻止攻击者为这些内部属性赋值。

不幸的是，从Java 9开始，由于引入了一个新的API (class.getModule)可以绕过Spring的保护并为属性的属性赋任意值类加载器属性- - - - - -这是SpringShell的根本原因。

为什么CVE-2022-22965 - SpringShell (Spring4Shell)如此危险?

Spring框架是一个非常流行的构建web应用程序的框架，而SpringShell漏洞位于该框架的核心，这意味着许多使用Spring框架构建的web应用程序都容易受到这个问题的影响。

虽然不是所有的web应用程序都可以利用这个安全漏洞(见下一节)，但利用这个安全漏洞的前提条件可能并不罕见。例如，Spring -发布的一个基本教程“处理递交表格”易受此漏洞的影响。由于许多web应用程序开发人员使用这些教程作为模板，这可能会导致应用程序在野外受到攻击。

该漏洞的影响是最高的-远程代码执行。

此外，JDK本身没有针对这种类型的漏洞的缓解技术，并且以稳定的方式利用该漏洞是微不足道的。

尽管如此，我们认为这个问题不会像现在这样普遍Log4Shell．

SpringShell (Spring4Shell)是如何被利用的如今?

有许多方法可以利用的修改类加载器以获取远程代码执行，但最初发布的PoC漏洞选择利用此安全漏洞Tomcat-specific技术滥用AccessLogValve获取任意文件覆盖。

该漏洞分为两个阶段

• 覆盖Tomcat-specific类加载器属性，将访问日志文件路径更改为web根目录下的某个位置，并将日志模式(写入的数据)更改为包含webshell代码的常量模式。这会导致webshell JSP被放到web根目录下
• 向已删除的webshell发送查询请求，以执行任意shell命令

webshell是一个非常简单的JSP程序，它执行通过查询参数传递给它的shell命令

<% java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("cmd")).getInputStream();Int a = -1;Byte [] b = new Byte [2048];While ((a=in.read(b))!=-1) {out。println(新的字符串(b));} % >

关于这个开发技术的更详细的描述可以在这里找到．

到底什么时候是SpringShell (Spring4Shell)漏洞可利用?

在高层次上，如果-，您的web应用程序可能是脆弱的

• 你的web应用是建立在Spring框架上的(例如，使用Spring Boot)
• 您的web应用程序运行在JDK 9或更高版本上
• 您的web应用程序使用数据绑定将请求参数绑定到Java对象

扩展最后一个前提条件——由于漏洞存在于Spring的数据绑定机制中，因此只有试图将请求参数绑定到pojo(普通旧Java对象)的web应用程序才容易受到攻击。

实际上，这意味着请求处理程序将接收用户定义的类类型作为其第一个参数。

下列注释中的任何一个，都表示可能受-影响的请求处理程序

@RequestMapping @GetMapping @PostMapping @PutMapping @DeleteMapping @PatchMapping

一个脆弱的Spring控制器的例子

@Controller public class HelloController {@GetMapping("/greeting") public String helloWorld(@ModelAttribute someeclass someeclass, Model Model){返回"hello";}}

注意@ModelAttribute注释，它表示数据绑定将会发生。

方法也可以编写相同的请求处理程序@ModelAttribute注释(用于someClass争论)，仍然脆弱-

@GetMapping("/greeting") public String helloWorld(someeclass someeclass, Model Model){返回"hello";｝

这是因为族不匹配的类型著名的类解析为@ModelAttribute默认情况下。

作为参考，请注意在使用以下参数类型/注释时，不能利用“-”

WebRequest NativeWebRequest ServletRequest ServletResponse MultipartRequest MultipartHttpServletRequest HttpSession PushBuilder Principal HttpMethod Locale TimeZone ZoneId InputStream Reader OutputStream Writer @PathVariable @MatrixVariable @RequestParam @RequestHeader @CookieValue @RequestBody HttpEntity @RequestPart Map Model ModelMap RedirectAttributes SessionStatus @SessionAttribute @SessionAttributes UriComponentsBuilder @RequestAttribute

关于当前漏洞的说明

由于原始PoC攻击选择了特定的利用向量(通过AccessLogValve任意覆盖文件)，该攻击除上述要求外还提出了两个要求:

• web应用程序必须由Apache Tomcat提供服务
• web应用程序必须作为WAR部署在Tomcat上。Spring Boot(可执行JAR)的默认部署方法不容易受到攻击。

然而，我们怀疑即将到来的攻击将采用不同的攻击载体，并且不容易受到这两个要求的影响。即使使用不同的应用程序服务器(如Eclipse Jetty)，针对这个问题打补丁也是很重要的。

发表不实

由于这个漏洞被作为零日漏洞发布，再加上引发fudd的CyberKendra原创博客文章，已经有许多关于SpringShell的不准确的发布。我们的研究团队不断关注最新的博客文章和出版物，并希望澄清一些观点-

• SpringShell不是反序列化问题，而且春天的承诺许多博客文章提到的反序列化问题与SpringShell(事实上，或任何其他具体的CVE)无关。
• 该漏洞可以通过所有HTTP方法被利用，而不仅仅是通过GET/POST。我们可以看到PoC漏洞在@PutMapping处理程序上进行了微小的更改

• 虽然最初的漏洞PoC仅适用于Apache Tomcat上托管的web应用程序作为WAR(这并不常见)，但无论托管应用程序服务器如何，漏洞本身都是相关的。我们完全希望未来的SpringShell攻击能够针对不同的应用服务器(例如Eclipse Jetty)和不同的部署方法。
• 一些建议和工具涉及基础spring bean软件包容易受到攻击，但此特定软件包的存在不足以远程利用此漏洞。这是因为易受攻击的处理程序必须具有@RequestMapping注释(或等效的注释)，并且这些注释仅在spring web包中。

如何测试SpringShell (Spring4Shell)问题?

用于测试活动端点，而不是运行可用的PoC漏洞,兰多里攻击队发布了一个使用curl -的简单测试

curl -s -o /dev/null -w "%{http_code}" host:port/path?class.module.classLoader.URLs%5B0%5D=0

如果返回的状态代码是“400”—您的端点很可能是脆弱的。

注意，返回的状态代码不是“400”，不保证端点不是脆弱的。

为了测试本地代码库，JFrog发布了一个OSS工具扫描编译的二进制代码，以找到易受攻击的web应用程序-

为了解决实际运行的应用程序与其源代码相匹配的复杂性，我们将重点放在了一个直接扫描已编译二进制代码的工具上。为了过滤掉不相关的结果，我们选择扫描这个特性，这个特性提供了一种健壮的方法，可以将很大一部分端点注销为非脆弱的(端点绑定请求的类型)，从而帮助团队专注于更新他们的软件中实际上可能是脆弱的部分。

如何完全修复SpringShell (Spring4Shell)漏洞?

修复SpringShell的最佳方法是将Spring Framework升级到5.2.20或5.3.18版本

如果您直接使用Spring Boot，请升级到2.6.6版本

升级Spring框架可以这样做-

Maven

编辑你的pom.xml- - - - - -

<属性> < spring-framework.version > 5.3.18 < / spring框架。版本>属性> < /

Gradle

编辑你的build.gradle- - - - - -

ext (spring框架。Version '] = '5.3.18'

我可以在不升级的情况下缓解SpringShell (Spring4Shell)问题吗?

最好的做法是升级Spring Framework(如上一节所示)。如果当前无法升级，Spring官方博客建议修改应用程序代码并添加一个@ControllerAdvice这阻止了一些类加载器内部字段-

@ControllerAdvice @Order(Ordered.LOWEST_PRECEDENCE)公共类BinderControllerAdvice {@InitBinder公共void setAllowedFields(WebDataBinder dataBinder) {String[] denylist = new String[]{"class. class. "*”、“类。*”、“* . class。*”、“* . class。* "};dataBinder.setDisallowedFields (denylist);}}

Spring提到这种解决方法并不是万无一失的而且建议更多可行的变通办法，但一般来说，升级是解决这个问题的最好办法。

JFrog平台易受SpringShell攻击吗?

经过内部调查，我们可以确认JFrog DevOps平台不容易受到SpringShell (CVE-2022-22965)或Spring Cloud Function (CVE-2022-22963)中最近的RCE漏洞的攻击。

SpringShell与CVE-2022-22963或CVE-2022-22950有关吗?

不幸的是，与SpringShell同时发布了另外两个Spring cve (CVE-2022-22965)，这造成了很多混乱。

这两个附加的cve与SpringShell无关，它们中的每一个都应该与SpringShell分开处理。

cve - 2022 - 22963是严重的RCE问题(最初报告的是中等严重程度的问题)中的Spring Cloud Function。这是一个非常严重的问题，但是Spring Cloud Function没有Spring Framework那么广泛。

cve - 2022 - 22950是Spring Framework中中等严重的DoS问题。

如何使用JFrog x射线检测SpringShell漏洞?

JFrog Artifactory和JFrog x光可以针对任何受支持的工件类型检测易受SpringShell漏洞攻击的工件，并通过详细的研究数据和缓解措施进行增强。阅读我们的补救方法博客文章学习如何最好地使用JFrog平台来查找、修复和加强您的软件供应链。

与JFrog安全研究保持最新

在我们的JFrog安全研究团队中跟踪最新的发现和技术更新安全研究网站并在推特上@JFrogSecurity．