复现Spring的漏洞

  • A+
所属分类:spring

我真的复现了这次 Spring 的漏洞。

昨天晚上我正在家里悄悄卷你们的时候,突然有人给我发来这样的一个链接:

https://sizeof.cat/post/springcore-rce/

然后只配上了四个字:

复现Spring的漏洞

于是我赶紧点进去看了一下。

很明显这个文章最开始的时候应该也是和我一样一起吃瓜的。

因为他最开始的描述是用的这样的词汇:

复现Spring的漏洞

可能、据说、大概...

然后在某个时间点变成了这样:

复现Spring的漏洞

简单来说就是:实锤了!

复现Spring的漏洞

而文章中提到的这个地方是一个 PDF 文件:

复现Spring的漏洞

这个 PDF 文件就是本文的核心了。

但是,我想先拐个弯让你看看这个地方:

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

这里才是 Spring 关于这个漏洞的官宣。我强烈建议你自己去读一读这个官宣,里面内容比较多,我就不给大家一一翻译了。

只是给大家看看这个地方:

复现Spring的漏洞

这里说了两件事,相当于“辟谣”。

第一个是关于我之前文章中提到的废弃 SerializationUtils 方法。

图片

你看我之前的文章说的还是“疑似瓜”,说明我还是比较严谨的。

官方的博客说:

The deprecation is unrelated to this vulnerability.

弃用与此漏洞无关。

幸好我在之前的文章里面说了:

复现Spring的漏洞

这不,打脸来的那么快。但是没关系,吃瓜嘛,开心最重要,挨几巴掌,不寒碜。

复现Spring的漏洞

第二个事情是说这段时间 Spring Cloud Function 也爆出了一个高危漏洞,但是这个漏洞是在 Spring 漏洞之前爆出来的。

官方的说法是:

It is also unrelated.

这两者之间这也是不相关的。

所以,大家在吃瓜的时候要看准方向,被别一些司机带错路了,假瓜吃的津津有味,自己还不知道。

复现Spring的漏洞

然后,在我写文章的时候,这个官方博客也在不断的更新:

复现Spring的漏洞

可以看到在 14:00 更新了这个漏洞报告:

https://tanzu.vmware.com/security/cve-2022-22965

复现Spring的漏洞

在这个报告里面,再次明确了这个漏洞的先决条件:

  • 必须是 JDK 9+ 的版本。
  • 必须是 Apache Tomcat 作为 Servlet 容器。
  • 必须是以 war 的形式打包。
  • 必须是依赖了 spring-webmvc 或 spring-webflux。

我想第一个条件,就让一大批人放心了。

至少这波,不用加班加点的升级修复了。

可以安心吃瓜。

复现Spring的漏洞

开始复现

额,这么写到这里了都还没有进入正题呢。

好吧,我想闲扯的基本上也就扯完了,下面开始搞事情。

让我们回到这个地方:

复现Spring的漏洞

你访问下面这个链接,可以直接拿到这个 pdf:

https://sizeof.cat/post/springcore-rce/files/readme.pdf

打开这个 PDF 之后,你可以看到如果要复现漏洞,要求条件是这样的:

复现Spring的漏洞

你仔细思考,其实这些条件都在 Spring 官宣的先决条件内。

先不必纠结于此,主要记住我框起来的这两个点,然后直接看下面的重点。

复现Spring的漏洞

在漏洞分析里面,他提到了一句话,是重中之重:

因为我觉得需要使⽤的参数内,存在⼀个 Class 类型的属性。

什么意思呢?

就是假设我们定义一个请求对象,叫做 UserReqDto,是这样定义的:

复现Spring的漏洞

里面有一个 Class 类型的属性,就是这个意思。

确实,我纵横开发界这么久,就没有见过请求对象里面要求传 Class 的。

但是他给出了这样的一个示例:

复现Spring的漏洞

分别有两个对象,EvalBean 和 CommonBean。

其中 CommonBean 是 EvalBean 的一个属性。

这样的定义就非常的常见了吧,项目里面一抓一大把。

然后还记得我前面框起来的两个点吗?

复现Spring的漏洞

这啥意思?

上个代码你就看的明明白白的:

