记一次应急响应
一次攻击流量结合源码泄露的及时应急处置
### 前言 最近恰好在参加攻防演练，作为防守方，设备还是布置在内网环境当中，一有风吹草动总是会心惊胆颤，前几天还算是没什么较大的攻击事件；在第五天突然接到了通知，被告知内部生产网的机器有异常外连的情况，下面就好好讲讲本次一波三折的应急响应。 ### 处置 1.接到通知时马上和技术人员协商，将被攻击服务器的应用服务进行关停 2.根据演习总防那边给到的一些流量包和监测到的异常数据包进行分析 根据UDP流可以判断攻击者在尝试将信息带出到DNSLOG，由此来判断该台机器出不出网 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-ac535581ac0255f69f3efba551ccd7f47c71789c.png) 对外网监控设备上捕获的攻击数据包进行分析 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-8d6154a08203fb571ef8d2205470acce57b35363.png) 从上面的数据包中可以定位到攻击的路径，根据数据包响应可以确定攻击者成功进行了类似文件写入的操作，并且根据不完整的POST数据，一大串a=应该是填充的脏数据，猜测可能是为了打满软WAF之类的；接下来就去服务器上对应的路径下进行检查写入的jsp文件 登上服务器后发现数据包中的jsp文件已经没有了，但是有可疑的jsp文件存在，直接进行文件内容读取操作，以看就很明显，是编码加密过的shell [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-1c284146bdef52c06c82ff0f3ee6a349d8212162.png) 第一时间对jsp文件进行了备份，然后进行删除，通过在线平台的沙箱对文件进行了检测，显示为安全文件 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-f6638d70d01acaa9239ed00ac1c53258fbf07838.png) 对文件内容进行解码，果不其然是魔改后的冰蝎马 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-51e4bde11c1c8a2dadea4abf1172a3c10403f166.png) 由于有多台服务器起着相同的业务系统，并且存在一个共享的文件夹，所以攻击者打下一台服务器相当于直接获取了多台服务器的权限；因此，还需要对共享文件夹进行排查，通过和现场的技术人员配合，逐一排查可疑的文件，最终删除了大概10多个shell文件。在删除shell文件没多久，又有新上传的后门文件出现，这就需要堵住攻击者的攻击路径。根据了解，被攻击的业务系统对应的war包下被写入的文件夹是存储一些业务系统涉及到的语音、图片等信息，由于不能影响生产，不能够修改文件夹权限为只读不可写。这样一来就需要确定业务系统存在的漏洞具体的位置。 ### 攻击路径还原 本着试一试的想法，尝试在Github和Gitlab上进行源代码的查找，由于该系统是有建设厂商建设的，果不其然在Github上找到了该框架的前端代码，其中泄露了一些地址。根据其中的地址，找到了建设厂商的Gitlab地址，根据交涉厂商不了解前不久新曝光的Gitlab未授权RCE的漏洞，猜测攻击者可能利用该漏洞进行了权限的绕过之后获取到了对应整体框架的前后端代码。 就在准备尝试用Gitlab的exp去打的时候，突然想到用百度的高级语法说不定能找到东西，直接"xxx"源码，第一条结果就是！！！ [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-a80fd61e2b6aba0b059c6c9e822c0e1935058ddd.png) 直接从Gitlab上把压缩包下载下来，根据攻击数据包中的POST参数对漏洞点进行定位，可以看到调用的saveLog方法就在公网泄露的代码当中，也就是说攻击者通过指定日志存储的文件，将恶意代码写入到日志文件当中；saveLog方法并未对内容进行过滤，直接写入，前面的填充垃圾数据可以缺失 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-4b9fd365a7e3e12590613b43b01674f5dcbb94c3.png) 还原一下攻击者的攻击路径： 通过业务系统暴露的域名，信息收集到对应系统的部分源码，再通过审计发现可以直接调用该接口，从而写入恶意代码，结合目录穿越传到目标路径。 当时的攻击还原截图 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-b90917c7c64bd73673ac85aac9e2854c188cd71f.png) 确定了攻击路径之后，马上和技术人员进行了协商，对业务系统的代码进行了修改，在不影响业务的情况下删除了该接口，并在当晚重启了服务，确保不存在内存马。外网的入口点成功堵上。 后续对整个应用服务目录和共享文件目录进行了后门查杀，使用盒马工具一键查杀，到这里应该算是应急完成了。 ### 后续 本以为算是彻底结束了，但是第二天，那边通知依旧存在外连情况，震惊！！！再次上到服务器上，用盒马查杀没有结果，翻了翻之前那几个目录也是没有找到后门文件。这就奇怪了。索性对所有JSP文件进行了读取输出到指定文件当中，查找后门文件的特征字符串，还是没有发现。 没办法，由于外网进来最后一层是nginx，所以还要到总防守那边去拿流量，最后也是走了流程拿到了流量，同时也对那边的防守设备事件进行了筛查，未发现有请求后门文件的流量。 通过对nginx流量分析，搜索jsp，果不其然找到了对应路径下的文件 [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-ed983aa81db3463ad0c72e506df40ce1f9cce382.png) [](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2021/11/attach-21cbf7b1d9a0f8d07004738f92baf7c5a80e5989.png) 可以发现攻击者篡改了后门文件的文件名和时间戳，企图达到隐藏shell的目的，并且由于加密过，盒马查杀没有检测到该后门文件。最想不通的是该路径下的文件夹是共享文件夹，个人角度来看无非是存储静态文件，但是这个目录居然能够解析JSP文件，并且外网能够直接访问该路径文件下的文件，这可不就是打开方便之门。 最后也是删除了后门文件，为了稳妥起见再次检查了所有服务器上的jsp文件，确保后门文件没有遗漏。 ### 总结 本次攻击事件的起因，还是系统源代码在诸如Github、Gitee代码托管平台上的泄露，导致攻击者直接获取到了一些接口信息，进而直接未授权上传了后门文件控制了应用服务器。最后也是联系到gitee和github的相关用户删除了泄露的源码信息。 建议： 1.共享文件夹非必要只读不可写权限 2.源代码不要托管，不要暴露一些接口信息，做好身份权限校验 3.做好目录可解析文件的限制 4.定期备份应用服务所有文件，便于被攻击时进行校验是否有文件被植入后门等情况
发表于 2021-11-30 09:52:34
阅读 ( 8999 )
分类：
应急响应
2 推荐
收藏
1 条评论
joker
19 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
