前天发布了《我想问问：你昨晚吃到 Spring 的惊天算夜瓜了吗？》这篇文章，没想到阅读量居然这么高。
这篇文章实在是我那天晚上知道这个“瓜”之后，看到很多技能群都在谈论，大概在 23 点 30 分的时候开始想写一篇，然后卡着零点发。
由于我想着本来着凭借我的手速，写这篇文章 30 分钟够够的吧。
于是我边写边吃瓜，吃着吃着韶光就来到了第二天零点。
当时我就想：哎，这拖延症也来越严重了...反正都已经到凌晨了，要不打几把欢快斗地主，欢快欢快？昨天把豆子输光了，本日又可以免费领豆子了。
以是....
我又打了几把斗地主。很快啊，又没有豆子了。
于是开始苦哈哈的开始写文章，一不留神就写到第二天凌晨 1 点 25 分。
为什么我记得这么清楚呢？
由于我写这篇文章的时候还是很愉快的，毕竟吃 Spring 的大瓜，一辈子也吃不了几次。
我看了一下我的腕表记录，在 1 点 25 分之后，我的心率开始低落，以是该当是这个时候写完文章的：
哎，这件事情再次印证了写"大众号的，或者说做自媒体的人的一个“黄金定律”：
一些文章写的时候以为这文章真牛逼，我花了这么多韶光写出来，这玩意一发出去肯定是爆款啊，这都不火，天理难容啊！
结果，真的发出去之后，无人问津。
每每是不经意间写的东西，溘然就火了。
这东西，你找谁说理去？
言归正传
好了，言归正传。
我真的复现了这次 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 文件在你的项目里面啊！
但是我必须要补充一句，如果你也想复现这个漏洞，最关键的是前面提到的“五个要求”。
但是在 pdf 里面，这五个要求的内容实在是不全的，大概缺失落了 30% 的内容。
我不知道为什么，但是我预测是作者故意的。
然后，凭借我超强的悟（瞎）性（猜），我花了一点韶光，补全了这部分的要求。
以是，我本地也写入了这个 jsp 文件：
万事俱备，只须要触发一下了。
怎么触发呢？
jsp 页面还能怎么触发，大略的一比嘛。
直接访问对应链接就可以了：
我能吊起打算器，我就能接管你的机器。
而在这个过程中，掌握台不会有任何输出：
但是还是能处理正常的要求，且打印日志：
潜入细无声，我就问你，怕不怕！
p1n93r
从 PDF 上看，是一个叫做 p1n93r 写的这个 PDF，并且把干系测试代码开源了：
但是在我看到这篇文章并点击这个开源项目的时候，创造已经 404 了：
乃至，p1n93r 也已经 404 了：
然后我搜索了一下这个关键词：
确认这是一个安全大佬。
我的搜索就止步于此了，很明显，他主动删除了干系的项目，乃至主动让自己在 github 上消逝，便是不想引起关注。
这让我想起了和其余一个安全大佬的对话：
对付一个安全大佬来说，静默，便是最好的生存之道。
