巡檢查殺
首先，我明白自己要做的不是找到這個上傳的位置是哪里出現(xiàn)的，我應該登上服務器進行webshel查殺，進行巡檢，找找看是否被別人入侵了，是否存在后門等等情況。雖然報的是我們公司的ip地址，萬一漏掉了幾個webshell，被別人上傳成功了沒檢測出來，那服務器被入侵了如何能行。所以我上去巡檢了服務器，上傳這個webshell查殺工具進行查殺，使用netstat -anpt和iptables -l判斷是否存在后門建立，查看是否有挖礦程序占用cpu，等等，此處不詳細展開了。萬幸的是服務器沒有被入侵，然后我開始著手思考這個上傳點是怎么回事。
文件上傳漏洞回顧
首先，我向這個和我對接的研發(fā)人員咨詢這個服務器對外開放的地址，要了地址之后打開發(fā)現(xiàn)，眼熟的不就是前不久自己測試的嗎？此時，我感覺有點懵逼，和開發(fā)人員對質(zhì)起這個整改信息，上次測試完發(fā)現(xiàn)這個上傳的地方是使用了白名單限制，只允許上傳jpeg、png等圖片格式了。當時我還發(fā)現(xiàn)，這個雖然上傳是做了白名單限制，也對上傳的文件名做了隨機數(shù)，還匹配了時間規(guī)則，但是我還是在返回包發(fā)現(xiàn)了這個上傳路徑和文件名，這個和他提議要進行整改，不然這個會造成這個文件包含漏洞，他和我反饋這個確實進行整改了，沒有返回這個路徑了。
文件后綴編碼繞過
討論回顧完上次整改的問題之后，理清了思路。然后我登錄了網(wǎng)站查看一下原因，因為網(wǎng)站只有一個上傳圖片的地方，我進行抓包嘗試，使用了repeater重放包之后，發(fā)現(xiàn)返回包確實沒有返回文件上傳路徑，然后我又嘗試了各種繞過，結果都不行。最后苦思冥想得不到結果，然后去問一下這個云平臺給他們提供的這個告警是什么原因。看了云平臺反饋的結果里面查殺到有圖片碼，這個問題不大，上傳文件沒有執(zhí)行權限，而且沒有返回文件路徑，還對文件名做了隨機更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。
當我仔細云平臺提供的發(fā)現(xiàn)webshel數(shù)據(jù)的時候，我細心的觀察到了文件名使用了base64編碼，這個我很疑惑，都做了隨機函數(shù)了還做編碼干嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關鍵，然后使用burpsuite的decoder模塊，將文件名“1.jsp”做了base64編碼成“MS5Kc1A=”，然后發(fā)送成功反饋狀態(tài)碼200，再不是這個上傳失敗反饋500狀態(tài)碼報錯了。
所以，這個問題所在是，在整改過程中研發(fā)人員對這個文件名使用了base64編碼，導致文件名在存儲過程中會使用base64解碼，而我上傳文件的時候?qū)⑦@個后綴名.jsp也做了這個base64編碼，在存儲過程中.jsp也被成功解碼，研發(fā)沒有對解碼之后進行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經(jīng)做了隨機數(shù)更改了文件名了，再做編碼有點畫蛇添足了，這就是為啥程序bug改一個引發(fā)更多的bug原因。
