文章总结： 本文描述了客户侧产品被攻击的应急响应过程，攻击者利用老漏洞的新利用方式，通过80端口调用8080端口绕过认证，结合已知SQL注入漏洞实现未授权RCE。文章强调了前后场联动分析的重要性，建议产品安全团队应关注漏洞的多种利用路径，并确保客户及时修复已知漏洞，避免因未加固导致安全事件。
综合评分： 88
文章分类： 应急响应,漏洞分析,WEB安全

客户侧产品推送样本事件处置

原创

aerfa21

我的安全视界观

2023年8月8日 06:06
北京

在每一年的演习中，我们都会处置好几十起产品安全事件，虽然绝大多数都是已知的漏洞，但仍然有记录和总结的价值。另外身处应急响应大厅，还会得到来自几千同事传来的一手情报，他们犹如探针一样驻扎在客户侧进行防守，又或是攻击队员，在演习期间不间断的上报情报，可以帮助提升公司网络安全（安全部做出相应排查、加固和检测动作）和产品安全能力（产品线依据情报详情编写检测规则）。回顾历年写下的笔记，提炼出八个典型场景进行分享：

1、面向情报公司付费信息的应急2、面向互联网侧舆情信息的应急3、客户侧产品推送样本事件处置4、某邮箱被攻击情报的自我检查5、办公网出口地址攻击客户蜜罐6、SRC白帽子突破边界进业务网7、某部门下发零日漏洞确认函处置8、公司溯源团队查到团队内部成员

本章为该系列的第九篇，亦是进入白热化战时状态的第3篇。客户侧的我司产品被攻陷，并以此为跳板发送恶意样本到其他机器。现场安服同事和后方产品应急团队双管齐下，同时开展应急响应，发现攻击队使用了一个老漏洞的新利用方式，由此对产品漏洞的利用和修复进行了反思。

—

事件描述

某日，客户侧驻场的一线同事，将产品被攻击事件上报至产品应急组。现场使用NTA设备发现异常，并结合丰富的人工经验对事件展开分析。产品应急组也将该产品的应急取证手册（演习前让产线准备好，由交付专家团队审核可操作性，以备不时之需）同步至前场，待日志回传后组织产线一起研判。

—

响应动作

前后场联动进行分析研判：客户侧同事利用现场的安全设备如NTA、hids、edr等安全产品的告警，以及各类系统及服务日志进行溯源分析，梳理漏洞利用点和攻击链；后场同事根据传回的日志进行产品漏洞分析，定位漏洞点。两者凑在一块，加速找到了产品的漏洞；
产品0day漏洞信息上报：若是出现0 day漏洞，需要由产品应急组上报指挥小组，同步漏洞信息，以辅助领导们为下一步或更上层动作进行决策（指挥小组领导的视野更宽、资源更广、消息渠道更多，往往能根据局势做出比较好的判断）；
据实际情况输出止血/解决方案：若是单点客户被攻击，舆情没有被传开，则可以先根据漏洞情况出具止血方案，快速进行止损，然后再做根除的修复方案；若是多点客户陆续被攻击，则应该权衡临时止血方案和修复方案的耗时及成本，快速给到受影响和潜在受影响的客户；
客户侧未加固清单盘点及再加固：经过分析，该客户未做后台已知漏洞的加固。即使攻击队找到了新的利用思路，若是按照加固手册执行，肯定也不会被攻击。于是就联动交付团队进行未加固客户清点，主动联系客户加固以避免被攻击。

—

处置结果

该事件涉及到的客户，已做后门清除和产品漏洞修复，后续无因为安全产品而遭到攻击的事件。针对未做同一漏洞修复的演习客户，也陆续联系进行漏洞修复，无此类事件发生，基本上是解决了这一类问题。

—

经验总结

经历过该事件，在漏洞挖掘和利用方面有了更深入的理解。实战演习关注的是前台RCE漏洞，最好是发一个请求包就能拿到产品权限。然而实际却不止那么简单，对产品的一次成功攻击=漏洞+利用路径，漏洞可以是同一个，但是利用路径却可以是多条。对于产品安全团队而言，需要看清以下几个事实：

后台老漏洞新路径利用方式：攻击者通过80端口（前台）调用8080端口（后台）进行攻击，通过该接口绕过后台认证，结合后台已知的SQL注入漏洞实现未授权RCE。在该事件中，攻击者深度结合业务场景扩展了攻击路径，做到比内部团队还了解复杂的业务逻辑，从而攻击成功；
多种常见组合实现前台RCE：演习中最害怕的就是遇到前台RCE漏洞，其攻击门槛低大多是要网络可达即可获取权限。所以在平时和集中漏挖时，重点放到了可以直接前台RCE的漏洞；次之是组合实现前台RCE效果的漏洞，比如硬编码+后台SQLi、默认密码+后台文件上传、认证绕过+后台命令执行、未授权+后台命令执行等；
针对bypass做的安全专项：回顾在做代码审计时，专门针对产线加白的函数进行了bypass测试，即对抗产品线的安全函数，如特殊符号和统一参数过滤函数。当时已经能够想到会出现bypass的情况，不过最主要还是针对发现漏洞来研究，没能想到去研究漏洞的多种利用方式，这在后续的产品安全蓝军中应该做补强；
甲方视角安全要求漏洞修完：该事件中的后台注入漏洞是内部已知，产品线也发布了公告和补丁。但是硬件盒子或To B客户的产品修复链太长，干扰修复成功的因素太多，比如没有完整的客户台账、客户出于稳定性不愿加固或升级、依赖于交付同事的责任心…并不像企业内部一样能够在快速修复，但客户也应该要有敬畏感，不能因为是后台漏洞就不修复。

长按识别二维码，和我交流

More…

——— 实战演习 ———

——— 安全运营 ———

——— 软件安全 ———****

——— 企业安全 ———****

——— 渗透测试 ———****

——— 安全开发 ———****

——— 个人体验 ———****

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：我的安全视界观 aerfa21《客户侧产品推送样本事件处置》

Tags: WEB安全安全培训安全开发安全运营应急响应渗透测试漏洞分析

你可能错过

网安别乱考证！5 本真正能帮你找工作的证书，分清刚需和智商税

数据安全风险评估系统已更新，可试用

【已复现】WordPress 未认证路径遍历漏洞，特定条件下可导致RCE

从 ZCode 到 Trae：AI 编程工具的偷传数据争议何时休