看到了微步的漏洞预警信息，于是想從零開始記錄一下 nday 漏洞的複現過程。雖然這次涉及代碼審計很少，但也算一個路徑，就記錄一下吧。
首先看預警信息
首先提取關鍵詞：accessToken 默認、在 application.properties 中配置、繞過認證調用 executor
接下來我們去 xxl-job 的官方倉庫找這個文件
該文件有多個但內容一致，這裡選擇 xxl-job-admin 下的為例。我們能看到 application.properties 中 accessToken 確實有個配置項，其值就為 default_token。因為 properties 是個純靜態文件，所以不存在什麼語法變量，確定就是這幾個字符 “default_token”
好，現在我們確定了 accessToken 的值，這將是我們構造 payload 的關鍵。接下來我們要弄清楚通過這個值可以繞過什麼。也就是預警信息中所說的 executor
查看項目目錄，發現了一個相似的文件夾
點開看裡面
又有兩個，而且裡面出現了 frameless 和 springboot，推測是兩個版本或者編譯方式。
這裡不敢繼續深入，不了解話可能會變成無底洞讓我鑽進牛角尖。那麼回到最開始，看一看官方文檔，看看從裡面能發現什麼信息便於我們了解軟件架構。
通過文檔我們可以知道 xxl-job 其實是分為兩部分是類似於 docker 的那種 c/s 結構，或者說類似於中台 /agent 架構。調度中心（默認端口 8080）就是 xxl-job-admin，而執行器（默認端口 9999）則就是所謂的 executor。執行器接收調度中心發出的命令，在所在機器上執行後並返回結果。而接收上級指令一定有一個身份驗證來保證不被濫用，這個驗證就是 accessToken。
那麼現在我們大致就理清漏洞的利用思路了，很簡單就是構造一個調度中心的指令請求給執行器，當 accessToken 為默認時我們就可以冒用身份把執行器作為我們的木馬去使用。那這個請求的格式是什麼樣的呢？最開始我從代碼層面可是跟踪，但往深處太複雜就換個方向從互聯網入手。搜索關鍵詞：xxl-job executor rce，這時找到了一個很久以前的漏洞
點進去看，時同一個組建相同的問題。我們現在這個是默認值，這個洞則是空值。看下時間，最早 2022 年就有人複現分析了。那麼他的 payload 我們能不能用呢？
很顯然裡面並沒有提到 accessToken 這個字段，估計是因為空值的話根本不用傳參。但是我們得到了另一個信息，組建之間通過 RESTful API 傳送數據，那麼這個字段格式在文檔中就也一定有。回到文檔去看
好了，可以直接根據文檔去構造請求包了。（glueType 字段還有別的類型自行摸索，可能會對 bypass 有利）
文章中的指紋我們也可以直接拿來用
即: shodan request, HttpMethod not support.
也就是 body 內容為 invalid request, HttpMethod not support.
其他國產引擎語法請自行構造
接下來找個目標試試
成功執行命令並通過 dnslog 帶出
如果默認值改了，則是這樣
總的來說就是這樣。但有些時候你會發現服務器的執行器打不了。這是因為 c/s 架構，agent 不一定就非得在 admin 的那個機器上。這雖然降低了利用成功率，但某種意義上對內網橫向起到了一定作用。
最後一個小彩蛋：
2022 年執行器未授權漏洞之後官方做了補救措施，默認開始 token。但他們卻使用了一個固定的值進行硬編碼。也就是這個修復開啟了執行器繞過。正所謂，修了嗎？如修
不知道為什麼這麼簡單的一個漏洞竟然過了一年才爆出來
最後的話：雖然這次沒有從代碼審計的角度深入解析，但指出了另一條路，要善用網絡搜索和已知漏洞，這往往也是一個捷徑