CVE-Flow:1999-2020年CVE数据分析

文章首发在阿里云先知社区，点击阅读原文，即可跳转。

给大家汇报一下最近工作，主要做了这么几个事情：

1. 1999-2020年CVE数据分析。

2. 增量CVE数据的T级监控。

3. EXP预警。

4. 全局自动化。

产出及价值

• 汇总产出一份近20年来CVE原始数据集：CVE2020，且持续自动更新，具备66个属性。借助数据集，可以分析各个属性数据的外在表现，推测其内在规律，辅助安全工作。

• 经过交叉打标，产出带有EXP标记的CVE标记数据集：EXP2020，且持续自动更新。借助已有标记数据集，通过机器学习和深度学习算法训练，可以预测CVE被利用的可能性，有的放矢，提高预警时间。

• 基于以上工作，开发名为CVE-Flow的工具，具备历年来CVE数据的分析、增量CVE的T级监控、EXP预警和全局自动化能力，作为外部威胁情报，给攻防双方提供有价值的CVE数据和建议。

起源

在我写的文章中，经常会交代文章的“起源”，介绍写这篇文章的原因和其中思考的过程。这主要来源于早几年在乌云看洞的时候，漏洞详情经常有果无因，只介绍了漏洞的触发点和利用方式，而最重要的如何发现这个触发点的过程却没有被提及，对于漏洞平台来说，要的是结果，而对于白帽子来说，更重要的可能是发现漏洞的过程，而这部分是缺失的，当然，这也可以理解，毕竟漏洞详情不是文章。

idea起源于目前的现状：从防的角度，做安全检测的场景和机器学习方法有一堆，但从攻的角度，机器学习的成功应用较为欠缺和有限。而从攻的角度来想，应用场景必然绕不开漏洞，那么问题也就变成了，机器学习在漏洞方面的应用。在dblp上使用vulnerability machine learning deep learning等关键字搜索，做了一下调研，发现大部分研究更偏向于学术型和研究型，能在工业界产生实际应用价值的很少，其中有一个比较有意思的应用是预测漏洞被利用的可能性。当时看到这个才发现我的思维定势，机器学习在漏洞方面的应用一定是指机器学习来挖洞吗？机器学习也可以应用在漏洞数据方面，可以做的事情例如，工程化”预测漏洞被利用的可能性“，为工业界服务。顺手在管理idea的仓库简要记录下了整个过程。

在这里给大家安莉下我的idea管理小本本，主要记录idea和TODO，找到适合自己的项目和时间管理工具很重要。

言归正传，回到机器学习和漏洞数据。先有数据后有天，如图是first.org截止到2016年3月17日，汇总的全球漏洞库，经过我的二次验证，发现除了最后一行的乌云不可用之外，其余漏洞库均在正常维护、更新和运营。目前漏洞库，官方的有美国nvd、CVE等，中国cnvd、cnnvd，澳大利亚AusCERT，欧洲CERT-EU，日本的JVN，JVN iPedia，芬兰的NCSC。非官方的主要有：Exploit DB，Rapid7的漏洞和利用库，Security Focus等。

研究了一下各大漏洞库的漏洞数据标准，发现都对标的CVE。CVE就像是一个枢纽，连接了全球的漏洞数据。这么看来可以从CVE数据出发，应用机器学习算法。如果有了大量的CVE数据，难道只做算法？用算法不是目的，是手段。产生价值才是目的。数据本身的简单统计和数据分析，同样能产生巨大的价值。

到现在为止，梳理一下我们要做的事情有：CVE数据分析（存量CVE数据分析和增量CVE监控），使用机器学习算法预测CVE的EXP可能性。

接着，向前思考怎么获取CVE及相关数据，爬虫爬还是下载订阅数据？在线还是离线？如何更新？等等的策略问题。向后思考结果和结果的展现形式。这些都是问题。

