重生之我是赏金猎人(六)-强行多次FUZZ发现某厂商SSRF到redis密码喷洒批量反弹Shell
0x00 前言
最近BugBounty挖了不少,但大多数都是有手就行的漏洞,需要动脑子的实属罕见
而之前就遇到了一个非常好的案例,故作此文
0x01 对目录批量FUZZ,发现一处隐蔽接口
挖某大厂已经挖了快两个周了,期间因为公司业务比较繁忙,最近一直没挖。
但是一直在用ffuf挂着字典对厂商资产进行批量目录扫描,今天上服务器看了下扫描结果,就出货了
接口地址为:https://xxx.xxxx.com/xxxx/start
我们直接对其进行访问
发现该接口给我们提供了一些可以使用的接口链接
我们逐个测试拼接接口后,发现一个名为face_xxxx的接口有戏
0x02 FUZZ传参格式+参数
访问接口,提示Method Not Allow,405错误,那么很显然,我们得换POST传参
POST随便传个参过去,发现接口提示"Request error, content-type was unsupported"
很好,继续FUZZ content-type header(记得把payload_processing自动编码给关掉)
FUZZ出来application/json的content-type头可用,那么很简单了,构造JSON数据,继续FUZZ JSON数据参数
0x03 SSRF无脑到手
参数为image_url,稍有经验的朋友就可以借此判断出,很可能这个参数是加载远程图片的
直接进行SSRF测试
服务器收到了请求,经测试gopher,dict,http等常规协议都可以使用~
之前通过各种域名二级目录或根目录的spring泄露,下载heapdump,OQL调试出redis明文密码
收集了不少该厂商内网redis的ip和密码,也了解到该厂商的内网网段
尝试利用本处SSRF完全可以批量对内网Redis进行密码喷洒+反弹shell对边界进行突破
0x04 利用gopher协议对内网脆弱网段批量Redis密码喷洒反弹Shell
普及一个知识:与未授权直接访问的redis不同,加入密码认证的redis在命令行链接时会多一个-a参数指定密码
如图所示如果不传参密码,则无法执行任何redis指令
而加入密码认证后redis,在整个RESQ协议流量中表现如下
认证过程中会多一个Auth,因此不能使用dict协议完成一连串的密码认证+写计划任务攻击
写脚本来构造gopher数据,注意把这块Auth加上,后续常规操作写计划任务反弹SHELL
利用上面挖掘到的SSRF点,配合之前自己收集到的内网redis密码和脆弱网段
直接通过intruder批量跑内网的脆弱网段redis,进行密码喷洒,喷洒一但成功,则会写入计划任务
最终功夫不负有心人,在一个网段,弹回来了十几个Shell。。。
厂商的内网Redis主机还能出网,属实是内网安全做的稀烂了。
0x05 后言
这个洞是在去年平安夜挖到的~算是圣诞贺礼啦
师傅们如果有BugBounty交流,技术交流需求,欢迎加个联系方式 QQ/VX:5470066660 ~
评论56次
事实证明,经验还是十分重要的
fuzz还是得要有耐心
表哥牛逼
太强了师傅,fuzz真的太考验耐心了
大佬平常都挖那些厂商啊 那些厂商产出比比较高?也在尝试挖洞赚赏金
emmm,我的话一般挖国内商家比较高的。比如OPPO,还有几家互联网大厂的SRC,hackerone也会看
大佬平常都挖那些厂商啊 那些厂商产出比比较高?也在尝试挖洞赚赏金
可以分享一下字典吗
确实需要耐心才能玩转fuzz。
还是得接口访问的错误提示信息屏蔽掉 估计可以屏蔽90%的类似攻击
多谢分享,又在实战中多了思路
又对fuzz 有了新的认识
不得不说 重生xi列文章是真的好看呀
表哥强啊,不但思路够骚,操作也牛逼
Redis密码喷洒反弹Shell脚本很强
太秀了,还能这样玩?
佩服楼主的功底,太强了
卧槽 这个fuzz太牛了 这么多一个个干掉 抽丝剥茧
Fuzz太细,自己平时也好懒去弄,有耐心的人真的强。
师傅的字典是自己平常搜集的么,我Fuzz感觉就没Fuzz出什么有价值的东西,当然也可能是我太菜的,没能判断出有价值的东西
网上公开+自己根据实战经验整合 这样能做成比较好的效果
师傅的字典是自己平常搜集的么,我Fuzz感觉就没Fuzz出什么有价值的东西,当然也可能是我太菜的,没能判断出有价值的东西