分类 安全数据 下的文章

CVE-Flow:CVE EXP监控和预测

文章同步更新在个人公众号:404 Not F0und,CVE-Flow:CVE EXP监控和预测

Problems

首先明确下问题,文章标题包括3个子问题:

  1. CVE增量监控;

  2. CVE的EXP增量监控;

  3. CVE的EXP预测,即预测刚爆出的CVE有EXP的可能性。

串起来就是,使用CVE存量EXP数据,训练EXP预测模型,并持续监控获取增量EXP数据,重训练模型,不断迭代,以预测新增CVE的EXP可能性。

Why

考虑做CVE增量监控的原因有这么几点,一是CVE是漏洞的事实标准,各大安全公司、厂商、人员常以CVE发布预警,二是漏洞的时效性对安全至关重要,相较于已知的存量CVE,新增的CVE相对不可控,潜在的危害可能更大,更快发布漏洞预警,挽回的损失更多。三是现有CVE监控手段的局限性,比如普渡大学公开的CVE监控工具The Cassandra Tool:https://cassandra.cerias.purdue.edu/CVE_changes/today.html,安全人员和安全工具常依赖此公开服务,直接获取最新CVE数据,默认信任了底层基础设施。解析并对比了国家漏洞数据库nvd每日发布的漏洞数据集https://nvd.nist.gov/vuln/data-feeds,发现普渡大学提供的CVE数据不准。不论是公开的CVE监控工具还是商业化CVE监控服务,监控的都是nvd官方发布的数据源,因此考虑直接监控官方的第一手CVE数据源。

漏洞的两大要素:危害程度和被利用的难易程度。前者和后者共同决定了漏洞的威力,一定程度上,后者相当于给前者加了个权,更具有实际价值,应更受关注。高危的难利用漏洞和中危的易利用漏洞,考虑ROI,攻击者更可能利用易利用的中危漏洞。当然,如果高危漏洞的影响面很广,价值很高,就算再难利用也会有EXP,这时候ROI就另算了,攻击者还是会硬啃骨头。

漏洞的第三大要素是时间。无论是对甲方安全还是乙方安全,很多时候,拼的就是各种时间,甲乙方都关注的0day、1day、CVE爆发时间,甲方关注的漏洞修复时间,乙方关注的漏洞预警时间。同时考虑时间和被利用的难易程度两大漏洞要素,做CVE EXP的增量监控和预测,更具备实战意义。一方面,可以快速获取CVE最新爆出的EXP,另一方面,可以在CVE未爆出EXP之前,基于已知的存量和增量EXP数据,训练深度学习模型,提前预测新增CVE被利用的可能性,给安全人员提供CVE相关的辅助决策信息,更快产出价值。

Result

  1. T级监控CVE和EXP增量的能力,后续最快可优化至近实时监控。

  2. 产出一份CVE EXP标记数据集。截止到文章发布当天,通过多个漏洞数据源对CVE打标,总计有66798个CVE被标记有EXP,且数据集标记了EXP发布时间、来源和地址链接。

  3. 基于深度学习的EXP预测模型的预测率目前稳定在80%-85%,面向实战,可运营。

  4. 整合了存量CVE数据分析、增量CVE和EXP监控、新增CVE EXP预警和可视化能力,形成一项CVE威胁情报服务,自动化产出CVE威胁报告并推送。

What&Challenges

针对CVE增量监控,实现起来比较简单,直接监控官方数据源解析取数即可,略过。

主要讲一下EXP增量监控和预测的实现。主要分为三大内容点:数据、模型和验证效果。

遭遇的部分难点如下,会在下文详述中穿插着回答这几个问题。

  1. CVE EXP数据集打标问题,如何打标?如何标的准?

  2. 爬虫问题,遭遇反爬如何处理?放弃还是反反爬?

  3. EXP预测模型如何用于实战?如何验证实战效果?

首先是EXP数据源和标记数据集问题。CVE EXP数据源分为正查和反查两类,正查是指仅包括或可仅包括CVE的漏洞数据源,主要包括nvd、cvemitre、cvedetails、github,可以直接标记CVE有无EXP,反查是指有大量漏洞(含有CVE)的数据源,主要有exploit-db、seebug、0day.today、securityfocus、semantic attack signatures等,需要从中筛选出CVE漏洞并标记EXP。

其中nvd源主要通过nvd官方每日发布的CVE数据中Reference中的exploit标记,对CVE进行EXP监控和打标,此源适用于EXP每日增量监控。cvemitre源是mitre官方发布的CVE和exploit-db.com的映射关系,如下图。

cvemitre.PNG

经过数据对比验证,这个映射数据并不全面,和exploit-db.com中的数据有出入,还需要从exploit-db源中爬取全量漏洞数据,并从中筛选CVE数据,进行补充,exploit-db源更新频率较高,适用于EXP每日增量监控,存在较弱的反爬机制,加个UA即可绕过。

github源是通过github的搜索api,通过关键字,例如“CVE exploit”,搜索CVE EXP数据,适用于EXP增量近实时监控,但是,github源提供的EXP标记可能不如官方可信,一方面,存在一些虚假CVE EXP,另一方面,我们基于github源标记数据集训练深度学习模型,可能也会遭到恶意的数据中毒攻击,所以当突然采集到大量增量EXP时,需要人工check一下。

