CVE-Flow:CVE EXP监控和预测

Problems

首先明确下问题，文章标题包括3个子问题：

CVE增量监控；
CVE的EXP增量监控；
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

T级监控CVE和EXP增量的能力，后续最快可优化至近实时监控。
产出一份CVE EXP标记数据集。截止到文章发布当天，通过多个漏洞数据源对CVE打标，总计有66798个CVE被标记有EXP，且数据集标记了EXP发布时间、来源和地址链接。
基于深度学习的EXP预测模型的预测率目前稳定在80%-85%，面向实战，可运营。
整合了存量CVE数据分析、增量CVE和EXP监控、新增CVE EXP预警和可视化能力，形成一项CVE威胁情报服务，自动化产出CVE威胁报告并推送。

What&Challenges

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

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

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

CVE EXP数据集打标问题，如何打标？如何标的准？
爬虫问题，遭遇反爬如何处理？放弃还是反反爬？
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的映射关系，如下图。

经过数据对比验证，这个映射数据并不全面，和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样本如下：

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

漏报的部分CVE样本如下：

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

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

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