前言：
本篇文章是關於一次滲透測試中意外getshell的記錄，屬於ueditor v1.3.x 的aspx語言的非網上流傳的getshell方式。由於當時在網上搜索並未發現該種getshell方法，故分享給各位。
經過：
起因是針對某客戶網站進行滲透測試時，發現了一個ueditor編輯器路徑，並且網站是aspx，經驗豐富的滲透測試人員應該都已經想到網上廣為流傳的v1.4.3的那個遠程文件加載繞過導致的getshell方式。起初，我也是第一反應去進行該嘗試，但是網站回饋對應漏洞url404。在測試結束其他功能點后，再回過來看這個漏洞，我產生一個疑問，據我說知，ueditor是個由唯一入口文件\ueditor\net\controller.ashx 進行請求分發。如果開發知識單純得刪除了漏洞文件，必然影響網站的正常使用。起於該思慮，我下載了v1.3.6版本的net源碼，進行查看。
確認后了解，ueditor在1.4.x版本對整體設計架構進行改版，在v1.3.x,還是離散的功能文件存在的，上傳功能在\ueditor3\net\fileUp.ashx。代碼如下：
本意是對.net進行代碼審計，發現是否存在安全漏洞（雖然通過搜索引擎並未找到這種信息），但是有意思的是在我審計出來之前，先前開啟的burp的后綴fuzz已經有所發現。
框架使用的是白名單，並重命名，但是代碼層面存在兩點不足。
第一點是獲取后綴的函數是自定義的，並且存在邏輯問題。這部分代碼存在於\ueditor3\net\Uploader.cs:190
簡單來說，該函數就是以“.”為分割符，得到一個文件名信息的字符型數組，並獲取數組最后一個值，在前面添加‘.’后作為后綴返回。這里存在一個問題，如果所傳的字符不存在點字符，文件名以點分割獲取的數組只有一個值也是最后一個值，如，‘pdf’。該函數最后返回的值將是‘.pdf’。從而繞過白名單的檢查。
另一個問題就是文件名的生成過程，文件名是隨機生成的，但是隨機生成的決定參數是前端fileNameFormat傳入，格式是{filename}{rand:6}，最簡單辦法就是直接將該參數改為字符串，不會被正則匹配，直接拼接入文件名。同時此時獲取后綴的函數使用asp.net自帶的獲取后綴的方法Path.GetExtension(filename)，（這里只想說不知道開發是怎么想的），該函數獲取pdf中后綴的值為空。所以最后保存的文件名只由format決定。
這里完成了對1.3.6版本的分析，同時我也搭建了jsp、php本部的和v1.4.3的ueditor對應的三種語言的靶場，經查看，這幾種均使用語言自帶的獲取后綴的函數。所以該利用方法也只能在v1.3.x的aspx環境下復現。
總結
v1.3.x的市場覆蓋率確實較1.4.3低了很多，希望能幫碰到該環境的老哥們多拿一個shell吧！如有，錯誤和不足之處，望多多斧正。