那么到这里，我们还有一件事情要做：自动化，做到自动可持续性更新，避免成为工具人。

存量CVE数据分析

先介绍点CVE相关的背景知识：CVE、MITRE、NVD、NIST、CVEdetails。安全绕不开漏洞，漏洞绕不开CVE（通用漏洞披露），CVE可以看成漏洞的美标，1999年由MITRE公司提出，现流行的ATT&CK也是由MITRE提出。MITRE上的CVE数据会被及时同步到NVD（美国国家漏洞库），NVD又是由NIST（美国国家标准技术研究所）于2005年支持创建的。而CVEdetails是2010年由第三方个人开发的，收录的CVE数据和官方的CVE数据有重叠，有差别，数据更新慢于官方几个月。

从cve的官网cve.mitre.org没有发现现成可利用的数据，爬虫爬的话，因为CVE数据字段比较多，难定义数据的统一格式，还好在NVD上有现成的data feeds，提供了1999年以来所有CVE数据，且定义好了数据格式。

解析完发现，一条完整的CVE数据最多包括66个字段，主要分为这几大类：CVE基本信息，CWE通用弱点枚举，reference引用，描述description，CPE通用平台枚举，impact影响，publishedDate公布时间，lastModifiedDate最近更改时间。其中CWE可以理解为漏洞类型，也是由MITRE提出的标准，CPE是标记漏洞影响产品的类型，是系统还是应用或是硬件，impact包括CVSS V2和CVSS V3两个版本通用漏洞评分系统。

首先对1999年-2020年5月8日的CVE数据做探索性数据分析。

截止到2020年5月8日，总计有142887个CVE，下图为CVE数量随时间变化趋势图，从趋势线可以看出，CVE数量是不断增多的，在2016-2017年CVE数量陡增，翻了近三倍，2017-2019三年来CVE数量也居高不下，仅2020年前四个多月，就爆发了6838个CVE，这样看来2020全年爆发的CVE极有可能多于2019年的18938个CVE。透过现象窥本质，为什么近三年来CVE量居高不下？是什么在驱动安全人员连年产出几万的CVE？相较于2016年，2017年究竟发生了什么？种种这些，归根结底肯定是利益相关的原因，但具体是什么呢？

是因为2017年安全行业发生的“维基解密”、“NSA武器库泄露”、“WannCry勒索病毒”等重大安全事件吗，或许有这方面原因吧，但肯定不止这些。

从漏洞危害的视角，探索CVE数量随时间变化趋势，这里采用CVSS V2划分漏洞危害的标准，将漏洞分为高危、中危、低危。从下图可以看到高危和低危漏洞增长的不算多，主要增长点是中危漏洞，中危漏洞频发。

细心的读者可能会发现上图中每年的高危、中危、低危CVE加起来都不等于上上图中的年CVE总量，准确地来说，是都小于，这是因为有部分CVE的状态是Rejected，漏洞被拒绝了，不是有效漏洞。当然这部分CVE都是有CVE id的，但这并不代表漏洞一定有价值，甚至漏洞都不一定真实存在。这涉及到申请CVE的流程，分为两大步：预定CVE编号和公开CVE漏洞进行验证。被分配了CVE id后，此时CVE的状态是Reserved，处于保留状态，还需要公开漏洞进行验证，验证不通过的即被拒绝。

从漏洞类型的视角，计算出1999-2020年CVE的有效CWE id Top10，分别代表：XSS、缓冲区溢出、不正确的输入验证、敏感信息泄露、SQL注入、权限和访问控制、目录遍历、资源管理错误、CSRF、密码问题。

再细化到每年，观察漏洞类型随时间的变化。考虑到CWE是在2006年被提出的，所以我们选取2006年以来的数据，取每年top3漏洞类型的并集，分别为：CWE-200、CWE-79、CWE-20、CWE-119、CWE-264、CWE-89、CWE-94，分别代表：敏感信息泄露、XSS、不正确的输入验证、缓冲区溢出、权限和访问控制、SQL注入、代码注入。除CWE94即代码注入外，其余均在1999-2020年总数据的top10内。

