微博某处漏洞导致多台服务器可GET SHELL

该漏洞报告给微博后,微博在第一时间修复了,并奖励了¥5,000现金和2000积分👍 ,赞下微博安全应急响应中心的处理速度。

0x01 切入点

流量镜像中抓到一处带url的请求

http://zhifu.game.weibo.com/topay.php

post请求,参数中pay action为域名,所以怀疑存在SSRF,回放请求进行验证

 通过我服务上nginx log可以发现有request过来,所以的确存在SSRF

那就开始扩大战果吧

0x02 服务器任意文件读取

SSRF支持file协议的,所以可以构造一个payaction=file:///etc/crontab

/etc/crontab内有许多脚本,随便挑一个 /etc/passwd  这台服务器上有web、db还有很多开发人员登陆过,不一一展示 并且这个zhifu.game.weibo.com这个domain是有做负载均衡的,可以看到后面的服务器有很多。 也就是说,已经上升到N台(取决负载服务器数量)服务器任意文件读取漏洞。

0x03 再一次扩大战果(读取代码配置)

如果只是读取一些没什么影响的文件,那还算不上高危。 找到Web目录,读取代码配置、密钥等。

Web目录还得从之前提交给新浪SRC来说,当时出现了一个Rsync匿名访问,泄露一些敏感文件。

其中就有Web目录配置的结构。(提醒下,那个漏洞已经过去很久,到现在还没彻底修复好,建议微博SRC仔细排查下) /data1/www/htdocs/game.weibo.com/

读个favicon.ico验证下 读个配置文件

0x04 再再一次扩大战果(任意写文件、爆破FTP、SMTP等)

上面的N台服务器任意敏感文件读取已经达到最高安全等级,但是没法写入文件,只能算是信息泄露 所以这一次决定扩大战果,任意文件写入,甚至获取GET SHELL

SSRF还支持gopher协议,通过这个协议我们可以构造出能直接操作Redis的请求
能操作Redis的话,能做的事情就多了,具体可以看下http://wufeifei.com/redis/

通过构造dict://10.n.n.n.n:6379/infol来探测内网可以匿名访问的Redis服务

通过随机挑选大B段、B段、C段的IP,通过设置请求的超时时间来判断是否存在

最终在10.17段找到几台可以利用的匿名Redis

10.75.6.89
10.75.6.90
10.75.6.91

构造请求用Redis写cron(/var/spool/cron/root),但是并未反弹回SHELL,猜测应该是这几台的crowd服务没有开启。

但理论上可以通过写/etc/profile.d,只要有人登陆这台服务器,就会反弹SHELL。(但考虑实现的成本,已经对你们系统有影响,所以只证明,不实践验证)

另外除了操作Redis写文件,gopher协议还能做更多事情,比如爆破或者访问匿名FTP,检测内网ShellShock等Web漏洞,此处不一一证明。

0x05 影响范围

  • N台(取决于负载服务器数量)服务器任意文件读取(各类配置、脚本、代码、密钥等)
  • N台(取决于内网可匿名访问的Redis数量)服务器任意文件写入(可GET SHELL)
  • 内部微博接口服务任意调用
  • 访问任意微博内网服务

0x06 渗透过程声明

  • 未留存任何此次渗透测试的数据(配置、密钥等)
  • 未连接任何此次渗透的DB
  • 未留存任何后门、木马
  • 所有敏感截图都会打码,避免CDN泄露
  • 本次渗透测试为实名测试,测试过程中使用的Cookie都为本人微博@吴止介
  • 本次渗透过程在漏洞修复前不会公开与传播

0x07 修复建议

  • 先修掉SSRF,修复方案见(http://wufeifei.com/ssrf/)
  • 删除渗透测试过程中写入的文件(10.75段的几台Redis服务器中/var/spool/cron/root)
  • 统一处理内部Redis匿名访问的问题
  • 保险起见,对可能涉及到泄露的密码、密钥等进行更改替换
  • 有任何问题或需要协助处理的请通过wufeifei@wufeifei.com联系