题目
题目1::你是公司的一名安全运营工程师,今日接到外部监管部门通报,你公司网络出口存在请求挖矿域名的行为。需要立即整改。经过与网络组配合,你们定位到了请求挖矿域名的内网IP是10.221.36.21。查询CMDB后得知该IP运行了公司的工时系统。(虚拟机账号密码为:root/IncidentResponsePasswd)挖 矿程序所在路径是?
题目2:挖矿程序连接的矿池域名是?
题目3:攻击者入侵服务器的利用方法是?
题目4:攻击者的IP是?
题目5:攻击者发起攻击时使用的User-Agent是?
题目6-7:攻击者使用了2种权限维持授权,相关的配置文件路径是?
Writeup
首先,我们查看该系统为Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-213-generic x86_64)。对于这一类的系统我们先查看开开放端口 使用SS命令
[email protected]:~# ss -lntp | gawk -F: ‘{ print $2 $4 }’
53 0.0.0.0((“systemd-resolve”,pid=1090,fd=13))
22 0.0.0.0((“sshd”,pid=1564,fd=3))
6010 0.0.0.0((“sshd”,pid=2048,fd=9))
3306 0.0.0.0((“mysqld”,pid=1540,fd=25))
80 0.0.0.0((“nginx”,pid=1423,fd=6),(“nginx”,pid=1422,fd=6))
22 [
6010 [
127.0.0.1]
80 [
发现存在ssh,nginx ,mysql等进程,我们查看进程使用ps-ef命令发现一个异常进程
/etc/redis/redis-server -c /etc/redis/redis.conf
redis的默认端口是6379,我们查看端口的时候发现没有该服务,我们进入路径看一下这个redis是一个什么东西?
我们进入redis路径发现存在4个文件分别是
redis.conf redis-server redis.sh SHA256SUMS
其中conf配置文件,server执行程序。sh启动脚本,sha校验文件
发现conf文件存在如下配置
“pools”: [
{
“algo”: null,
“coin”: null,
“url”: “donate.v2.xmrig.com:3333”,
“user”: “YOUR_WALLET_ADDRESS”,
“pass”: “x”,
“rig-id”: null,
“nicehash”: false,
“keepalive”: false,
“enabled”: true,
“tls”: false,
“tls-fingerprint”: null,
“daemon”: false,
“socks5”: null,
“self-select”: null,
“submit-to-origin”: false
}
其中url为矿池地址,故redis是一个伪造的挖矿程序
题目1的flag为/etc/redis/redis-server
题目2的flag为donate.v2.xmrig.com
发现存在nginx,我们查看一下nginx的日志
查看nginx安装目录使用whereis nginx 查看安装路径
[email protected]:/etc/redis# whereis nginx
nginx: /usr/sbin/nginx /usr/lib/nginx /etc/nginx /usr/share/nginx /usr/share/man/man8/nginx.8.gz
一般这种安装的他的日志位置在/var/log/nginx目录下
cat 一下文件access.log
发现大量的同一IP的访问记录,81.70.166.3,以及不同的User-Agent,经过过滤尝试发现
User-Agent为Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)为攻击者的User-Agent
题目4的flag为81.70.166.3
题目5的flag为Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
在查看进程的时候发现存在java -jar程序运行,查看所在路径发现一个名为nohup.log的日志文件,一般该文件为jar包运行的日志
查看日志发现存在
2023-07-23 16:39:55.238 WARN 2071 — [.1-8080-exec-16] o.a.shiro.mgt.DefaultSecurityManager : Delegate RememberMeManager instance of type [org.apache.shiro.web.mgt.CookieRememberMeManager] threw an exception during getRememberedPrincipals().
猜测是shiro的漏洞导致 经过测试发现为shiro的Deserialization
关于shiro的Deserialization 这里不在过多赘述,可以参考lightless的blog
题目3的flag为 shirodeserialization
在root路径下发现.ssh文件发现存在authorized_keys,且文件不为空,故猜测这里为权限维持手段之一
为了进一步查找权限维持手段,使用systemctl list-units –type=service 对服务器运行的服务进行查看
发现一个名为redis.sever的服务
在前面我们发现redis为挖矿程序,我们进一步查看状态,执行 systemctl status redis.service
发现内容如下:
● redis.service – Redis
Loaded: loaded (/lib/systemd/system/redis.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-08-30 04:09:05 CST; 1h 46min ago
Main PID: 1304 (redis-server)
Tasks: 6 (limit: 2312)
CGroup: /system.slice/redis.service
└─1304 /etc/redis/redis-server -c /etc/redis/redis.conf
发现该服务当前状态为runing状态,且执行进程为/etc/redis/redis-server -c /etc/redis/redis.conf
且我们进一步查看该状态 执行 systemctl list-unit-files –state=enabled|grep redis
发现该服务为自启动服务,维持挖矿权限
redis.service enabled
故发现2个为权限维持手段,1个是ssh 秘钥认证,1个是服务自启动。
题目6-7的flag1为:/root/.ssh/authorized_keys flag2为/lib/systemd/system/redis.service