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