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

3月29日cyberkendra安全博客发了一条耸人听闻的帖子Log4ShellSpring框架中的等效远程代码执行(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;私人字符串内容;

+

@GetMapping("/endpoint") public String greetingSubmit(@ModelAttribute Greeting Greeting, Model Model) {

+
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];在((= in.read (b)) ! = 1){。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的例子-

@控制器公共类HelloController {@GetMapping("/greeting") public String helloWorld(@ModelAttribute SomeClass, Model Model){返回"hello";}}

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

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

@GetMapping("/greeting") public String helloWorld(SomeClass SomeClass, 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)，针对这个问题打补丁也是很重要的。

发表不实

由于这个漏洞是在零日发布的，再加上导致fude的CyberKendra原始博客文章，已经有很多关于SpringShell的发布不准确。我们的研究团队一直在关注最新的博客文章和出版物，并希望澄清一些观点-

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

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

如何测试SpringShell (Spring4Shell)问题?

用于测试活动端点，而不是运行一个PoC利用可用,Randori攻击团队发布了一个使用curl -的简单测试

curl -s -o /dev/null -w "%{http_code}" host:port/path

如果返回的状态码是“400”—您的端点很可能是易受攻击的。

注意，返回的状态码不是“400”，并不能保证端点不容易受到攻击。

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

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

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

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

如果你直接使用Spring Boot -升级到2.6.6版本

升级Spring Framework可以按照以下步骤进行—

Maven

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

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

Gradle

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

ext (spring框架。版本']= ' 5.3.18 '

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

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

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

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

JFrog平台易受SpringShell攻击吗?

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

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

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

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

cve - 2022 - 22963是一个严重的RCE问题(最初报告的是中等严重程度)在Spring云功能。这是一个非常严重的问题，但是Spring云功能没有Spring框架广泛。

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

如何使用JFrog Xray检测SpringShell漏洞?

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

保持最新的JFrog安全研究

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