標題:記一次對某客戶端的安全測試

taibeihacker

Moderator

0x00 起因​

此次接到的項目是對某客戶端進行安全測試。之前的工作內容除了偶爾測測App 之外,大部分的測試目標還是以B/S 架構的Web 為主,這是第一次對C/S 架構的客戶端進行測試,所以也是兩眼一抹黑,只能先按照測Web 的常規思路來了。

0x01 抓包​

首先查看目標客戶端是否存在代理配置功能(大多數沒有)
1049983-20220112165300525-811630463.png

可以看到只有個簡單的登錄功能,並無代理配置功能

Proxifier + BurpSuite​

查看BurpSuite 中配置的代理地址及端口
1049983-20220112165301160-1350397900.png

在Proxifier 中添加代理服務器(ip、port 為BurpSuite 中配置的代理地址及端口)
1049983-20220112165301716-1441305015.png

配置好後,進行檢查,測試與BurpSuite 的連通性(BurpSuite 中有流量即為成功連通)
1049983-20220112165302269-1798238801.png

在Proxifier 中添加代理規則
1049983-20220112165302895-1418935946.png

BurpSuite 成功攔截到客戶端的登錄請求
1049983-20220112165303584-270157212.png

0x02 数据包分析​

成功攔截到數據包之後,便打算對其進行分析,結果一看就絕望了,請求包跟響應包均被加密
1049983-20220112165304516-19916912.png
1049983-20220112165305262-348139652.png

尝试 Web 访问​

之前測App 時遇到過手機端流量被加密但PC 端未加密的情況,遂復制請求鏈接嘗試Web 訪問,並未獲取到有效信息
1049983-20220112165306029-925588883.png

由於該客戶端內相關功能的請求參數均以POST 方式傳輸,流量均被加密,所以暫時放棄,轉變思路打算從服務器入手

0x03 柳暗花明​

WebSphere對目標服務器進行端口掃描,發現開放的端口還挺多,9043、9060分別為WebSphere 默認的管理控制台安全端口、管理控制台端口
1049983-20220112165306551-244104662.png

默認登錄地址為/ibm/console,此處用默認的用戶標識admin 成功登錄
1049983-20220112165307024-536088840.png

一波三折​

更换 jsp 文件内容​

按理說成功進入WebSphere 管理控制台,拿到shell 只是順理成章的事情,但是事情遠沒有我想像中的那麼容易,首先使用之前打好的war 包進行上傳
1049983-20220112165307550-894715545.png

選擇war 包,填好上下文之後報錯
1049983-20220112165308151-1929645713.png

關於這個報錯,我上網搜索了好久最終匯總了幾種原因以及解決方案,分別是重啟WebSphere、war 包中包含的文件內容格式有誤、打war 包時所用的jdk 與目標WebSphere 的jdk 版本不一致、修改一些WebSphere 的配置文件。
將war 包中的jsp 文件內容修改為打印字符串(無害內容),重新打包後上傳,依舊報錯

更换 jdk 版本​

從前面抓取到的數據包中可知目標使用的jdk 版本為1.5.0_21,遂下載對應版本的jdk 使用jar 命令對無害jsp 文件打war 包後上傳,依舊報錯
1049983-20220112165309237-224143831.png
1049983-20220112165310203-1987621632.png

Myeclipse 构造 war 文件​

通過此前的多次嘗試均未解決這個報錯,於是卡在這個步驟上好久,最後通過查閱資料得知,WebSphere 6.x 版本默認支持的Web 應用是2.3(web.xml 配置的web-app_2_3.dtd),所以選擇使用Myeclipse 來生成war 文件
Myeclipse 新建web 項目將jsp 文件放至WebRoot 目錄下導出項目為war 文件
1049983-20220112165311490-623774130.png
1049983-20220112165312230-288898744.png

生成的war 文件目錄結構如下
1049983-20220112165312720-1805505908.png

選擇生成的war 文件並填寫上下文進行上傳
1049983-20220112165313199-902598587.png

步驟1-4 無需操作,點擊下一步步驟5 點擊完成後,記得選擇保存到主配置
1049983-20220112165313745-1109284724.png

安裝完成後應用程序狀態為已停止,點擊啟動即可成功啟動
1049983-20220112165314266-401746263.png
1049983-20220112165314657-1887140362.png
1049983-20220112165315061-470388678.png

0x04 总结​

jsp 文件需使用Godzilla 生成的webshell,剛開始使用Behinder v3.11生成的馬,雖然可以上傳成功,但是會提示頁面存在,無法獲取密鑰,猜測可能與目標jdk 版本過低有關,具體原因不明。
1.先分別設置bp和proxififter的代理端口為127.0.0.1 8081 ,並將目標客服端的軟件添加到proxififter中,並對其抓包
,發現目標傳輸的post數據包已進行加密,顯示的JDK為1.5.0-21。
2.對客服端軟件的IP進行端口掃描,發現開放了9043、9060以及WebSphere 服務端口
3.訪問WebSphere後台(/ibm/console),輸入用戶名admin/admin可進入系統,且版本為6.x
4.這里通過Godzilla 的生成的一句話木馬,製作成war包(自應用程序-企業應用程序-安裝-新應用程序的路徑-本地文件系統-選擇WAr包)
5.上傳WAR包顯示錯誤,出現錯誤的原因如下:
需要重啟WebSphere
war 包中包含的文件內容格式有誤需要修改
打war 包時所用的jdk 與目標WebSphere 的jdk 版本不一致
修改一些WebSphere 的配置文件
5.這裡在本地安裝jdk1.5版本,然後通過jar命令將war包進行修改,並上傳waf包,發現還是不能運行
jar -cvf time.war time.jsp
6.WebSphere 6.x 版本默認支持的Web 應用是2.3(web.xml 配置的web-app_2_3.dtd),所以選擇使用Myeclipse 來生成war 文件:
new --web project-project name(getshell)-將Godzilla生成一句話拖入到getshell項目下。然後export導出--
java EE --war file--導出getshell.war包
7.getshell.war包可直接上傳
(自應用程序-企業應用程序-安裝-新應用程序的路徑-本地文件系統-選擇WAr包,以及上下文根(test目錄))
8.然後保存配置,並啟動。
最終訪問:
原文鏈接:https://xz.aliyun.com/t/10253
 
返回
上方