跳到主要内容

某社交平台SSRF到GET SHELL

SSRF 漏洞能升级为 RCE 的关键在于内网的隐式信任关系。 这个案例中，Redis 的匿名访问和可写的 cron 文件，是从 SSRF 到 GetShell 的两个关键跳板。外网的请求伪造漏洞之所以能最终完成服务器接管，是因为内网服务默认被当作可信环境，完全没有独立的认证防线。

1 找切入点​

参数中携带 URL 是 SSRF 的经典信号。 在支付回调接口 http://zhifu.game.weibo.com/topay.php 的 payaction 参数中发现了 URL 类型的值。后端在处理这类参数时，若会主动向该 URL 发起请求，就构成了服务端请求伪造的条件。通过将参数值替换为自控服务器地址并观察访问日志，即可验证漏洞是否存在。

回放请求后服务器收到了来自目标的访问，SSRF 得以确认。

那就开始利用吧！

2 第一滴血​

file:// 协议支持使 SSRF 直接变成任意文件读取。 将 payaction 参数值替换为 file:///etc/crontab，服务端在发起请求时会直接读取本地文件并将内容返回。通过一个辅助重定向脚本，将 HTTP 请求跳转到任意协议地址，可以绕过部分协议限制，进一步扩展可读取的文件范围。

/etc/crontab 是获取服务器目录结构的快捷入口。 定时任务文件中记录了大量脚本的完整路径，借助这些路径可以进一步读取业务代码、配置文件和密钥：

读取/etc/passwd文件：

img

负载均衡的存在将单点漏洞扩展到整个服务器集群。 从 Response header 可以发现 zhifu.game.weibo.com 背后做了负载均衡，意味着这一任意文件读取漏洞影响的是后端所有实例，而非单台服务器。截至目前已达到集群级别的任意文件读取。

3 扩大战果​

读取代码配置

已知的历史信息泄露可以作为新漏洞的跳板。 结合此前发现的 rSync 匿名访问漏洞（该漏洞彼时已过去较长时间，但仍未彻底修复），可以获取 Web 目录的完整结构，再通过 SSRF 的文件读取能力逐一读取目标路径下的配置文件。

/data1/www/htdocs/game.weibo.com/

验证路径可读后，即可读取代码配置和密钥。

img

至此已经可以读取到代码配置、密钥等敏感信息，并可以拿这些信息进一步利用了。

4 再次扩大​

任意写文件、爆破FTP、SMTP…

gopher 协议是 SSRF 升级为写入能力的关键。 SSRF 除了支持 file:// 读取本地文件，还支持 gopher 协议，可以直接构造 Redis 协议报文并通过 SSRF 发送，等同于直接操作内网 Redis 服务。

内网匿名 Redis 是从 SSRF 到 GetShell 的第一个跳板。 利用 dict:// 协议对内网 IP 段进行扫描，通过超时时间差判断端口是否开放，最终在内网找到数台可以无认证访问的 Redis 服务。Redis 在无认证保护的情况下，允许任何能够建立连接的客户端执行任意命令，包括修改其数据持久化的目录和文件名。

  • 10.75.6.89
  • 10.75.6.90
  • 10.75.6.91

可写的 cron 文件是第二个跳板。 通过 SSRF 操控匿名 Redis，将一条反弹 shell 的命令写入 /var/spool/cron/root，并将 Redis 的持久化目录设置为 /var/spool/cron/、文件名设置为 root，执行 save 命令后 cron 文件即被覆盖。此次测试中 crond 服务未运行，反弹 shell 未成功触发。理论上只要 crond 运行，或者将内容写入 /etc/profile.d 等登录触发路径，即可在有人登录时完成 shell 反弹。

内网 Redis 不应以无认证方式运行。 Redis 设计之初假设运行在受信任的内网环境中，默认不启用认证。但当内网存在 SSRF 等间接访问路径时，这一假设就不再成立。对 Redis 启用 requirepass 认证并限制监听地址，是防止此类攻击链的基础防线。除 Redis 外，gopher 协议还可用于访问匿名 FTP、发送 SMTP 邮件、检测内网 ShellShock 等 Web 漏洞，内网服务的无认证暴露会在 SSRF 存在时产生连锁的攻击面。

5 影响范围​

这条攻击链将一个支付回调接口的参数漏洞升级为整个内网的访问权限。

  • 整个负载均衡集群的任意文件读取（配置、脚本、代码、密钥等）
  • 内网匿名 Redis 所在服务器的任意文件写入（可 GetShell）
  • 内部微博接口服务任意调用
  • 访问任意微博内网服务

6 渗透声明​

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

7 修复建议​

修复链条的入口是 SSRF，但根本问题在于内网服务的隐式信任。 修复 SSRF 是阻断这条攻击链的第一步，但即使 SSRF 被修复，内网匿名 Redis 的问题依然是独立的安全风险，需要分开处理：

  • 修复 SSRF，对 payaction 等 URL 参数进行严格的白名单或协议限制
  • 清理测试期间写入的文件（10.75 段的几台 Redis 服务器中的 /var/spool/cron/root）
  • 对所有内网 Redis 实例启用认证，并限制监听地址，禁止匿名访问
  • 对可能已泄露的密码、密钥进行轮换替换

漏洞已报告给CNCERT/乌云/补天或厂商且已修复完成，感谢厂商的重视及现金奖励。（此次测试为微博 SRC 活动参与，严重漏洞奖励 ￥5,000 现金和 2,000 积分。）

本章内容大纲