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

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

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

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

01

—

事件描述

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

02

—

响应动作

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

03

—

处置结果

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

04

—

经验总结

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

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

  ---