404notfound 发布的文章

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

文章首发在阿里云先知社区,同步更新在个人微信公众号:404 Not F0und,欢迎关注。

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

  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.png

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

ideas.png

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

vuldb.png

研究了一下各大漏洞库的漏洞数据标准,发现都对标的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年究竟发生了什么?种种这些,归根结底肯定是利益相关的原因,但具体是什么呢?

cvenumber.png

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

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

cvenumyear.png

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

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

top10.png

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

top10year.png

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

  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真就以一己之力养活了大半个安全圈从业人员。

cpe.png

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