类IPS产品告警的通用分析方法

写在前面

本文内容大多产出于工作之余的总结，但是很多内容实际上与工作环境相关。所以得提一下内容产出属于金睛ddlab。所用的产品为启明星辰天阗高级持续性威胁检测与管理系统与全流量分析取证系统（打个广告）。旁路流量产品检测的本质相差不大，我接触过安恒APT + 态势感知 + alipha大数据分析、奇安信天眼、深信服态势感知等等产品。下文会稍微介绍检测原理+检测过程+分析过程。

一些介绍

旁路检测作为不影响网络架构一种检测方式，在客户处是非常方便部署的产品。上架+镜像流量就基本搞定了。没有串行部署入架构那种可能导致业务宕掉的风险。
另外在安服仔与驻场仔的工作中很常见，我有幸驻场过某个大型单位。哪里部署了多家厂商的探针（类IPS）产品，所有产品日志发向态势感知。类似于现在常提到的一个安全运营类似的概念。
驻场那会儿的我时常会吐槽，怎么有这么垃圾的产品？老子java的站，你一个php漏洞的EXP来扫我，产品还疯狂报警高危。再次一点的产品就直接告诉你攻击成功了。那时候的我充满疑惑，这群做产品的为什么这么菜，为什么不能预先定义的语言来自动筛掉一部分流量？还有这种批量的告警怎么分析、这种上世纪的漏洞我怎么分析他成功没有、这种我见都没见过漏洞怎么分析啊？日常上班就开始反思自己，是不是不应该做安全啊？
直到后来运气好，开始能接触产品更多层面上的内容时，博主才发现过去的自己正问候着现在的自己。后来根据日常的一些总结与学习，整理了一小部分可以被用通用方法来分析的告警。因为曾经作为驻场仔苦不堪言的经历，分享一些经验给大家。至少能只挨乙方领导的骂，不用在被甲方领导骂了。

那么言归正传。产品是如何在进行检测？看下面这张迷你的拓扑图。

攻击通过FW进入到我们的交换机，交换机再将数据转发给我的web站点，这时候，旁路镜像了流量的检测产品也就收到这一份流量。这一份流量进入到产品之后，就开始按照产品内的处理流程开始进行处理。下图是一张比较抽象的检测流程，实际上复杂很多。

那么接下来就是特征，这个玩意怎么来的。各个厂商都有自己的团队专门来负责这一方面。因为是站在流量从攻击者到被攻击服务器的中间进行检测，所以，就是一个中间人的身份，那么提取特征的时候，复现抓流量是必不可少的阶段，复杂点的情况就涉及到解密。
如何提取这一类的特征，实际上就类似于我们日常写漏洞验证的POC。不过是身份换成中间人了。对于同产品的同类型漏洞，很明显的存在通用的特征。就比如java反序列化，那么他的gadget必然是被检测的一个点，只需要我们去流量中找出规律。这也是所有厂商对外称能检测通用型0day的原因。
对于没有通用特征的漏洞，遇到一个就添加一个。但是有许多漏洞的特征并不强，也就造成了产品产生误报的场景。除了狠抓检测特征的质量，或者进行事件关联处置，不然很难被检测。流量上的检测是存在局限性的。就比如CSRF这类型漏洞是不能被流量检测到的。
那么前面该说的都说完了，检测产品在啥位置和如何检测也抽象的描述了一下。接下来就进入事件的分析。

告警分析

瞎猫碰上死耗子分析方法一

目前市面上攻击工具在测试漏洞是否存在时,会发送一段加密运算的数据，或者随机字符串进行核验。或者漏洞本身存在回显。
我们用TP的漏洞来举个例子。这个漏洞本身就会回显payload执行的结果。那么我们要做的事情就来到的分析payload这件事情上，看不懂payload没关系，你认识他执行的命令就OK。一般来说，大家手中的产品长的都差不多这个样子。

借助产品本身对协议的解析，我们直接观察http请求中的内容。如果不是星际玩家，基本都能看到whoami。

