Fastjson反序列化漏洞利用分析

标签：ack   pac   imp   and   lookup   目标   编码   执行流程   exce   

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 = 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的应用，实现代码执行，相对来说第一种方式杀伤力更强一些。所以还请务必将组件升级到最新版本，来避免攻击者对此漏洞的攻击。

Fastjson反序列化漏洞利用分析

标签：ack   pac   imp   and   lookup   目标   编码   执行流程   exce   

原文地址：https://www.cnblogs.com/dearroy/p/13541254.html