0x01 前言

早在 2015 年 1 月 28 日， Gabriel Lawrence（@gebl）和 Chris Frohoff（@frohoff）就發布了關于反序列化的演講，演講中 frohoff 公開了他寫的 Java 反序列化漏洞利用的工具 ysoserial。關于 Java 反序列化相關漏洞的背景和相關知識可以看我之前的文章《Java 反序列化取經路》。

7 年后的今天，反序列化漏洞依舊是 Java 安全漏洞中的當紅流量明星，高危中的高危，尤其在各大中間件和框架中。而與其他漏洞類型不同的是，Java 反序列化利用的核心，并不是漏洞的入口點，而是環境中的依賴 —— 反序列化 Gadget。

隨著時間的沉淀，各個比較常見的組件庫中的 Gadget 被挖掘出來，在用戶量較大的 ysoserial 以及 marshalsec 中都公開了一些常見組件的鏈。

但是隨著各個組件的更新、各種基于黑名單/過濾層的防御模式的出現，這些常見反序列化利用 Gadget 的可用性急速降低，攻擊者往往面臨著在黑盒進攻時，明明找到了入口點，但是無鏈可用的情況。

遇到這種情況怎么辦？c0ny1 師傅在 @Joshua Bloch的《effective java》 基礎上提出了利用反序列化炸彈的技巧，通過消耗部分性能達到間接延時的作用，來探測 class 是否存在，文章在這里。

珂字輩師傅實現了修改 URLDNS Gadget 通過獲取類 hashCode 并通過 DNSLOG 回顯的方式來嘗試解決此問題，項目在這里。

但是當利用鏈存在但因為某種原因被 Ban 掉，或者當類存在，但是依賴版本已經更新，關鍵代碼位置已經不再包含可反序列化利用的邏輯時，攻擊者還是會束手無策。所以針對目前的反序列化漏洞利用，有以下幾個局限性：

1. 常利用的 Gadget 就那幾個，在目標環境有防御措施的情況下，幾乎無法利用；
2. 客戶端更新依賴包版本后，原有的 Gadget 將會失效；
3. 目前的 Gadget 由于為了高利用性，通常是挖掘在同一個依賴下的類 + JDK 自帶的類組成鏈，但其實還可以在幾個常用依賴中找可以串聯起來的類。

在對 ysoserial 中全部鏈進行學習和跟蹤后，我發現時至今日，要在一個新組件中挖掘一條新鏈也并不容易，需要對組件的源碼實現、很多關鍵類的關鍵方法的調用有十足的了解，并在積累了一定的安全知識后再進行對 kick-off/gadget/sink 進行挖掘和組成。在真實的業務代碼中，開發人員引用了更多的依賴，如果手動挖掘，需要的精力和時間將會指數級上升。

所以，能不能有辦法可能較為快速的挖掘呢？

網飛 Platform Security Team 的 Ian Haken 在 2018 年 8 月的 DEF CON 26 上給出了他的答卷：GadgetInspector。項目在這里，PPT 在這里，會議視頻在這里。

按照其介紹，本項目可以自動化挖掘反序列化利用鏈。本篇文章則是對該項目的學習、研究以及優化改造的記錄。

關于項目的介紹和分析，網上已經存在了不少優秀的文章，本文內將不再重復相關的信息，在筆者學習和研究時，主要參考了以下幾篇文章，先列舉一下，作為本文的前置知識：

• 簡單理解污點分析技術 by k0rz3n
• java反序列化利用鏈自動挖掘工具gadgetinspector源碼淺析 by threedr3am
• Java 反序列化工具 gadgetinspector 初窺 by Longofo
• GadgetInspector源碼分析 by fynch3r

0x02 明確目標

在開始改造之前，首先要明確目標：

核心目的是對包含了若干個依賴庫的用戶代碼進行自動化挖掘反序列化利用鏈，預期的效果是可以根據現有的知識儲備挖掘在用戶的整個代碼環境下可能由多個依賴組成的反序列化利用鏈。

