webshell被上傳溯源事件的示例分析

這篇文章將為大家詳細講解有關webshell被上傳溯源事件的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

巡檢查殺

首先，我明白自己要做的不是找到這個上傳的位置是哪里出現的，我應該登上服務器進行webshel查殺，進行巡檢，找找看是否被別人入侵了，是否存在后門等等情況。雖然報的是我們公司的ip地址，萬一漏掉了幾個webshell，被別人上傳成功了沒檢測出來，那服務器被入侵了如何能行。所以我上去巡檢了服務器，上傳這個webshell查殺工具進行查殺，使用netstat -anpt和iptables -L判斷是否存在后門建立，查看是否有挖礦程序占用CPU，等等，此處不詳細展開了。萬幸的是服務器沒有被入侵，然后我開始著手思考這個上傳點是怎么回事。

文件上傳漏洞回顧

首先，我向這個和我對接的研發人員咨詢這個服務器對外開放的地址，要了地址之后打開發現，眼熟的不就是前不久自己測試的嗎？此時，我感覺有點懵逼，和開發人員對質起這個整改信息，上次測試完發現這個上傳的地方是使用了白名單限制，只允許上傳jpeg、png等圖片格式了。當時我還發現，這個雖然上傳是做了白名單限制，也對上傳的文件名做了隨機數，還匹配了時間規則，但是我還是在返回包發現了這個上傳路徑和文件名，這個和他提議要進行整改，不然這個會造成這個文件包含漏洞，他和我反饋這個確實進行整改了，沒有返回這個路徑了。

文件后綴編碼繞過

討論回顧完上次整改的問題之后，理清了思路。然后我登錄了網站查看一下原因，因為網站只有一個上傳圖片的地方，我進行抓包嘗試，使用了repeater重放包之后，發現返回包確實沒有返回文件上傳路徑，然后我又嘗試了各種繞過，結果都不行。最后苦思冥想得不到結果，然后去問一下這個云平臺給他們提供的這個告警是什么原因。看了云平臺反饋的結果里面查殺到有圖片碼，這個問題不大，上傳文件沒有執行權限，而且沒有返回文件路徑，還對文件名做了隨機更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。

當我仔細云平臺提供的發現webshel數據的時候，我細心的觀察到了文件名使用了base64編碼，這個我很疑惑，都做了隨機函數了還做編碼干嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關鍵，然后使用burpsuite的decoder模塊，將文件名“1.jsp”做了base64編碼成“MS5Kc1A=”，然后發送成功反饋狀態碼200，再不是這個上傳失敗反饋500狀態碼報錯了。

所以，這個問題所在是，在整改過程中研發人員對這個文件名使用了base64編碼，導致文件名在存儲過程中會使用base64解碼，而我上傳文件的時候將這個后綴名.jsp也做了這個base64編碼，在存儲過程中.jsp也被成功解碼，研發沒有對解碼之后進行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經做了隨機數更改了文件名了，再做編碼有點畫蛇添足了，這就是為啥程序bug改一個引發更多的bug原因。

關于“webshell被上傳溯源事件的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。