技術文章 » ThinkPHP6.0.13反序列化漏洞分析

ThinkPHP6.0.13反序列化漏洞分析

2022-10-09 22:00:51
最近有點閒下來了，不找點事幹比較難受，打算找點漏洞分析一下，於是就打算看看TP的一些漏洞，ThinkPHP6.0.13是TP的最新版，八月份有師傅提交了一個issue指出TP存在反序列化問題，網上也有些師傅分析了一波，不過斷點下的比較多，而且部分方法沒有闡明其用途，所以我也嘗試詳細的分析一波。下面先給出POC

1.png

php入門到就業線上直播課：進入學習
API 檔案、設計、偵錯、自動化測試一體化共同作業工具：

分析

首先看看POC的起始點

2.png

3.png

發現起始點在Psr6Cache這個類，我們進入這個類，不過沒有發現__destruct或者__wakeup等常見的反序列化起始魔術方法，推測應該在其父類別AbstractCache這個抽象類中。跟入AbstractCache類

4.png

如圖，成功發現本次反序列化鏈子的起始類。這裡我們可以控制autosave這個屬性為false，從而進入save方法。

回到Psr6Cache類檢視這個方法

5.png

可以發現，pool屬性和key屬性我們都可控。因此可能存在兩種路線，呼叫不同類的同名方法（getItem）。或者是直接嘗試觸發__call方法。我們來看看POC作者是怎麼讓反序列化進行下去的。

6.png

作者用構造方法傳入了exp，exp其實就是在範例化Channel類。我們進入Channel類檢視

7.png

Channel類中有一個__call方法，那麼作者是選擇觸發__call來讓鏈子繼續下去。這個call方法接受了兩個引數，method是寫死的(getItem)，parameters是可控的（即前面可控的key屬性）

8.png

跟入log方法檢視，其接受三個傳參（但是其實對後續的鏈子沒啥用），傳入record方法

9.png

跟入record方法

10.png

再返回檢視作者的POC，發現其控制lazy屬性為false，讓函數進入最後一個if分支執行save方法

11.png

那麼save方法應該是比較關鍵的方法了，跟入save方法，這裡面有三個可能被利用的點，作者選擇了哪一個呢？

12.png

根據POC不難發現作者選擇了控制logger屬性，利用建構函式對其賦值，令其為Socket類的物件

13.png

14.png

在這個類中，我們找到了一個複雜的同名方法，其中有大量的操作。

15.png

我們繼續來看作者是怎麼構造的，作者控制config屬性，給其賦值為陣列。陣列有如下內容

16.png

關鍵在於這兩個鍵值，作者控制config，讓程式執行到呼叫invoke方法的分支

17.png

同時，app屬性可控，作者令app屬性為App類的物件，我們進入App類

18.png

這裡先看看App類的的exists方法的情況，在其父類別中找到了這個方法

19.png

繼續往後，這裡對App類進行了唯一一個操作，控制了instances屬性的值。這裡控制其值是為了進入Request類，並且執行url方法

20.png

21.png

作者在這裡對Request類做出唯一的操縱，就是控制url屬性的值。可以看出，如果url屬性存在，那麼就會進入第一個分支，其值等於本身。

22.png

同時又注意到，complete我們之前傳入的是true。因此最終返回的結果就是$this->domain().$url，url我們已經控制了，那麼domain方法返回什麼呢？

23.png

OK，這點我們就不用看了。分析了這麼多，我們得到了$currentUri最後的值，就是：

http://localhost/

24.png

currentUri作為一個陣列被傳入invoke了，根據鏈子的長度，達到invoke，我們的反序列化之旅就快結束了

25.png

檢視invoke，App類找不到這個方法，在他的父類別裡找到了這個方法

26.png

這裡可以看到。這個函數內有三分支走向，那麼最終會走向哪裡呢？根據我們之前$config[‘format_head’]的傳入， 首先我們傳入的這個物件不是Closure的範例或者子類，並且也不滿足第二個分支的條件

27.png

因此進入到到第三個分支。我們跟進invokeMethod()方法。這裡傳入的$callabel就是[new \think\view\driver\Php,'display']、而$vars就是[‘http://localhost/’]

28.png

注意，我們傳入的$method是陣列，因此進入第一個分支。把new \think\view\driver\Php （即物件）賦值給$class，’display’（即方法名）賦值給新的$method。

然後下面進行了一個判斷，如果$class是物件，那麼其值就為它本身，因為我們傳入的是物件，所以這裡沒什麼變化。然後進入最關鍵的程式碼

可以看到，把物件new \think\view\driver\Php 以及方法 display傳入了ReflectionMethod。

29.png

在最後，呼叫invokeArgs方法，傳入了new \think\view\driver\Php物件，同時傳入了$args

30.png

那麼args是什麼呢？

31.png

我們跟入之後發現是一個處理常式，因為本人比較懶，而且到這都快分析完了，就不去硬讀了，直接給結論，總之我們傳入的 $vars ，也即 [‘http://localhost/’] 其中的關鍵部分保留了下來，並且進入到了後續的傳參中

32.png

繼續往後看，對於這個函數(invokeArgs)，可以簡單的類比call_user_func()，因此最後的關鍵程式碼其實只有這兩行

33.png

也即

$reflect = new ReflectionMethod(new \think\view\driver\Php,’display’);
return $reflect->invokeArgs(new \think\view\driver\Php,’ ’)
登入後複製

常看tp反序列化的朋友就知道，已經結束咧！畢竟呼叫display方法了。但是上述這個呼叫ReflectionMethod類的操作到底是什麼呢？我們可以藉助如下範例來演示。所以說這玩意和call_user_func很像

34.png

最後是display方法，沒什麼好說的了，content傳入display方法中，eval執行命令了

35.png

結語

TP的鏈子一如既往的有意思（以及複雜），特別是最後的ReflectionMethod類的用法上，如果不瞭解這個類以及類中的方法組合可以實現類似call_user_func函數的作用的話，那麼就很容易錯過這樣一個精彩的漏洞。

【相關教學推薦：】

以上就是ThinkPHP6.0.13反序列化漏洞分析的詳細內容，更多請關注TW511.COM其它相關文章！