很多師傅在 GadgetInspector 的核心代碼上進行改造，使其能力可以覆蓋 fastjson/jackson/xstream 甚至是常規漏洞的分析與挖掘，不過本次筆者專注于反序列化漏洞，對其他類型漏洞將不進行覆蓋。

0x03 關鍵流程及技術分析

這一小節來用文字簡單描述一下 GadgetInspector 對于 “自動化挖掘反序列化利用鏈” 這一目標的技術實現過程中的關鍵流程。

一句話來說，GadgetInspector 使用 ASM 對 Java 類字節碼進行污點分析來挖掘反序列化利用鏈。考慮到在很多時候不一定能拿到用戶的源代碼，所以這一思路還是非常符合現實情況的。

信息收集

GadgetInspector 使用 ASM 的 ClassReader 來讀取全部類和方法的信息，使用自定義 MethodVisitor 在讀取類和方法的指定位置來記錄信息。記錄的信息有全限定類名、類中包含的方法、方法名、方法描述符等。

處理完基礎信息后，會解析類的繼承關系、方法繼承關系、構造類和方法的映射等等相關信息的映射，接下來使用 DFS 算法對方法的調用鏈進行逆拓撲排序，其實就是使用了遞歸的后序遍歷，并解決了環式調用和重復排序的問題，將方法復雜的調用圖轉為線性的序列，供后續的遍歷和處理。

污點分析

污點分析這部分是調用鏈挖掘的重中之重。

GadgetInspector 使用了自定義 MethodVisitor，模擬幀棧的變化，或者說是模擬本地變量表（local variables）和操作數棧（operand stack）的變化來進行污點傳播的追蹤，模擬的過程實際是參照了 ASM 提供的 AnalyzerAdapter 的思路。

這一部分共分為兩段，第一段是方法內的污點傳播，即方法的入參能否影響到方法返回結果的分析過程。

GadgetInspector 通過在自己模擬的棧頂數據打標記（入參索引），并在訪問字段、訪問其他方法等操作時根據自定義規則判斷是否能夠傳播污點來對棧頂數據打標記或清空的方式來進行污點傳播的分析。直到方法 return 時，取出棧頂返回數據的污點標記，得到哪個入參對其造成了影響。

第二段是方法間的污點傳播，即一個方法調用下一個方法時，調用者（caller）方法能否影響到被調用者（target）方法的入參的分析過程。

同樣的思路進行方法間調用的污點分析，使用調用者的入參索引作為污點，傳播至被調用者入參時，認為其可以影響到下一個方法的調用。

Source 與 Sink

曾在《Java 反序列化取經路》中提到，反序列化 Gadget 的組成一共有三個：Kick-off，Chain，Sink。而這里的 Kick-off 在靜態分析中則稱之為 Source。

對于反序列化漏洞而言，一般是從重寫了 readObject 等方法的邏輯開始，進行相關的調用，最終調用到一些可能造成危害的函數，如執行命令、文件寫入等。

GadgetInspector 定義了一些 Source 點：重寫 finalize 方法、重寫 readObject 方法、InvocationHandler子類的 invoke 方法、重寫 equals/hashCode 方法以及指定包下的點如 Closure 的 call/doCall 方法。

同時定義了一些 Sink 點：FileInputStream/FileOutputStream 的創建與寫出、Runtime 執行命令、反射調用、URLClassLoader 實例化、URL 建立連接等等和一些特定包下的利用點如 PyCode 等。

反序列化鏈的構造

有了 Source，有了 Sink，有了污點分析的結果，就開始最終的反序列化鏈的構造了。

GadgetInspector 構造反序列化鏈從 Source 點方法出發，尋找該方法能污染的方法，并從這個方法和他子類中的方法中繼續尋找下一個能污染的方法，直到遇到 Sink 點，就組成了利用鏈。

0x04 改造之路

