redis未授权访问漏洞复现

凌晨两点，授权我盯着终端里那条redis-cli -h 192.168.1.105的访问复现命令，回车后竟然直接蹦出了redis 3.2.1的漏洞版本号。没有密码提示，授权连个认证的访问复现姿势都没有。这台服务器是漏洞朋友公司测试环境里漏出来的，本来只是授权想验证一下安全报告上的条目，没想到三秒就进去了。访问复现

漏洞原理其实简单得让人发笑——Redis默认绑定在0.0.0.0:6379，漏洞而且配置文件中protected-mode如果没开，授权或者没设requirepass，访问复现那任何能连到6379端口的漏洞人都能直接操作数据。更可怕的授权是，Redis的访问复现CONFIG SET命令允许运行时修改配置，这意味着你可以动态开启dir和dbfilename，漏洞把恶意代码写到web目录或者计划任务目录里。

我复现的第一步是探测。用nmap扫了一圈，发现6379端口敞着，banner显示版本是3.x。老版本连protected-mode这个选项都没有，纯粹裸奔。接着用redis-cli直连，输入info命令，服务器老老实实吐出了所有运行信息——内存、连接数、持久化状态，甚至还有几个key的名字。这种信任感，就像把家门钥匙挂在门口脚垫下面，还贴了张纸条写着“欢迎光临”。

真正的高潮在写入webshell那一步。假设目标服务器上跑着nginx，web根目录在/var/www/html。我输入：

CONFIG SET dir /var/www/html CONFIG SET dbfilename shell.php SET payload "<?php @eval($_POST['cmd']);?>" SAVE

这几行命令执行完，服务器就把Redis的数据文件直接写成了PHP文件。虽然默认的RDB格式会在文件前面加一堆二进制垃圾，但只要在PHP代码前加个GIF89a之类的注释头，就能绕过文件头检查。我试了试访问http://192.168.1.105/shell.php，返回200，用蚁剑连上去，直接拿到了www-data权限。

另一种玩法是写计划任务。如果目标机器是Ubuntu或CentOS，可以写/var/spool/cron/root或者/etc/cron.d/目录。我曾在真实渗透测试中遇到过一台内网Redis，用SET命令写入反弹shell的cron任务，等了一分钟，shell就回来了。那种感觉挺魔幻——一个缓存数据库，居然变成了远程命令执行的跳板。

修复方案其实很粗暴。第一，绑内网IP，别暴露公网。第二，设置requirepass强密码。第三，把protected-mode yes打开。第四，最好用防火墙限制只有应用服务器能访问6379。但现实中很多运维为了图省事，redis.conf里全是注释掉的默认配置，装上就能用，结果就成了黑客的免费服务器。

复现完这个漏洞，我在测试机上执行了FLUSHALL清掉痕迹，然后删掉了写入的shell文件。但心里清楚，生产环境里这种漏洞远比想象中多。很多公司买了安全设备，却连最基本的基线检查都没做。Redis本身没错，错的是把它当成了不需要锁门的保险柜。