漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

雲鼎實驗室發表於2020-07-02

文章來源：freddychi(遲長峰)@騰訊安全雲鼎實驗室

北京時間2020-6-22日Apache官方釋出了Dubbo 2.7.7版本，其中修復了一個嚴重的遠端程式碼執行漏洞（CVE-2020-1948），這個漏洞是由騰訊安全玄武實驗室的ruilin提交，該漏洞允許攻擊者使用任意的服務名和方法名傳送RPC請求，同時將惡意序列化引數作為有效載荷，當惡意序列化的引數被反序列化時將執行惡意程式碼。該漏洞與 CVE-2017-3241 RMI反序列化漏洞有點類似，都是在遠端呼叫過程中通過方法引數傳入惡意序列化物件，服務端在解析引數進行反序列化時觸發。Dubbo Github Star數量32.8k，知名度不亞於fastjson，被大量企業使用，包括一些知名互聯公司，漏洞影響十分廣泛。

補丁分析

從補丁對比檔案來看，在DecodeableRpcInvocation.java檔案133-135行增加了對Method方法進行驗證，如果驗證不通過則丟擲非法引數異常終止程式執行，核心程式碼程式碼如下:

if (!RpcUtils.isGenericCall(path, this.getMethodName()) && !RpcUtils.isEcho(path, this.getMethodName())){throw new IllegalArgumentException("Service not found:" + path + ", " + this.getMethodName());}

跟進isGenericCall和isEcho方法，發現驗證邏輯十分簡單，如果method等於$invoke、$invokeAsync或者$echo則返回true。不得不說此處站在開發角度思考是沒問題的，非Dubbo自帶service中的$invoke、$invokeAsync、$echo方法以外，其他函式名全部丟擲異常，但是萬萬沒想到RPC呼叫過程中方法名是使用者可控的，所以攻擊者可輕易的將method設定為其中任意一個方法來繞過此處限制。

public static boolean isGenericCall(String path, String method) {return "$invoke".equals(method) || "$invokeAsync".equals(method);}

public static boolean isEcho(String path, String method) {return "$echo".equals(method);}

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

通過對歷史版本的回溯，發現在2019.10.31日的一次提交中DubboProtocol類的getInvoker函式的RemotingException程式碼塊中增加了getInvocationWithoutData方法，對inv物件的arguments引數進行置空操作，用來緩解後反序列化攻擊，此處正是CVE-2020-1948漏洞後反序列化利用的觸發點。

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

如下getInvocationWithoutData函式，可能是為了方便開發者排查問題，如果系統配置log4j debug級別或者不配置任何其他級別，則不會將inv物件的arguments引數設定為null，會直接返回invocation物件，所以還是存在被後反序列化漏洞攻擊的風險。所謂後反序列化簡單理解就是漏洞是在物件被正常反序列化之後觸發，比如在異常處理中對成功反序列化的物件進行間接或直接的函式呼叫，從而導致的程式碼執行。

/*** only log body in debugger mode for size & security consideration.   *   * @param invocation   * @return   */private Invocation getInvocationWithoutData(Invocation invocation) {if (logger.isDebugEnabled()) {return invocation; }if (invocation instanceof RpcInvocation){RpcInvocation rpcInvocation = (RpcInvocation) invocation;rpcInvocation.setArguments(null);return rpcInvocation;}return invocation; }

由上可知，DecodeableRpcInvocation#decode請求體解碼函式的驗證邏輯存在繞過DubboProtocol#getInvocationWithoutData函式的後反序列緩解存在無效情況。

構造POC

知道了method的驗證邏輯，修改CVE-2020-1948 Poc中的的service_name和method_name引數的值，分別為：org.apache.dubbo.rpc.service.GenericService和$invoke。

在DecodeableRpcInvocation類中的decode函式方法起始處設定斷點進行Debug。

程式碼123-124行首先通過path（對應客戶端的service_name）引數來獲取服務描述物件repository，該物件包含了服務名、介面型別和方法資訊等。

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

繼續跟進，由於params是我們構造Gadget, 最終repository物件獲取到函式描述物件為null。

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

繼續跟進,由於pts變數沒有被賦值，所以pts== DubboCodec.EMPTY_CLASS_ARRAY表示式成立, 接著進入isGenericCall函式，由於rpc呼叫設定的method的值為$invoke，此處可以驗證通過。

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

最後進入hession反序列化流程，成功執行了程式碼。

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

可以看到呼叫棧如下：

漏洞分析 | Dubbo2.7.7反序列化漏洞繞過分析

另外，Dubbo暴露的埠如果開啟了Telnet協議，攻擊者可以連線到服務通過ls命令檢視service、method等資訊，甚至可以執行shutdown危險操作直接關停服務。白帽子@CF_HB在Dubbo 2.6.8版本通過Telnet服務中InvokeTelnetHandler.java類在處理invoke命令時的漏洞結合Fastjson反序列化漏洞成功進行了利用。隨著越來越多的安全研究人員對Dubbo安全問題的關注，相信後面會有更多的漏洞被挖掘出來。