對於滲透就是想盡了各種方法，找到了突破口。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：
/userCenter/getUser [獲取用戶信息URI POST]
/userCenter/pay/getSign?userSign= [獲取Sign POST]
/userCenter/life/showShop?pId= [獲取商品信息 GET]
/userCenter/showQRcode [獲取二維碼圖片 POST]
不小心日偏
仔細的對每個功能點進行測試的時候，抓到了一些”逃出加固命運”的明文報文。
發現了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:
送給大家一句話：技術不牛逼。思維是第一。大意失荊州，心細挖天下。
相關推薦