在了解了實現思路，過了一遍源代碼后，可以發現在部分具體細節中，GadgetInspector 還是存在著一些問題，這些問題導致著很大程度的誤報和漏報，雖然 Soundness 和 Completeness 永遠是需要平衡的，但是這里還是可以通過一些細節的處理來對其功能進行優化和提高。

繼承方法

在構造反序列化利用鏈時，會根據之前生成的污點傳播信息獲取一個方法能夠污染的方法，并判斷這個方法所在類和他的子類是否存在可以反序列化的類，再進行進一步的查找。

這個邏輯就存在一個問題，在 GadgetInspector 標記一個方法時，對方法的簽名加入了所在類的信息，那如果一個類的方法是繼承至其父類的方法，那可能會導致獲取這個類的方法時的結果為空，從而漏掉了調用鏈的構造。

因此需要在構造鏈時對繼承至父類的方法進行處理。

【來自 threedr3am 師傅的版本】

路徑爆炸

在循環過程中，由于各種原因可能導致最終得到的調用鏈非常之長，并且中間具有多次重復性的調用方法的情況。

需要進行去重和對調用鏈中方法出現的次數增加閾值等處理。

【來自 5wimming 師傅的版本】

transient 字段

標識著 transient 的字段將不會加入到序列化和反序列化的流程中，這是眾所周知的事實，因此 GadgetInspector 在收集信息和污點分析過程中遇到 transient 修飾的字段時都進行了忽略。

但實際上，transient 字段只代表開發人員不希望 Java 原生序列化流程來處理它，不代表開發人員自己不會處理它，可能通過自定義 writeObject/readObject 方法內的邏輯來還原對象的狀態，因此<font color="red"> transient 修飾字段的對象不會被自動反序列化，但是可以參與反序列化流程，前提是用戶在調用前對其進行了處理。</font>

例如 ysoserial 中的 MozillaRhino1 鏈中用到的 org.mozilla.javascript.MemberBox 類，雖然其成員變量都由 transient 修飾，看起來好像不能參與序列化/反序列化，但類中定義了 writeMember/readMember 方法用來在 writeObject/readObject 中調用中還原，依舊可以參與鏈條。

但作為靜態分析，不能完全開放對 transient 的限制，還是需要在某些維度進行判斷。

動態代理

在使用中可以發現， GadgetInspector 是無法完整掃出經典 CC 鏈和一些常用的 ysoserial 中的鏈的，這是為什么呢？

原因是在這些鏈條中，部分 gadget 之間的調用本就不是串聯的，而是在構造時使用了動態代理技術，通過 InvocationHandler 實現類的 invoke 方法中的邏輯進行向后的觸發。

拿 CC1 舉例，是使用 AnnotationInvocationHandler 生成的動態代理類調用 AnnotationInvocationHandler#invoke 方法觸發 TransformedMap#get 方法，此時可以將其作為 Source 點進行處理，GadgetInspector 就是這么做的。

但是在 Jdk7u21 等鏈中，則是觸發調用 AnnotationInvocationHandler#equalsImpl 方法來調用代理對象的全部方法。此時則可以將其作為 Sink 點處理。

再舉一個例子，在 CC3 鏈中，除了入口點， AnnotationInvocationHandler 還充當了代理 LazyMap 的動態代理 handler 類，串聯反序列化鏈的作用。

除了 AnnotationInvocationHandler 之外，在一些特定的包中還有能觸發特定方法的 InvocationHandler 的子類，是反序列化鏈的構造有更大的靈活空間。

所以可以看到，InvocationHandler 在反序列化構造中可以起到相當大的作用，既能當 Source，又能當 Chain，還能當 Sink，因此需要對其進行格外的處理。

Agent 技術加持

GadgetInspector 是靜態的分析手段，借助了 guava 的工具類獲取指定 ClassLoader 下的全部類的資源信息，先不說 GadgetInspector 自己的依賴會污染到最終結果，還面臨的問題是程序運行時從字節碼動態加載，或根據某些規則動態生成的類將無法納入利用鏈中。