可以看到，漏洞类型随时间的变化，有升有降。这里直接给出几点分析结论。

1. 敏感信息泄露越来越严重，从2014年开始爬坡，2017年到达顶峰，后续居高不下。

2. XSS连续三冠，从2017年陡增，至今成为CVE的主旋律。

3. 不正确的输入验证，从2017年持续增长至今。

4. 缓冲区溢出在2017年到达顶峰后，近年来逐步回落。

5. SQL注入不生不死，2017-2019近三年来，日均一个半CVE。

6. 权限和访问控制漏洞越来越少，我验证了好几遍数据，2020年至今未出现一例包含CWE-264的CVE。这块有点反常，从2018年开始火热的云原生和权限、访问控制密不可分，为什么这方面CVE比较少，甚至2020年都没呢，是因为CVE官方可能将此类型的洞归属到了其他CWE id吗，还是说是因为安全相较于基础设施的演进，安全漏洞有个滞后期吗？如果是的话，是否能一定程度上说明这是一片蓝海？

7. 代码注入连年少得很，仅在2006年排名top1，近10年来都没怎么进过top10。

所以，能给出的通用建议是：建议甲方安全重点关注敏感信息泄露、XSS和不正确的输入验证。乙方和白帽子的话，可以重点就这三类漏洞锤甲方，因为大量的数据表明，这三类洞是真的多，一锤一个准。

从CVE的引用视角，通过提取引用链接的主域名数据并归并，发现CVE引用的头部数据为：在美安全公司的漏洞库、美日官方的漏洞库、各大产品厂商官方的安全通告。其中产品厂商绝大部分为oracle、apple、ibm、google、android、cisco、Microsoft、adobe、wordpress等美属企业，其中有个例外是华为，从这点看来华为安全的国际化做的不错。

分析到这里，除了华为，我国官方安全机构、安全公司和产品厂商在CVE中的存在感很弱，究其原因，猜测是安全的国际化做的不好，例如cnvd都没英语版网页。

种种这些，形成了一个既定的事实：CVE及周边是且仅是美国的一种安全生态，我们目前仍依附于此。被动依附总不是个长久的办法，是走国际化主动向CVE对接，还是联合起来做自己的标准和生态（虽然目前cnvd也联合很多安全公司做漏洞，但目测只处于正规化阶段，离标准化、生态化还比较远），这是个问题。

在CVE的引用中有个tag字段标记了CVE是否有现成的exploit，这决定了漏洞被利用的难度。exp源主要有这么几类：第一大类是github，github提供了最多的exp，第二类是安全组织和厂商，包括维护的漏洞库和官网，如packetstormsecurity、secunia、securityfocus、exploit-db、talosintelligence、hackerone等，第三类是受影响产品厂商，如wordpress、google、blogspot。

因此可以通过监控和爬取上述提供exp数据的头部源，一方面可以早发现exp，另一方面可以给CVE数据打标，标记CVE是否有公开的exploit，如果有，exp是什么，来自哪里。以此维护一份较为完整的CVE exp库，使用机器学习训练该库的标记数据，预测CVE被利用的可能性，EXP预警部分在下篇文章中详述。

最后，从CPE，即通用平台枚举的视角，简单统计下CVE涉及到的产品和厂商数据。1999年-2020年，CVE中总计涉及到8431个产品和厂商，下图为top10数据，google占到了22.8%，相当于第25名往后所有厂商的总和，google真就以一己之力养活了大半个安全圈从业人员。

除了这些分析，还可以使用这批数据做很多有意思的分析，推测和验证想法，从数据中，发现一些安全趋势，助力安全工作。

快快订阅404 Not F0und，获取安全、数据、算法的实践和思考，扫描它，带走我。