盲猜包體對上傳漏洞的艱難利用過程
Part1 前言
大家好,上期分享了一個IIS短文件名猜解在實戰中拿權限的利用,本期將會分享一個特殊的上傳漏洞的利用案例。很多時候遇到一個存在漏洞的點,只要有一線希望,就不愿意輕言放棄。對一個網站進行測試前,掃描目錄和掃描敏感文件是經常使用的方法,有時候會掃描出上傳功能的后端頁面,這時候不知道包體是怎么構造的,也不知道上傳漏洞需要提交哪些參數,所以就需盲猜包體了。類似的案例我成功過好幾次,接下來詳細說一下具體方法及詳細過程。
Part2 技術研究過程
- 掃描目錄
首先,目標網站就是一個空白頁面,對于這種網站,只能對URL進行目錄掃描了,最后一層層掃目錄得到類似于如下URL地址(以下是虛擬機環境的截圖):
http://www.xxx.com/Temp/servlet/UploadFile,打開頁面如下:

做過Javaweb的朋友一眼就能看出這是Java站點的常見提示,通過URL的路由地址UploadFile猜測,這可能是一個上傳功能的后端頁面。由于沒有前端的用戶交互頁面,就無法得到具體需要提交哪些參數。接下來講講如何對這個功能頁面進行利用。
- 本地搭建環境
首先拿一個本地搭建的網站舉例說明一下,我們平常見到的可能存在上傳漏洞的頁面是如下所示的一個前端頁面:

查看瀏覽器源碼,可以得知,真正處理用戶上傳數據的URL實際上是以下這個地址:

直接瀏覽器打開,頁面如下,很多都是一個空白頁面:

上傳一個文件,使用burpsuite抓包,得到如下數據包,發現filepath和FileName是常見的用戶提交給上傳功能后端頁面去處理的參數。其中,filepath是Web應用保存上傳文件的地址,FileName是文件名稱。
接下來我就想了,可不可以盲猜一下上傳功能的包體呢?上傳功能的POST包體常用的參數就是那幾個。萬一猜對了,就可以直接上傳webshell了。
- 盲猜包體過程
于是使用burpsuite手工嘗試filename、FileName、fileName、name、Name、FilePath、filePath等參數名,不斷地構造上傳包體,不斷地進行變換構造,當構造出如下包體時,提示“文件上傳成功”,這同時也說明這是一個存在未授權訪問功能的上傳頁面。這個案例是好多年前的了,當時具體是哪幾個參數我也不記得了,大致與以下截圖類似。

當構造出如上圖包體時,該頁面提示“文件上傳成功!”。上述包體的那個name字段應該是沒起什么作用,但是不影響上傳功能的正常使用。

- 尋找Webshell路徑
接下來難點就來了,Web應用雖然提示“文件上傳成功”,但是沒給出文件上傳的路徑,那這個webshell傳到哪里去了呢?接下來又得猜解目錄及文件地址了。
假設掃描到了如下敏感目錄(以下虛擬機環境的截圖,項目圖就不放出來了),/images/、/files/顯得尤為重要。

于是打開網站訪問/images/test123.txt,/files/test123.txt等等,發現均提示404,頁面不存在,這就麻煩了。Webshell究竟傳到哪里去了呢?
- 按照研發人員的思維滲透
后來思路轉變了一下,既然是Java站點,而且目錄中又有一個/temp/目錄,程序員估計會以時間戳去重命名文件名做測試用。
于是打開IDE,找了一篇Java生成時間戳的文章,照著寫了幾行代碼,生成了一個時間戳:
如下圖所示,本地生成了一個時間戳:

由于本地操作時間與服務器文件落地的時間肯定不能完全一致,一定是有差別的,所以需要以當前時間戳為基準,前后取一定的時間差,生成一個幾萬行的字典,用burpsuite枚舉一下:

結果沒有那么簡單,發現均是404響應碼,沒有找到響應碼200的記錄,也就是說沒有找到webshell的地址。原因可能是時間戳不對,也可能是存放上傳文件的目錄沒有找到,也可能是服務器壓根就沒有以此時間戳命名的文件。后來重新理了一下思路,我本地先生成了一個時間戳字典,然后使用burpsuite發上傳數據包,再用burpsuite枚舉時間戳文件名,中間大概有個幾秒鐘甚至是10秒鐘的間隔,可別小看這個時間間隔,做個涵蓋這個時間間隔的字典,也得上百萬行、上千萬行字典了。
后續為了加快掃描速度,也為了減少服務器的壓力,我將GET請求轉換成了HEAD請求,然后經過幾百萬行字典的爆破,成功找到了webshell地址,最終getshell成功。
- 尋找準確時間戳的新思路
后續經過Magic_Zero的提醒,他給出了一個更好用的思路,可以先查看服務器返回的Date響應頭的時間,然后做成時間戳字典地址,這樣準確度更高。這個思路真的沒想到,感謝提供。

Part3 總結
1. 理解一個技術問題要理解它的實質。
2. 按照程序員、研發人員的思維去搞站,事半功倍。
3. 大批量掃目錄、掃文件時,記得把GET請求換為HEAD請求,有些網站可能不支持HEAD請求,需要提前手工判斷一下。