0x00 前言

如有技術(shù)交流或滲透測試/代碼審計/SRC漏洞挖掘/紅隊?向綜合培訓 或 紅藍對抗評估/安全產(chǎn)品研發(fā)/安全服務(wù)需求的朋友?

歡迎聯(lián)系QQ/VX 547006660?

https://github.com/J0o1ey/BountyHunterInChina?

重?之我是賞?獵?系列，歡迎?家點個star

2000人網(wǎng)絡(luò)安全交流群，歡迎大佬們來玩
群號820783253

最近BugBounty挖了不少，但大多數(shù)都是有手就行的漏洞，需要動腦子的實屬罕見

而今天就遇到了一個非常好的案例，故作此文

0x01 對目錄批量FUZZ，發(fā)現(xiàn)一處隱蔽接口

挖某大廠已經(jīng)挖了快兩個周了，期間因為公司業(yè)務(wù)比較繁忙，最近一直沒挖。

但是一直在用ffuf掛著字典對廠商資產(chǎn)進行批量目錄掃描，今天上服務(wù)器看了下掃描結(jié)果，就出貨了

接口地址為：https://xxx.xxxx.com/xxxx/start

我們直接對其進行訪問

發(fā)現(xiàn)該接口給我們提供了一些可以使用的接口鏈接

我們逐個測試拼接接口后，發(fā)現(xiàn)一個名為face_xxxx的接口有戲

0x02 FUZZ傳參格式+參數(shù)

訪問接口，提示Method Not Allow，405錯誤，那么很顯然，我們得換POST傳參

POST隨便傳個參過去，發(fā)現(xiàn)接口提示"Request error, content-type was unsupported"

很好，繼續(xù)FUZZ content-type header(記得把payload_processing自動編碼給關(guān)掉)

FUZZ出來application/json的content-type頭可用，那么很簡單了，構(gòu)造JSON數(shù)據(jù)，繼續(xù)FUZZ JSON數(shù)據(jù)參數(shù)

0x03 SSRF無腦到手

參數(shù)為image_url，稍有經(jīng)驗的朋友就可以借此判斷出，很可能這個參數(shù)是加載遠程圖片的

直接進行SSRF測試

服務(wù)器收到了請求，經(jīng)測試gopher，dict，http等常規(guī)協(xié)議都可以使用~

之前收集了不少該廠商內(nèi)網(wǎng)redis的ip和密碼，也了解到該廠商的內(nèi)網(wǎng)網(wǎng)段

嘗試利用本處SSRF完全可以批量對內(nèi)網(wǎng)Redis進行密碼噴灑+反彈shell對邊界進行突破

0x04 利用gopher協(xié)議對內(nèi)網(wǎng)脆弱網(wǎng)段批量Redis密碼噴灑反彈Shell

普及一個知識：與未授權(quán)直接訪問的redis不同，加入密碼認證的redis在命令行鏈接時會多一個-a參數(shù)指定密碼

如圖所示如果不傳參密碼，則無法執(zhí)行任何redis指令

而加入密碼認證后redis，在整個RESQ協(xié)議流量中表現(xiàn)如下

認證過程中會多一個Auth

寫腳本來構(gòu)造gopher數(shù)據(jù)，注意把這塊Auth加上,后續(xù)常規(guī)操作寫計劃任務(wù)反彈SHELL

利用上面挖掘到的SSRF點，配合之前自己收集到的內(nèi)網(wǎng)redis密碼和脆弱網(wǎng)段

直接通過intruder批量跑內(nèi)網(wǎng)的脆弱網(wǎng)段redis，進行密碼噴灑，噴灑一但成功，則會寫入計劃任務(wù)

最終功夫不負有心人，在一個網(wǎng)段，彈回來了十幾個Shell。。。

廠商的內(nèi)網(wǎng)Redis主機還能出網(wǎng)，屬實是內(nèi)網(wǎng)安全做的稀爛了。

0x04 后言

這個洞是在平安夜挖到的~算是圣誕賀禮啦