红蓝攻防应急响应实录：JSP后门排查与攻击路径还原

前言

最近恰好在参加攻防演练，作为防守方，设备都布置在内网环境当中，一有风吹草动总是会心惊胆颤。前几天还算是风平浪静，没什么较大的攻击事件；结果第五天突然接到通知，被告知内部生产网的机器有异常外连的情况。下面就来好好讲讲本次一波三折的应急响应过程。

处置

1. 接到通知后马上和技术人员协商，将被攻击服务器的应用服务进行关停。
2. 根据演习总防那边提供的一些流量包和监测到的异常数据包进行分析。

根据 UDP 流可以判断，攻击者在尝试将信息带出到 DNSLOG ，由此来判断该台机器出不出网。

接下来对外网监控设备上捕获的攻击数据包进行分析。

从上面的数据包中可以定位到攻击路径。根据数据包响应可以确定，攻击者成功进行了类似文件写入的操作，并且从那段不完整的 POST 数据来看，一大串 a= 应该是填充的脏数据，猜测可能是为了打满软 WAF 之类的防护设备。接下来就去服务器上对应的路径下检查写入的 JSP 文件。

登上服务器后发现，数据包中的 JSP 文件已经不存在了，但有可疑的 JSP 文件残留。直接进行文件内容读取操作，一看就很明显，是编码加密过的 shell。

第一时间对 JSP 文件进行了备份，然后进行删除。通过在线平台的沙箱对文件进行了检测，结果显示为安全文件。

对文件内容进行解码，果不其然是魔改后的冰蝎马。

由于有多台服务器运行着相同的业务系统，并且存在一个共享文件夹，所以攻击者打下一台服务器相当于直接获取了多台服务器的权限。因此，还需要对共享文件夹进行排查。通过与现场技术人员配合，逐一排查可疑文件，最终删除了大概 10 多个 shell 文件。

然而删除 shell 文件没多久，又有新上传的后门文件出现。这就必须堵住攻击者的攻击路径了。根据了解，被攻击的业务系统对应的 war 包下被写入的文件夹，是存储一些业务系统涉及到的语音、图片等信息。由于不能影响生产环境，无法将文件夹权限修改为只读不可写。这样一来，就需要确定业务系统存在的漏洞具体位置。

攻击路径还原

本着试一试的想法，尝试在 GitHub 和 GitLab 上查找源代码。由于该系统是建设厂商开发的，果不其然在 GitHub 上找到了该框架的前端代码，其中泄露了一些地址。根据这些地址，找到了建设厂商的 GitLab 地址。经过交涉，厂商并不了解前不久新曝光的 GitLab 未授权 RCE 漏洞，猜测攻击者可能利用该漏洞进行了权限绕过，随后获取到了整体框架的前后端代码。

就在准备尝试用 GitLab 的 exp 去打的时候，突然想到用百度的高级语法说不定能找到东西。直接搜索 "xxx"源码，第一条结果就是！

直接从 GitLab 上把压缩包下载下来，根据攻击数据包中的 POST 参数对漏洞点进行定位。可以看到，调用的 saveLog 方法就在公网泄露的代码当中。也就是说，攻击者通过指定日志存储的文件，将恶意代码写入到日志文件当中；saveLog方法并未对内容进行过滤，直接写入，前面的填充垃圾数据可以缺失。

还原一下攻击者的攻击路径：

通过业务系统暴露的域名，信息收集到对应系统的部分源码，再通过审计发现可以直接调用该接口，从而写入恶意代码，结合目录穿越传到目标路径。

当时的攻击还原截图：

确定了攻击路径之后，马上和技术人员进行了协商，对业务系统的代码进行了修改。在不影响业务的情况下删除了该接口，并在当晚重启了服务，确保不存在内存马。外网的入口点成功堵上。

后续对整个应用服务目录和共享文件目录进行了后门查杀，使用盒马工具一键查杀，到这里应该算是应急响应完成了。

后续

本以为算是彻底结束了，但是第二天，那边通知依旧存在外连情况，震惊！再次上到服务器上，用盒马查杀没有结果，翻了翻之前那几个目录也没有找到后门文件。这就奇怪了。索性对所有 JSP 文件进行了读取，输出到指定文件当中，查找后门文件的特征字符串，还是没有发现。

没办法，由于外网进来最后一层是 Nginx ，所以还需要到总防守那边去拿流量。最后走了流程拿到了流量，同时也对那边的防守设备事件进行了筛查，未发现有请求后门文件的流量。

通过对 Nginx 流量分析，搜索 jsp，果不其然找到了对应路径下的文件。

可以发现，攻击者篡改了后门文件的文件名和时间戳，企图达到隐藏 shell 的目的。并且由于文件经过加密，盒马查杀没有检测到该后门文件。最想不通的是，该路径下的文件夹是共享文件夹，从个人角度来看无非是存储静态文件，但这个目录居然能够解析 JSP 文件，并且外网能够直接访问该路径下的文件，这可不就是打开了方便之门。

最后也是删除了后门文件，为了稳妥起见，再次检查了所有服务器上的 JSP 文件，确保后门文件没有遗漏。

总结

本次攻击事件的起因，还是系统源代码在 GitHub、Gitee 等代码托管平台上的泄露，导致攻击者直接获取到了一些接口信息，进而未授权上传了后门文件，控制了应用服务器。最后也联系到 Gitee 和 GitHub 的相关用户，删除了泄露的源码信息。

建议：

1. 共享文件夹非必要设置为只读，不给写入权限。
2. 源代码不要托管在公开平台，不要暴露接口信息，做好身份权限校验。
3. 做好目录可解析文件的限制。
4. 定期备份应用服务的所有文件，便于被攻击时校验是否有文件被植入后门等情况。