0x00 前言
話說夏天的某個早晨，筆者突然從夢中驚醒，耳邊就直接傳來一段低語：
炎炎夏日宅在家無聊？不如 （跟我一起做複讀機，複制這段話再發出去，每天收入0元，我和身邊的朋友都在做，反正閑着也是閑着。吃飽了也是撐着，不如挨頓罵） 跟我一起挖個 CNVD 原創漏洞。反正閑着也是閑着，吃飽了也是撐着，不如找機會點綴下履歷、豐富下經驗 ~
聽完之後忽覺一陣激靈，好久才回過神來：莫非這就是傳說中的天降神谕？真所謂垂死病中驚坐起，老天叫我去挖洞啊！既然如此那還想什麼，開沖開沖！！
0x01 開搞
衆所周知，擷取 cnvd 原創漏洞證明無非兩種途徑。一個是送出重要關基的事件型漏洞，另一個就是送出通用型漏洞。這裡選擇第二種方式。因為直覺告訴我大型關基的漏洞應該早就在各種攻防演練中被挖得差不多了，而自己人菜技拙，何德何能和衆大佬争功？
于是構造一波 fofa 關鍵字——同理，常見的、比較有影響力的開源項目大多也被大佬們審計得差不多了，是以這裡直接從 fofa 找案例，然後從案例反查廠商，運氣好的話也能撿到個小通用。一番挑肥揀瘦後找到了個疑似的軟柿子（厚碼見諒/doge）：
【——全網最全的網絡安全學習資料包分享給愛學習的你，關注我，私信回複“領取”擷取——】
1.網絡安全多個方向學習路線
2.全網最全的CTF入門學習資料
3.一線大佬實戰經驗分享筆記
4.網安大廠面試題合集
5.紅藍對抗實戰技術秘籍
6.網絡安全基礎入門、Linux、web安全、滲透測試方面視訊
界面比較樸實無華。之是以判斷是個軟柿子是因為簡單測試下來發現目标存在目錄周遊的低級問題：
對本人來說，一些低級問題的出現也可以看成衡量開發人員安全意識高低的一個名額。也就是說，這個站出現其他更嚴重安全漏洞的可能性比較大。于是既然鎖定了目标，那麼依照慣例，先簡單判斷了下網站的情況：
- 看了下登入頁面的樣式和 html 源碼，代碼風格放蕩不羁，符合小廠商比較随性的作風，而且 upload 目錄存在目錄周遊，至少可以說明運維人員比較粗心大意，可能存在漏打更新檔之類的情況（而且通常一些比較有安全意識的 cms 開發人員，都會熱心地在 upload 、attachments 等目錄下手動加上一個空白的 index.html 來避免因運維配置錯誤而産生的目錄周遊。是以如果從這個角度來看，說連開發人員安全意識也不足也不為過）
- Cookie 中 存在鍵名為 JSSESSION 的 Cookie、404頁面顯示web容器為tomcat8.5，可判斷後端語言是Java。是以也可以嘗試 Tomcat、Weblogic、 Jboss、shiro、fastjson 等容器、中間件群組件的漏洞。
- 簡單看了下 js 等靜态資源，沒有發現可直接利用的注釋或隐藏的接口等資訊。但頁面展示了該系統配套使用的一個 APP，後期或許可以從 APP 入手嘗試挖掘一些 web 界面沒有展示出來的接口
有了簡單的判斷和猜想之後，要做的就是逐個驗證了。
既然目标站點後端語言為 Java，那麼先上一波 shiro 的探測。畢竟就算 Tomcat 和 Weblogic 之類的可以直接打到，感覺也隻能算是中間件的漏洞，而不是這個 web 系統本身的通用。
shiro 的探測這裡用到的是 burpsuite 的一款被動探測插件 shiroscan ， github 位址是 https://github.com/Daybr4ak/ShiroScan
插件安裝好後，浏覽測試頁面，不足須臾，插件的 ShiroScan 的視圖果然就給出了探測結果：shiro key scan unknown error：
瞧一眼插件的原始請求和伺服器的響應，基本可以确認 shiro 應該是存在的了，出現這樣的結果可能是插件内置的 shiro key 不夠多。于是又不甘心地輪換了幾個 shiro 的利用工具去測試，可惜結果都不如人意：
0x02 峰回路轉
眼看 shiro 一把梭這條路是走不通了，又順手測了測登入框的注入、Cookie的僞造等一些明面上能測的東西。最後還剩 fastjson 這個猜想還沒有辦法進一步驗證了——因為就目前為止，系統暴露出來的功能除了一個登入，就再沒有其他的了。更重要的是，即使隻是這個登入頁，其所送出的資料也不是 json 格式的，是以個人猜測這裡存在 fastjson 漏洞的可能性比較低。于是挖掘的重點轉向登入頁挂着的配套 APP 上，希望至少可以從中挖出一些 web 界面沒有展示出來的接口吧——當然，如果是未授權或者是存在 fastjson 漏洞的接口那就更好了。
說幹就幹。眼看飲茶時間又快到了，挖洞哪有喝茶重要。是以先不考慮 APP 加殼的問題，直接下載下傳 APK，改字尾為 .zip 打開：
存在兩個 dex 檔案，這裡也先不去探究哪個才是最要緊的了，總之兩個都解壓出來，分别改名為 xxx1.dex 和 xxx2.dex：
接着 dex2jar 伺候，得到 jar 包：
最後，jd-gui 打開，順利得到源碼，似乎可以撿漏逆襲：
得到源碼後，全局搜尋諸如 ：”username“、”password“、”host“、”hostname“ 、”domain“ 、”secretkey“、”publickey“、”upload“之類的字眼。因為經驗告訴我，運氣好的話可能可以直接得到一些可利用的寫死資訊或可未授權通路的敏感接口，比如：
顯然，從圖中代碼不難看出，系統确實存在一個名為 appuploadfileservice/uploadfile 的接口，而且該接口在處理用戶端送出資料前可能還沒有任何身份校驗機制。為了證明這個猜想，根據反編譯得到的代碼，在 burpsuite 中按下面推測大膽構造了請求：
first 和 offset 使用代碼截圖裡的預設值就可以了；param 參數的作用未知；至于 file 參數，一個從請求的 querystring 獲得，一個似乎從 POST 的資料 body 裡獲得——那麼暫且認為 body 裡的就是檔案内容，則可以構造得到資料包為：
送出後傳回 200 狀态碼，但是沒有傳回路徑。難道是了解錯誤了？氣氛一下子變得有點尴尬起來了。。。
不過好在，這種尴尬沒持續多久，我又突然想起之前那個雞肋的目錄周遊。難道。。。？
于是懷着死馬當活馬醫的資訊再看一眼 upload 目錄發現：
Bingo ！
原來請求中的 param 的意義是指定儲存的目錄。那麼，自然而然地最後的 shell 通路位址是：http://xxxxx/upload/test/test.jsp ：
0x03 功敗垂成
至此，一個未授權的任意檔案上傳漏洞算是挖掘完成了。然而，正當我準備放棄喝茶，打算打包送出 cnvd 混個原創證書時卻尴尬地發現：
啊這、影響也太小了吧。。連 10 個網際網路案例都湊不齊。。
還是送出事件吧、要臉。。。。
0x04 總結
- 要會搞 web ，但不能局限于隻會搞 web ，因為 web 的突破口也有可能在其他地方。
- 滲透什麼的還是要膽大心細，并且再雞肋的漏洞也不能輕視，畢竟連一張廁紙、一條内褲都會又它自己的作用的。
- 下次挖通用前先查下産品使用率。。。
相關實驗：FCKeditor 2.4.3檔案上傳漏洞（複制連結體驗吧）
https://www.hetianlab.com/expc.do?ec=ECIDc23d-a989-4084-a5a0-5816b120e02e&pk_campaign=weixin-wemedia#stu
FCKeditor是一款開放源碼的文本編輯器，其2.4.3版本upload.php檔案使用黑名單進行檔案校驗，通過實驗學習如何繞過黑名單檢測，上傳惡意檔案。