记一次对某企业的渗透测试实战
作者：Vulkey_Chen
前言
本文總結一下漫長的滲透測試過程，想盡了各種方法，終于找到了突破口。so沒有絕對的安全，所謂的安全性其實都是相對的～
信息踩點
在這里其實沒辦法去做一些有價值的收集，只能踩點，踩坑。
信息難點：
傳輸加密：
要做滲透的目標是一個APP，根據抓到的請求包發現這個APP是經過某產品加固過的，所以HTTP的POST請求正文部分(Data)是神奇的密文～
分析難點
分析：
- 信息踩點其實也是解決難點的過程，在這里我們嘗試對APP進行逆向，發現并沒有什么東西，因為被加固了。
- 對APP進行功能的整理，逐個功能點進行抓包分析：
- 請求正文(data)雖然是密文，但是請求的URI還是真正按照對應的功能去請求的（參考URI的命名和功能的相對應性）
建立設想(A)：
在這里請教了師傅，說可能GET請求參數并沒有經過加密，而后臺很有可能是這樣寫的：
<?php $mstsec = $_REQUEST['vulkey'];//注意這里使用的是$_REQUEST 默認情況下包含了 $_GET，$_POST 和 $_COOKIE 的數組。 ?>- 一點即通，首先我可以去測試是否是真的這樣的后端處理接收。
- 為了滿足第一步的驗證，我需要想辦法找到一個GET請求的包并且有帶有GET參數，這樣我才能判斷規則，不然就是大海撈針。
有價值的東西
其實對APP做滲透測試，大部分情況下還是對網站做滲透測試。
所以在這里抓包獲取到的HOST，直接對其進行了前期的常規信息刺探（端口、目錄、指紋…）
中間件：Tomcat
目錄開放：/fileUpload/
端口開放：8001 1444
APP三個功能點：個人用戶、資金管理、生活欄目
滲透開端
一開始粗略的對整個APP進行抓包，然后做一些簡單的測試，發現并沒有那種明面上的漏洞（SQL注入、XSS等等…），但是獲取了這幾條URI：
不小心日偏
仔細的對每個功能點進行測試的時候，抓到了一些”逃出加固命運”的明文報文。
- 發現了S2-005這個歷史悠久的Struts2框架遠程代碼執行問題：
執行了whoami：
- 發現了SQL注入，這里需要做一些簡單的繞過(e.g.?AandND 1 like 1)：
然而沒看清楚，一下次給日錯地方了…很尷尬。
關聯分析
日偏后我分析了一下兩者的特征，發現應該出自同一個程序員之手，并且這個程序員很喜歡使用駝峰命名法…
驗證設想(A)
在這里我嘗試根據每個URI功能點生成GET請求參數的dict：
-
/userCenter/getUser?[獲取用戶信息URI POST]
dict: [uId, userId, uName, userName ...]
-
/userCenter/showQRcode?[獲取二維碼圖片 POST]
dict: [uId, userId, uName, userName, imagePath, filePath, codePath, fileName ...]
生成請求：
GET /userCenter/getUser?uId=10001 GET /userCenter/getUser?userId=10001 GET /userCenter/getUser?uName=test001 GET /userCenter/getUser?userName=test001 ... GET /userCenter/showQRcode?uId=10001 GET /userCenter/showQRcode?userId=10001 GET /userCenter/showQRcode?uName=test001 GET /userCenter/showQRcode?userName=test001 GET /userCenter/showQRcode?imagePath=../../index.do GET /userCenter/showQRcode?filePath=../../index.do GET /userCenter/showQRcode?codePath=../../index.do GET /userCenter/showQRcode?fileName=../../index.do ...結論
現實殘酷，打敗了設想。
絕處逢生
就在想放棄的時候，決定打算”垂死掙扎”一下，重新開始”審視”了各個功能模塊，眼光又轉到了這個二維碼地方。（因為二維碼的”皮相”，所以很多人都會忽略它）
這里我去解析了二維碼的地址：
失算…失算…，當去訪問這個地址的時候，響應報文中會多出這樣的頭：
... Set-Cookie: USESSIONPID=xxx; ...jpg content這時候我就知道是時候修改uId了，然而修改了沒用，根據多年的經驗（吹牛）我認為是uSign參數起了作用，這時候對uSign進行刪除發現不行，會提示uSign參數不存在，當我置空這個參數，發現居然成功了又返回了用戶的Cookie憑證…好吧，說明這里有一個邏輯問題…
到這下去就很簡單了，獲取管理員權限有上傳點，測試使用jhtml的后綴可以直接繞過上傳，但是上傳上去之后，直接訪問就給你download下來了（很多次遇到這種問題…）
好吧，管理員也沒啥能危害到服務器的東西了…不過回過頭再來看看，二維碼這個點還沒啃完呢，fileName這個參數還沒去測試，fuzzdb了解一下，先懟lfi的字典進去跑（有個坑這里一定要填寫完整[uId, uSign]），然后再進行Fuzz：
從intruder模塊(BurpSuite)的測試結果發現這里是可以讀取文件的，并且判斷這個web服務是root權限運行的因為我修改fileName參數的值為../../../etc/shadow時我直接可以獲取到文件的內容，從而獲取root賬號權限的密碼：
(解密不了)，怎么通過這個本地文件讀取漏洞拿到shell？我的思路是通過讀取tomcat的密碼配置文件然后進入tomcat的Web管理部署war包進行getwebshell，但是這里做了一圈的目錄猜解，死活沒找到tomcat的應用目錄…
讀取/root/.bash_history啊(這個文件是記錄root用戶輸入過的命令-老師傅提醒到)，突然間我茅塞頓開，是啊，一般運維人員會通過命令行進行管理，那么肯定會有目錄出現啊。
我修改fileName參數的值為../../../root/.bash_history，搜索下關鍵詞tomcat就發現了：
成功的發現了root用戶的命令歷史并且找到了Tomcat的應用安裝路徑，那么我只需要修改fileName的參數值為../../../../home/apache-tomcat-7.0.67/conf/tomcat-users.xml，直接就可以讀取到Tomcat的管理員賬號權限，從而直接通過外部訪問的形式進入Tomcat的管理界面進行控制。
登錄進來之后直接到WAR file to deploy功能點，進行war包的部署（在這里使用壓縮的方式將網站后門壓縮成zip格式然后修改后綴名.zip為.war即可），點擊Browser選擇war包然后點擊Deploy：
這里部署上去之后回到Applications功能點，可以看到部署的情況，點擊你的命名鏈接然后加上你壓縮的文件名（這里我的是 /vulkey/vulkey.jsp）使用Webshell管理工具進行管理，看見了我久違的界面，久違的root權限：
總結
因為后滲透可能會影響正常業務的運行，所以沒有繼續進行下去，很遺憾，希望下次有機會。
END:
送給大家一句話：心細則挖天下。
有問題大家可以留言哦，也歡迎大家到春秋論壇中來耍一耍??>>>點擊跳轉
總結
以上是生活随笔為你收集整理的记一次对某企业的渗透测试实战的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： es6新语法Object.assign(
- 下一篇： js jquery 函数回调