getshell滲透測試

隨著攻防演練愈演愈烈，弱小的我也不得不加入攻防大軍的隊伍里，而本篇文章就記錄了某次攻防演練中的getshell歷程。在這次攻防演練中，初步利用工具批量打點無果，作為團隊里卑微的撕口子工具人，只能選擇一個站一個站硬啃。

1 開始

又是熟悉的“開局一個后臺”系列，初期重點選擇沒有驗證碼機制的后臺去進行爆破：

這里目錄與賬號密碼同時進行爆破，然而不出意外，沒有任何結果：

既然爆破無果，只能再試試其他的思路。

一般URI中帶#的js多為webpack模塊打包。于是決定再次從前臺webpack打包的js接口入手：

利用瀏覽器功能美化js文件，通過搜索path關鍵字，查找后臺路由：

通過構造路徑進入后臺，發現大部分接口存在二次驗證。直接跳轉至登錄頁，對path路徑進行多次嘗試，找到個人頭像上傳點。

測試直接上傳jpg成功后，抓包嘗試修改后綴上傳webshell。但發現服務端直接對上傳的文件進行了重命名，此條線索終止。

隨后，找到導入excel處嘗試XXE：

下載模板，解壓后修改其中xml文件的內容，加入payload：

上傳后發現所添加的ceye平臺出現了請求：

其中有http請求,說明可以下載文件：

修改payload為訪問外部實體的語句：

在vps上預先放置外部實體：

開啟http服務等待下載：

之后上傳文件，會觸發服務器請求vps下載dtd外部實體的命令，進而讀取內容。另外開啟ftp服務以實現文件內容外帶，嘗試讀取/etc/passwd中的內容。

這里直接在網上尋找的腳本：

“https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb”

嘗試讀取ssh key，讀取成功：

“/root/.ssh/id_rsa.pub”

對主機進行端口探測，發現22端口處于filtered狀態，嘗試連接發現超時，考慮到時間成本，暫時放棄這條路線。

最后在個人中心處找到一個可下載的APP：

打開app發現需要登錄，且抓包發現與Web端登錄接口一致，放棄嘗試登錄繞過，直接反編譯apk，找到主界面的activity：

通過adb 的am指令繞過登錄界面，到達MainActivity（Android端一些APP手勢密碼繞過也可以利用此方法步驟，直接跳轉到設置手勢密碼的Activity界面，通過重新設置手勢密碼來進行繞過，但是同樣需要通過AndroidManifest.xml來查找相應的Activity名稱）。

“am start ｛包(package)名｝/｛包名｝.{活動(activity)名稱}”

到達主界面后發現提示登錄錯誤，仍然存在二次驗證：

仔細尋找功能點。這里很累，因為如果請求沒有身份認證通過，便會直接退回登錄界面，需要一直利用am指令進行主頁跳轉：

在訂單流程處找到一處上傳附件的地方，發現其對后綴名進行了白名單校驗，放棄。

最后發現app只有在網盤功能處，上傳時不需要cookie認證，這里第一次進行上傳時uri路徑存在null參數，懷疑是用來獲取用戶昵稱在服務端創建文件夾。

將null修改為admin，雖然再次成功上傳，但是沒有直接返回文件路徑，即使找到路徑也很有可能是上傳到靜態目錄，無法對腳本文件進行解析。

雖然網盤很大概率是靜態目錄，但撕口子的迫切感讓我不得不把握住每一次可能的機會，遂開始嘗試查找路徑。

在此APP下，要想查找上傳路徑有兩種方法，一種是通過網盤在下載文件時查看是否會有文件路徑，第二種就是根據上傳接口去構造猜測文件路徑。

當打開網盤界面時，發現在網盤加載文件列表時需要用戶會話認證，沒有即為空。

白茫茫的背景圖，讓本不富裕的我更加雪上加霜。

只能寄希望于最后一處更加渺茫的方法：猜測路徑。

手工對URI逐級進行拆分：

結果拆到第二步，驚喜就出現了，沒有提示404，證明文件存在：

好家伙，我直接好家伙，這居然還是system權限，花光了我一年的運氣：

shell已到手，打點工具人也該撤退了。

2 總結

本文先從Web端入手進行滲透，在webpack模式下對后臺查找未授權訪問點，如上傳跟XXE測試，測試無果后在后臺發現apk安裝包，轉向防護相對薄弱的Android移動端進行滲透最終getshell。

因為初始目標明確，就是為了拿到webshell打開口子，所以進行滲透時都是奔著可以getshell的方式進行重點測試。