|
|
本章为该系列的第十六篇，亦是进入战后总结与复盘阶段的第二篇。主要围绕演习期间观察到的一些现象，并跟进思考和进一步分析，得到一些浅显但是有意思的道理。乍一看很平淡无奇，不过只有经历了，才会有深刻感悟和成长。人生贵在体验，工作亦是如此。
01
—
-
正向用于产品能力赋能：处置过的漏洞信息会从威胁情报中心分发到各产品线，产线的安全研究人员编写相应的检测规则，再通过补丁的方式推送到客户侧增强安全检测能力； -
正向用于安全事件应急：不仅是公司会将情报用于自我检查，客户侧也同样有需求。一些项目经理就曾反馈，因为第一时间获得xx软件的供应链消息，在客户现场进行了同步，得到客户领导的认可和表扬； -
反向用于漏洞情报研判：在追求安全技术的道路上，有时候借助一些事实来辅助推断，有利于提升网传漏洞真实性的研判效率。比如在某年的演习期间，外部谣传NGINX和log4j漏洞，S联系我并询问情报细节，当时啥线索都没有，故他反推一线没有任何情报，说明这两个漏洞大概率都是假的。从结果来看，他的研判是对的。
02
—
随着演习的常态化开展，攻击队在漏洞利用方面早已实现了武器化。毫不夸张的说，在做好信息收集和拿到内网权限等情况下，真的就是一键getshell --> 提权 --> 持久化 --> 横向扩展 --> 获得战果（如收集敏感信息切片外传） --> 清理攻击产生的日志...好比网上公开的漏洞poc或exp的升级版/实战版，是针对目标场景高度定制化的武器。
-
漏洞类型：从最开始的web漏洞，到后来的基于业务场景的系统漏洞，再到现在的二进制逻辑漏洞，可以看出对抗难度在逐年提升，也说明常见的web漏洞已经比较难挖，产品安全建设工作起到一定效果。不过关注点也应该随着演习攻击态势的风向标进行调整，在二进制漏洞治理方面进行重点投入； -
漏洞利用：先是从单个未授权RCE漏洞，直接拿到产品权限；又是多个漏洞的组合（如硬编码+后台命令执行），实现未授权RCE效果拿下产品；再到C/C++实现的特殊场景下账号的认证缺陷利用，绕过认证进入后台，隐蔽的使用产品功能帮助其突破边界或扩大攻击面； -
隐蔽情况：早期的演习，从安全事件的应急情况来看，或多或少都能拿到一些应用日志、审计日志进行分析。到现在情况就变了，攻击队似乎从不怕我们知道变成不想让我们知道。在处置大多数安全事件时，都感觉是非常有意识的清理了痕迹，一点儿都不想留。
03
—
-
跟踪并深挖：产品漏洞情报是指公司产品的漏洞情报，并非开源软件或商业软件的。我们一般会有一个在线编辑的大表格，用于记录该类情报、设置不同节点、跟进至闭环。通过多年的经验来看，只要是外部再传，那肯定就会有问题，比如新0day、已知历史漏洞、被夸大的产品功能...； -
竭力去验证：情报很可能就是几句话或一张打码的截图，通常第一时间拿不到详情，此时需要尽可能想办法去定位产品甚至安全漏洞。对内，发散思维去枚举可能存在的问题点、功能点，然后在值班现场review代码进行check；对外，尽可能去顺藤摸瓜，找到线索知晓人，引导其提交SRC换取奖励。
04
—
-
产线A负责人响应事件很迟缓：在反馈信息时响应慢、负责人迟迟不出面主导产线侧响应，导致整体节奏变慢、安全专员跨部门协调资源难等问题。之所以不积极，很可能是因为其职位的变化，之前非常配合甚至很主动提出安全要求，与现在形成了鲜明的对比； -
产线B不听指挥中心自己处理：产品应急组在收到产品漏洞情报时，产线B（当前公司热卖产品）都已经定位安全问题点并制定了修复方案。没有第一时间上报产品应急组，只是在面向客户侧进行修复时，流程卡壳了才同步过来。这件事儿及时上报了执行总指挥，其表示产线具备攻防实力，就让他们自己去处理吧。
在实战演习中，似乎看到了一个社会现象的本质：产品线在公司的地位重要，人在产品线中的位置高，就可以有越过常规的话语权，甚至藐视这些既定规矩和流程。这令我加深了对其的理解，且记忆深刻。
长按识别二维码，和我交流
More...
---------实战演习---------
--------- 安全运营 ---------
--------- 软件安全 ---------
--------- 企业安全 ---------
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------
原文始发于微信公众号（我的安全视界观）：演习后认知外的见微知著
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论