實戰｜記一次某系統的滲透測試

開端

前幾個月被授權進行某大型運營商的滲透，在過程中也是遇到了一些比較有意思的東西，特此記錄一波

最開始是通過一個webpack+未授權訪問的接口獲取了另一個系統的權限，根據獲取到的口令進行復用對其他資產進行登錄嘗試，發現了這樣一個系統

登錄進去之后是一個攝像頭的管理平臺，里面包含了各種各樣的功能，但經過一番簡單的嘗試，一些常見的漏洞如文件上傳、sql注入均不存在；這個時候我就又把這個后臺所有功能翻了一遍，發現這個后臺的備份還原功能可能存在問題

斗智斗勇

點擊手動備份之后，需要輸入登錄密碼和一個加密密碼，加密密碼是可以任意輸入的；確認之后，就會返回給你一個壓縮包，打開一看是這樣的一個結構

看到這個properties文件還是有點激動，當時還以為這里面可能會有數據庫密碼之類的東西，數據庫拿下了getshell的幾率不就大大增加了嗎（這個公網ip是開放了一個mysql服務的）；于是懷著激動忐忑的心情點擊解壓，但輸入了登錄密碼、加密密碼都不對，這個時候我就有點懵逼了，敢情你這個加密密碼就是個擺設？

懷著*了狗的心情，又去看了下這里的還原功能，發現就是備份的逆邏輯，在你上傳一個壓縮包之前同樣需要輸入加密密碼；于是猜測這里的加密密碼后端是做了一些處理的，單純的使用加密密碼無法解壓備份文件

這個時候，首要任務是找到后端對這個加密密碼的處理邏輯；首先我抓包看了下這里的包，發現這里的登錄密碼和加密密碼傳送到后端時是經過加密了的，于是我大膽猜測這里前端的加密可能和后端的一致；經過一天對前端 JS 的分析，總算是分析出了前端的加密邏輯，然而我還是低估了這個系統的開發人員，加密后的密碼依然不能解壓備份文件

PS：這個時候我真心覺得這系統是真TM安全啊

峰回路轉

沒辦法了，和小伙伴吐槽了一通，他建議我去官網找下產品手冊，也許手冊里有寫相關的內容呢；我只好抱著死馬當做活馬醫的心態去官網翻了一遍，手冊沒找到，倒是找到了一個修復補丁包

里面不但有后臺的部分代碼（class文件），還貼心的告訴了你補丁包的具體使用方法，比如安裝路徑等等。

真就離大譜，這種東西為啥會直接放出來。

直接代碼包解壓，導入idea，開審！

首先要找到備份相關邏輯，直接全局搜索對應的路由關鍵字，找到了后端對加密密碼的處理邏輯，用加密后的加密密碼去解壓備份文件，可惜的是備份文件中并沒有我想要的信息，只有這個后臺相關的一些數據庫數據，沒任何鳥用；沒辦法了，只有對這殘缺的代碼繼續審了，幸運的是，很快就從這個系統引入的依賴發現了突破口

這里引入的 ant.jar 包版本是有漏洞的，在它對壓縮包進行解壓時，沒有正確的對 ../ 進行處理，會導致目錄穿越的發生；由于之前補丁包中告訴了我們正確的web路徑，所以這里大概率是能getshell的

GETSHELL

首先我們構造一個形如這樣的壓縮包

opt里面即是該系統的具體web路徑+webshell文件，構造完之后還需要使用加密后的加密密碼對該壓縮包進行加密

PS：這一步其實坑挺多的，構造目錄穿越壓縮包的腳本很多，但基本沒有提供壓縮包加密功能；提供壓縮包加密軟件的又不能構造形如 ../ 的目錄（當時腦子卡了，后面才想到用linux的命令應該可以構造），最后是使用了某國產數字壓縮軟件成功進行了構造（國產YYDS）

將構造好的壓縮包通過備份還原功能上傳，成功getshell