我真的復現了這次 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 上消失，就是不想引起關注。

對于一個安全大佬來說，靜默，就是最好的生存之道。

這讓我想起了和另外一個安全大佬的對話：

就到這。

技術交流群

最近有很多人問，有沒有讀者交流群，想知道怎么加入。

最近我創建了一些群，大家可以加入。交流群都是免費的，只需要大家加入之后不要隨便發廣告，多多交流技術就好了。

目前創建了多個交流群，全國交流群、北上廣杭深等各地區交流群、面試交流群、資源共享群等。

有興趣入群的同學，可長按掃描下方二維碼，一定要備注：全國 Or 城市 Or 面試 Or 資源，根據格式備注，可更快被通過且邀請進群。

▲長按掃描

往期推薦 不要簽字！不要簽字！不要簽字！最近違法裁員猖獗，這里單獨給大家一些應對參考！重磅！俄羅斯將與全球互聯網斷開，啟用本國互聯網“Runet”！問八股文的公司都是垃圾！？

如果你喜歡本文,

請長按二維碼，關注?Hollis.

轉發至朋友圈，是對我最大的支持。

點個?在看?

喜歡是一種感覺

在看是一種支持

↘↘↘

總結

以上是生活随笔為你收集整理的我滴个乖乖，我复现了Spring的漏洞，害怕！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。