cvedetails源、seebug源和securityfocus源更新时间比较滞后,不适用于每日增量CVE EXP监控,但包含了大量的存量CVE漏洞,可以爬取用于训练EXP预测模型,此处要注意的是seebug官网有较强的反爬机制,cookie满足一些条件,才能正常访问漏洞页面。绕过反爬机制的策略如下:先get网页,得到一个加密的js代码1,解密后得到另外一个js代码2,运行代码2,会得到一个 __jsl_clearance ,用 __jsl_clearance 作为cookie再去get网页并且记录第二次get得到的cookie __jsluid, 会得到加密js代码3,解密后的得到js代码4,运行代码4,会得到最终的 __jsl_clearance。将第二次记录下的__jsluid和通过运行js代码4得到的__jsl_clearance 作为cookie再次get网页,即可成功。

目前,已经实现用于EXP每日增量监控的数据源有:nvd、github、exploit-db,用于EXP月度增量监控的数据源有:cvemitre、cvedetails、seebug,用于标记EXP数据集训练EXP预测模型的数据源有:nvd、cvemitre、cvedetails、github、exploit-db、seebug。从以上数据源采集到CVE的EXP,则认为该CVE可被公开利用,上述数据源未覆盖到的CVE,暂时认为不存在公开EXP,后续会扩大数据源,使得EXP的标记更为准确。使用不同属性数据源对CVE进行EXP打标,对应解决的问题也不同。如果使用semantic attack signatures等在野EXP标记源,可以预测CVE有无在野EXP,相较于公开EXP预测,更具有实战意义。当然,这门槛比较高,可能只有乙方大厂有条件做在野EXP预测。

其次是模型,需要基于底层数据考虑模型,目标是将预测模型用于实战。当我们完成CVE的EXP打标,有了label,剩下需要做的就是特征工程。根据前文CVE-Flow:1999-2020年CVE数据分析,我们采集到的CVE数据包括了60多个字段属性,大部分字段都有数据,不为空,可以用来训练深度学习模型。但是考虑模型实战的话,可用的字段非常有限。这是因为nvd官方发布的CVE公开数据是不断更新的,一开始可能就有个descriptions和reference,其中reference中的链接和标签也很少,后续会不断补充,补充漏洞的定级、评分、涉及到的产品、reference中的链接和标签等等。所以最新爆出的CVE的数据非常有限,60多个字段可能只有descriptions和references两个字段数据。如果等后续补充完数据再用模型进行预测,那黄花菜都凉了,提前预测也就失去了意义。如果训练阶段采用全量字段数据,在预测阶段对空字段进行数据填充,鉴于空字段太多,填充的效果将非常有限,预测模型实际效果堪忧。因此本文在训练阶段仅采用descriptions单字段和label来训练深度学习模型,以便用于实战。虽然是单字段,但是descriptions由几十到几百不等的单词组成,描述了漏洞的成因、涉及到的产品主体和版本等,可以看作有语义的高价值短文本。

对1999年-2020年至今的CVE及EXP标记数据训练EXP预测模型,直接采用上上篇文章我对安全与NLP的实践和思考中造的轮子FXY,一款安全数据特征化工具,通过pip install openfxy一键完成安装,对CVE的descriptions进行向量化处理,并调用内置的textcnn模型,训练模型,baseline模型的accuracy大约在83%,auc大约在85%,优化模型结构和参数调优,效果可能会更好一些。但descriptions上限在这摆着,后续会考虑引入reference字段数据,因为通过分析已有exp的CVE reference数据发现一些规律,CVE引用中exploit-db.com、github.com和产品厂商等站点数据,和CVE有无EXP,存在密不可分的联系。

最后是验证EXP预测模型的实战效果。2020年7月01-2020年7月14,新增384个CVE,新增83个CVE的EXP,其中16个EXP属于当月384个CVE中的15个CVE,以0.5为阈值,15个CVE中有4个被漏报,11个被预测正确,在1天-14天时间跨度内,以15为分母,当前正样本预测准确率在73%,后续随着时间跨度的增大,越来越多的EXP被爆出,可以衡量的预测率也会随之增加。

以上计算方法不足以定量评估模型的实战性能,因为出现EXP和出现CVE的时间间隔,短则几天甚至几小时,长则几十天甚至几个月,短时间内很难全部确定每个CVE的EXP真实标签ground truth。这里有个缓解的评估方法是,计算出已有的6万多个exp出现和cve出现的时间间隔,根据其主体数据制定阈值,比如当90%的cve在一个月内有exp,那么阈值就是一个月,一个月统计一次模型的实战性能。

我们仍然可以从一些case中定性评估下模型的实战性能。case主要分为预测正确、漏报和未知三类。

预测正确的部分CVE样本如下:

cve1.PNG

通过这些descriptions,EXP预测模型可以大致判断CVE是否可以有EXP,上述预测正确的这些样本大多都属于应用安全中的典型漏洞,易于利用,此时EXP预测模型相当于一个有经验的安全工程师(工具人)。

漏报的部分CVE样本如下:

cve2.PNG

以个人的应用安全经验,一眼扫过去descriptions,我觉得EXP预测模型没啥毛病,但是事实是都有EXP,典型的漏报,把影响很大的CVE-2020-5902都给漏掉了。分析下case,5902有exp,可能是因为是RCE和产品影响面很广,exp自然就有。

暂时未知的部分CVE样本如下:

cve3.PNG

随着时间的推移,和增量EXP的爬取,这部分CVE样本将会被一一验证。

At Last

目前,CVE-Flow初步实现了1999-2020年CVE数据分析和监控、EXP监控和预警、可视化等功能,每日会自动化运行、生成报告、推送至github和邮箱,致力于打造一款好用的CVE威胁情报服务。

CVE-Flow相关数据集和源码逐步开源在:https://github.com/404notf0und/CVE-Flow

每日CVE威胁情报报告:https://github.com/404notf0und/CVE-Flow/blob/master/README.md

感兴趣的读者可以在公众号后台留下邮箱,等CVE-Flow服务稳定后,会定向推送情报。

Ref