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

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

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

然后只配上了四个字：

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

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

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

可能、据说、大概...

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

简单来说就是：实锤了！

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

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

但是，我想先拐个弯让你看看这个地方：

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

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

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

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

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

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

官方的博客说：

The deprecation is unrelated to this vulnerability.

弃用与此漏洞无关。

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

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

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

官方的说法是：

It is also unrelated.

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

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

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

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

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

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

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

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

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

可以安心吃瓜。

开始复现

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

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

让我们回到这个地方：

你访问下面这个链接，可以直接拿到这个 pdf：

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

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

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

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

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

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

什么意思呢？

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

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

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

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

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

其中 CommonBean 是 EvalBean 的一个属性。

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

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

这啥意思？

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

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

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

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

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

你就仔细想想，是不是细思极恐？

那么对应的原理是啥呢？

大佬在 PDF 里面指了个路：

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

那么为什么会多出来呢？

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

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

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

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

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

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

PDF 里面也写了。

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

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

写入 jsp 文件啊！

老铁，这可是写入了一个 jsp 文件啊！

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

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

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

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

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

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

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

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

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

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

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

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

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

怎么触发呢？

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

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

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

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

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

潜入细无声，我就问你，怕不怕！

p1n93r

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

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

甚至，p1n93r 也已经 404 了：

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

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

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

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

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

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

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

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

就到这。