雖然目前沒有這樣的利用鏈，但是理論上并不排除，而且也許還可能繞過一些限制，因此這里產生的一個想法就是加持 Java Agent 技術來獲取運行系統中全部的類。

這部分在做的時候對實際效果不報有期待，但如果效果好的話，也可以算是給 Java Agent 產品的一種賦能。

Sink/Source 點增強

這里的增強主要分為兩個，一個是補充，一個是前/后置。

GadgetInspector 內置的 Sink 和 Source 點都不全，需要更完全的補充，例如 Source 點通用的只寫了 ObjectInputStream#readObject、Object#finalize/hashCode/equals。Sink 點只寫了一點點可利用的點，在目前利用手段多種多樣情況下，實際上有非常多可以補充的點。

另外一個是“ Source 點后置”以及“Sink 點前置”。在目前已經掌握到了一些基礎信息后，沒必要將全部的工作都交給污點分析和最終的利用鏈組合邏輯。可以利用已有的知識將利用鏈的構造進行縮短。

例如：可用明確利用的點比如 org.apache.commons.collections.Transformer#transform 可以直接做為 sink 點，沒必再走到 Method#invoke。用動態代理生成的類作為反序列化入口時可以直接使用 java.lang.reflect.InvocationHandler#invoke 作為入口點等等。

反射

GadgetInspector 內置了一些白名單污點流，默認一些類的方法的哪幾個參數可以污染返回值，其中一個如下：

{"java/lang/Class", "getMethod", "(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;", 0, 1}

在 Sink 點中，肯定是有 java.lang.reflect.Method#invoke 反射方法調用作為最終的執行點，但是調用之前需要先獲得 Method 對象：

• 這個 Method 對象可能是可反序列化類的成員變量。
• 這個 Method 對象可能是在調用過程中用 Class#getMethod 獲得的。

第一種情況比較好處理，直接構造進去即可；第二種情況則不然，如果要實現任意方法的反射調用，Class#getMethod 的兩個參數都要可控。但在靜態污點分析中，有一個參數能影響到結果，這個污點就能傳過來。

所以反射和類似的 Sink 點勢必要導致一些誤報。這里可以選擇在后期進行人工參與，也可以選擇針對反射的 Sink 點進行特殊處理。

其他

還有其他一些亂七八糟的小 BUG ，直接修復一下。

0x05 Gadgetor

針對上一節提出的一些問題和處理思路，我將 GadgetInspector 按照個人喜好的代碼風格進行了重構，并增強或修改了部分的處理邏輯，形成了新的輪子，這里簡單粗暴將其命名為 Gadgetor。

關鍵的模擬 JVM 幀棧的污點分析的邏輯部分沒有改動，但是針對其他的發現流程進行了優化和重寫。

Gadgetor 的邏輯看起來也許會更清晰一些，不是更好，不是更優雅，只是也許更清晰一些，并且有了比較清晰的注釋，非常適合閱讀。

這里簡單過一下項目結構，總體的邏輯與之前描述的一致。

收集生成各種信息，記錄各種映射。

逆拓撲排序。

污點分析。

剩下就是利用鏈的構造，主要是優化邏輯，以及對 Sink 點進行了較大程度的豐富。

并且將一些已知反序列化鏈的關鍵觸發位置進行了 Sink 點前置。

就不再貼出過多的代碼了。目前由于擴展之后的 Gadgetor 雖然能掃出利用鏈，但誤報也相對較多，需要人工參與的部分比較多，還需要繼續更新和優化，目前代碼暫時先不放出來，主要是期待與師傅們進行思路的交流，在沉淀一段時間后再進行開源（懂的都懂）。

0x06 效果

光說不練假把式，找一個開源項目試一下。

從圖中可以看出，測試的項目得到了 6 個反序列化利用鏈，經過人工審查后，發現雖然有誤報，但是還是有所收獲的。

0x07 TODO

在這個基礎上還可以有一些有趣的待實現的功能，比如：結合中間件的依賴進行挖掘、結合 IAST 也許可以自動化構造 Payload 等等。