在瞅一眼http的响应，那么就可以确认攻击的结果。

这种傻瓜式的方法非常好用，因为现在工具开发者都十分滴良心。哪怕是原本不能回显的漏洞，他们也会想尽办法回显，方便利用。咱们再看看工具，小风哥的工具中，检测漏洞是否存在的就会利用md5去加密一串特殊字符串，然后再进行响应内容的匹配，匹配到了就存在漏洞。

在XRAY中，同样存在着回显利用的方式，热心的开发者留下了一些特征。比如shiro反序列化漏洞。

通信流量分析方法

这一类检测方法，有的产品不独立支持，就需要用到全流量存储产品进行检索。这一类场景就是常见的SSRF、SQL注入dnslog外带、反序列化漏洞、XXE等。
以接下来fastjson漏洞为实例，我们来看看如何快速分析。这里有一些前置的要求，就是知道fastjson反序列化漏洞是如何被利用的。由于内容比较敏感，就放一张图意思一下。

这种漏洞最常见的就是，攻击者攻击服务器，让服务器去请求恶意服务器，远程加载恶意文件。那么我们判断漏洞是否存在的依据，就在服务器是否去请求了恶意服务器。也就是咱们查到他们两之间通信的流量，基本上就石锤了。
下图是用vulhub搭建起来的一个环境，攻击者利用dnslog来检测漏洞是否存在，那么这个时候，我们只需要去查询被攻击的服务器是否发起了dns查询的请求，就能判断fastjson漏洞是否存在。所以咱们借助全流量产品即可完成这种漏洞的研判。其他远程请求类型的漏洞同理，就不一一赘述了。

响应时间分析方法

在无回显的漏洞利用中，攻击者利用代码执行来进行一定的延时，从而根据响应的时间来进行漏洞的判断。
那么只要认得到payload，我们就能利用工具，来进行快速分析。请神，上wireshark！
这里可以看上面那篇博客，sql盲注分析。https://www.yuque.com/waiting4/bb2aov/gb0xgx

瞎猫碰到死耗子分析方法二

最后这个，是每个人的精力都有限，总会遇到没见过的漏洞，这时候如何进行分析呢？
那天我坐在甲方的电脑面前，背后是三个充满期待目光的甲方领导与我方大放厥词的销售。销售说我们的安服来了，马上就能给您分析报告了。甲方领导的手下眼神中充满了期待。而我，满手的汗。TMD这个漏洞没见过。玩吉尔犊子了。
这时候怎么办？
我告诉你，去上厕所，打开百度，搜索“上级分配的工作任务完不成怎么办？会不会被开除？”。这样子准备话术给领导交差。
当然，本着实事求是的态度，我们应该找到POC，进行漏洞利用步骤的分析。分析这个漏洞预期的目的是什么？是执行一段代码？还是直接可以执行命令？还是进行文件读取？了解预期目的之后，再分析一下漏洞利用的步骤是什么。分好步骤之后咱们逐一开始分析即可。
举个例子：
之前在现场遇到了一个jumpserver RCE漏洞，我百度了一哈，有人分析过了，POC也属于公开的。那么我们直接读一下POC即可。
分析的文章：
https://mp.weixin.qq.com/s/KGRU47o7JtbgOC9xwLJARw
实际上，我们可以看到第一步需要一个临时token，我们进行一下流量与API的比对，就能快速发现第一步攻击者是否成功。当然，那次第一步读token就没成功，然后我还检查了版本等信息进行了一个扫尾工作。最后确认为友商产品的误报。

最后

实际上，全篇都是一些比较基础的分析方法。也是为了分享一些基础的经验。毕竟我也做过卑微的驻场仔。当然大家也能发现其实全部的分析都是建立在能阅读payload的基础上，如果连这漏洞是为了做什么都不知道的话，实际上很难分析出结果。
最后，祝大家开心运营产品，永不挨揍、永不挨甲方叼~