侧边栏壁纸
博主头像
why

一个主要敲代码,经常怼文章,偶尔拍视频的成都人。

  • 累计撰写 197 篇文章
  • 累计创建 11 个标签
  • 累计收到 101 条评论

我滴个乖乖,我复现了Spring的漏洞,害怕!

why
why
2022-04-01 / 0 评论 / 0 点赞 / 262 阅读 / 3,106 字
温馨提示:
关注公众号why技术,第一时间接收最新文章。

你好呀,我是歪歪。

前天发布了《我想问问:你昨晚吃到 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” 属性。

那么为什么会多出来呢?

我不知道,我也没去研究。反正路指给你了,你想深入的话,可以从这条路走。

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

PDF 里面也写了。

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

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

写入 jsp 文件啊!

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

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

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

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

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

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

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

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

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

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

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

所以,我本地也写入了这个 jsp 文件:

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

怎么触发呢?

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

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

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

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

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

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

p1n93r

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

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

甚至,p1n93r 也已经 404 了:

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

确认这是一个安全大佬。

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

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

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

好了,如果你也想要对应的源码的话。

在公众号后台回复关键字【漏洞】就可以了。拿着源码,配合着 PDF 看,自己去玩吧。

就到这。

0

评论区