复现Spring的漏洞

这写法就是“Spring 的参数绑定”,这不就是我们常规的写法吗?没有看到任何不妥的地方呀?

是的,没有看到任何不妥的地方。

但是,如果你这样的代码对应的运行环境和方式,满足了前面官方提到的先决条件。

那么恭喜你,就是有漏洞的。

你就仔细想想,是不是细思极恐?

图片

那么对应的原理是啥呢?

大佬在 PDF 里面指了个路:

复现Spring的漏洞

复现Spring的漏洞

意思就是在前面的示例代码中,请求对象中虽然没有 class 熟悉,但是在 Spring 进行参数绑定的时候会凭空多出一个 “class” 属性。

那么为什么会多出来呢?

我不知道,我也没去深入研究。大概是因为反射的时候获取 bean 信息会处理所有以 get 开头的方法,所以 getClass 方法被映射成了 class 属性。

然后再想一想为什么是 JDK 9+ 以后才有这个问题呢?

我也不知道,但我盲猜一波是因为这个东西,模块化:

复现Spring的漏洞

但是我也没有具体的依据,都说了是盲猜了。

反正路指给你了,你想深入的话,可以从这条路走。

那么到底怎么发起攻击呢?

PDF 里面也写了。

你只要把代码打个 war 包,然后运行在对应的环境中,并执行下面这五个请求:

复现Spring的漏洞

就能在项目的 out 文件夹中写入一个 jsp:

复现Spring的漏洞

写入 jsp 文件啊!

老铁,这可是写入了一个 jsp 文件啊!

我不知道你有没有经历过 jsp 文件写页面的那个时代,我以前写过。

我当年特别喜欢这个东西,因为它支持热部署,修改了 jsp 页面的内容,都不用重启的。

所以,我喜欢通过 jsp 页面留下一点方便我对项目进行运维的后门操作。

后门是啥,具体就不详说了。

复现Spring的漏洞

如果你知道 jsp 的威力,你就能明白这句话的分量是多大:

这可是由别人通过构造特定的请求写入了一个 jsp 文件在你的项目里面啊!

而且,我能写 jsp 了,难道我就不能多写点其他的什么东西....

但是我必须要补充一句,如果你也想复现这个漏洞,最关键的是前面提到的“五个请求”。

然而在 pdf 里面,这五个请求的内容其实是不全的,大概缺失了 30% 的内容。

我不知道为什么,但是我猜测是作者故意的。

但是,凭借我超强的悟(瞎)性(猜),我花了一点时间,补全了这部分的请求。

所以,经过一番折腾,我本地也成功写入了这个 jsp 文件:

复现Spring的漏洞

万事俱备,只需要触发一下了。

怎么触发呢?

jsp 页面还能怎么触发,简单的很嘛。

直接访问对应链接就可以了:

复现Spring的漏洞

我能调起计算器,我就能接管你的机器。

而在这个过程中,控制台不会有任何输出:

复现Spring的漏洞

但是还是能处理正常的请求,且打印日志:

复现Spring的漏洞

潜入细无声,我就问你,怕不怕!

复现Spring的漏洞

p1n93r

从 PDF 上看,是一个叫做 p1n93r 写的这个 PDF,并且把相关测试代码开源了:

复现Spring的漏洞

但是在我看到这篇文章并点击这个开源项目的时候,发现已经 404 了:

复现Spring的漏洞

甚至,p1n93r 也已经 404 了:

复现Spring的漏洞

然后我搜索了一下这个关键词:

复现Spring的漏洞

确认这是一个安全大佬,但是不知道是红是黑。

我的搜索也就止步于此了,很明显,他主动删除了相关的项目,甚至主动让自己在 github 上消失,就是不想引起关注。

对于一个安全大佬来说,静默,就是最好的生存之道。

这让我想起了和另外一个安全大佬的对话:

复现Spring的漏洞

幸好,我这里还有另外一份源码。

好了,如果你也想要对应的源码的话。可以在公众号后台回复关键字【漏洞】就可以了。

拿着源码,配合着 PDF 看,自己去玩吧。但是可能手速得快,我怕这一份源码也被删了。

就到这。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: