【实战】某博彩资讯站的开放端口与未授权Redis

一、故事背景

这次对某博彩资讯站进行资产测绘与渗透。目标系统提供博彩资讯、赛事数据与投注入口的综合站点，前后端分离架构。客户希望了解自己服务器的暴露面。我在拿到授权后，先进行了端口扫描，然后针对开放的危险服务进行测试。很多安全事件都源于数据库、缓存等服务直接暴露在公网且未设密码。

二、信息收集

信息收集阶段，我用 nmap 对目标 IP 203.0.113.20 进行了全端口扫描，命令为 nmap -sT -p- 203.0.113.20。扫描结果显示，除了常规的 80、443 端口外，6379（Redis）、27017（MongoDB）端口也直接对外开放。这是一个非常危险的信号，因为这些服务默认没有密码保护。

三、漏洞发现

我先测试 Redis。用 redis-cli -h 203.0.113.20 直接连接，发现无需密码即可连接，且可以执行 info 命令查看服务器信息。进一步测试发现，Redis 是以 root 身份运行的，这意味着一旦利用成功，就能直接获取 root 权限。我继续测试了 MongoDB，发现同样未设密码，可以直接访问数据库内容。

四、漏洞利用

针对 Redis 未授权，我构造了写计划任务的攻击。利用 Redis 的 CONFIG SET 命令，将持久化目录设置为 /var/spool/cron，文件名设置为 root，然后写入包含反弹 shell 的计划任务内容，最后执行 save 命令持久化。payload 的关键是把恶意命令通过 Redis 的 set 命令写入，格式为 set 1 "反弹shell命令"。

五、权限获取

计划任务写入后，等待定时执行。我在 VPS 上提前用 nc 监听 4444 端口。约一分钟后，成功收到来自目标服务器的反弹连接，且是 root 权限（因为 Redis 以 root 运行）。至此，我完全控制了这台服务器。我随后检查了 MongoDB 中的数据，确认了数据泄露风险。

六、复盘总结

这次渗透的教训非常直接：数据库和缓存服务绝不能裸奔在公网上。修复建议：第一，Redis、MongoDB 等服务必须绑定 127.0.0.1，禁止公网访问；第二，所有数据库服务必须设置强密码；第三，通过防火墙限制端口访问，只对必要的来源开放；第四，定期进行端口扫描，发现新暴露的服务及时处理。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。