应急响应实战分析：红蓝攻防演练中的Java Web漏洞利用与后门排查

前几天还算是风平浪静，但在攻防演练的第五天，警报突然响起。作为防守方，我们接到通知：内网生产环境的服务器出现了异常外联。接下来的应急响应过程可谓一波三折，下面就来详细复盘一下这次事件。

应急处置

1. 立即协调技术人员，关停被攻击服务器的应用服务，阻断攻击链。
2. 根据演习指挥部提供的流量包和异常数据包进行分析。

根据捕获的UDP流分析，攻击者正在尝试将信息外带到 dnslog.cn，以此探测目标机器是否能够出网。

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

从数据包可以定位到攻击路径。根据响应判断，攻击者成功执行了类似文件写入的操作。POST数据中大量的a=字符，猜测是为了填充数据以绕过软WAF等防护设备。

我们立即登录服务器，检查数据包中对应的路径，发现攻击者写入的jsp文件已被删除，但存在其他可疑的jsp文件。读取文件内容，发现是经过编码加密的Webshell。

我们第一时间备份并删除了该文件。通过在线沙箱对文件进行检测，结果显示为安全。

对文件内容进行解码后，确认是经过魔改的冰蝎马。

由于多台服务器运行着相同的业务系统，并且共享一个文件夹，攻击者控制一台服务器就相当于获取了多台服务器的权限。因此，必须对共享文件夹进行全面排查。在现场技术人员的配合下，我们逐一筛查可疑文件，最终删除了十多个Webshell。

然而，删除后不久，新的后门文件再次出现。这说明必须堵住攻击者的入口。经了解，被攻击的业务系统war包下被写入的文件夹用于存储语音、图片等业务数据。考虑到不能影响生产，不能简单地将文件夹权限改为只读。因此，确定业务系统存在的具体漏洞入口迫在眉睫。

攻击路径还原

抱着试一试的心态，我们尝试在Github和Gitlab上搜索源代码。由于该系统由特定厂商建设，果然在Github上找到了该框架的前端代码，其中泄露了一些内部地址。根据这些地址，我们找到了建设厂商的Gitlab。

与厂商沟通后得知，他们并不了解近期新曝光的Gitlab未授权RCE漏洞。我们怀疑攻击者可能利用此漏洞绕过权限，获取了整个框架的前后端代码。

就在准备尝试利用Gitlab的exp进行验证时，突然想到可以用百度高级搜索语法试试。搜索“xxx源码”，第一条结果就是泄露的代码仓库！

直接从Gitlab下载压缩包，根据攻击数据包中的POST参数定位漏洞点。发现攻击调用的saveLog方法就在公网泄露的代码中。这意味着攻击者通过指定日志存储的文件名，将恶意代码直接写入日志文件。saveLog方法未对输入内容做任何过滤，前面的垃圾数据填充只是为了绕过检测。

攻击路径还原如下：

1. 通过暴露的业务系统域名进行信息收集，获取部分系统源码。
2. 通过代码审计，发现可以直接调用未授权接口。
3. 利用该接口，结合目录穿越手法，将恶意JSP文件写入目标路径。

当时的攻击还原截图如下：

确定攻击路径后，立即与技术团队协商，在不影响业务的前提下删除了该危险接口，并于当晚重启服务，以清除可能存在的内存马。至此，外网入口被成功封堵。

随后，对整个应用服务目录和共享文件目录进行了后门查杀，使用了诸如“盒马”等工具进行一键扫描。到这里，看起来应急响应工作已经基本完成。

后续波折

本以为事件已彻底解决，但第二天，监控再次告警：服务器依然存在异常外联！这令人震惊。

再次登录服务器，使用查杀工具未发现结果，翻查之前的可疑目录也没有找到新的后门文件。情况变得棘手。

无奈之下，将所有JSP文件内容读取并输出到指定文件，搜索后门特征字符串，依然一无所获。

由于外网流量的最后一层是Nginx，我们只能向总防守方申请调取流量日志。走完流程拿到日志后，也对防守设备的事件进行了筛查，未发现请求后门文件的明显流量。

但通过对Nginx流量日志进行分析，搜索.jsp关键词，果然找到了对应路径下的文件访问记录。

分析发现，攻击者篡改了后门文件的文件名和时间戳，试图隐藏行踪。由于文件内容被加密，常规查杀工具未能检测出来。最令人意外的是，这个共享文件夹本应只用于存储静态文件，但该目录竟然能够解析JSP文件，并且外网可以直接访问，这无异于敞开了大门。

最终，我们删除了这个隐藏的后门文件。为了稳妥起见，再次检查了所有服务器上的JSP文件，确保没有遗漏。

总结与反思

本次攻击事件的根源在于系统源代码在Github、Gitee等代码托管平台上的泄露。攻击者由此获取了未授权接口信息，直接上传后门文件，控制了应用服务器。事后，我们联系了相关平台用户，删除了泄露的源码。

安全建议：

1. 权限最小化：共享文件夹非必要情况下应设置为只读权限。
2. 代码与接口管控：源代码严禁托管于公开平台。对所有接口，尤其是文件操作、日志记录等敏感功能，必须做好身份认证与权限校验。
3. 目录解析限制：严格配置Web服务器，禁止在静态资源目录下解析动态脚本文件（如JSP）。
4. 定期备份与校验：定期备份应用服务所有文件，并可通过文件哈希校验等方式，便于在遭受攻击时快速发现文件篡改。
5. 加强代码审计与安全意识：在系统上线前及运维过程中，应定期进行安全审计，并对开发、运维人员加强安全意识培训，防止信息泄露。

这次红蓝攻防演练中的应急响应事件再次提醒我们，安全的防线往往在最意想不到的地方被突破。从源码泄露到未授权访问，再到隐蔽的后门驻留，攻击链上的每一环都值得我们深入思考和加固。关于更多安全攻防的技术讨论与案例分享，欢迎来到云栈社区与同行们交流探讨。