01 引言

近两年正如许多安全公司的研究员亲身经历的那样，网络攻击量显著增加，重大漏洞被相继爆出并伴随着在野利用。如去年年底的log4shell（CVE-2021-44228）和今年爆出的spring4shell（CVE-2022-22965）在安全圈里都掀起了不小的风浪。由于在分析spring漏洞时cve编号还没有出来，自评影响力也没那么“核弹级”，后续就没怎么关注这个漏洞的。最近突然想看看这个漏洞的CVSS评分，看看官方是怎么给这漏洞做影响力定义的。查看后发现该漏洞CVSSV2.0评分为7.5，CVSS3.1的评分为9.8。那么CVSS的评分依据究竟是什么？2.x和3.x的评分标准区别在哪？是否分数越高就表示漏洞危害越大？近年来又有哪些CVSS评分为满分的漏洞？本篇文章想就这些问题跟大家简单聊一聊。

02 CVSS评分依据

2.1 CVSS评分指标

CVSS全称为Common Vulnerability Scoring System，即“通用漏洞评分系统”，是一个行业公开的标准。其被设计用来评测漏洞的严重程度，并帮助确定所需反应的紧急度和重要度。CVSS是安全内容自动化协议（SCAP）的一部分，通常CVSS和CVE一同由美国国家漏洞库（NVD）发布并保持数据的更新。CVSS标准由FIRST制定，并由其组织团队SIG（The CVSS Special Interest Group）改进和推广。通过漏洞难易程度以及对机密性、完整性、可用性的影响综合评估后，生成一个0到10分之间的评分值来评估漏洞的严重程度。

CVSS的评分指标由三部分组成：

1、基础评价（Base Metric Group）：

评估漏洞本身固有的一些特点及这些特点可能造成的影响。基础评价指的是一个漏洞的内在特征，该特征随时间和用户环境保持不变，基础评价是CVSS评分里最重要的一个指标，我们一般说的CVSS评分都是指漏洞的基础评价得分。

2、生命周期评价(Temporal Metric Group)：

此指标衡量当前利用技术或代码可用性的状态，是否存在任何补丁或解决方法或者漏洞报告的可信度等。生命周期评价几乎肯定会随着时间的推移而改变。

3、环境评价（Environmental Metric Group）：

这些指标使分析师能够根据受影响的IT资产对用户组织的重要性定制CVSS评分，并根据组织基础结构中组件的情况的分配分值。

2.2 基础评价对比

不同版本的CVSS对以上三个维度的评价方式略有不同，CVSS2.0在基础评价阶段主要评估攻击途径、攻击复杂度、认证、机密性、完整性和可用性几个方面，评分要素如下表所示：

最终基础评价的计算方式为

基础评价得分=10*攻击途径*攻击复杂度*认证*（（机密性*机密性权重）+（完整性*完整性权重）+（可用性*可用性权重））

CVSS3.1相比于2.0在评价要素和分值上都做了调整，评价因子如下表所示：

CVSS3.1基础评价的计算方法也比2.0要复杂许多，评分由可利用性评分和影响度评分两部分构成：

基础评价得分=可利用性评分+影响度评分

要计算这两个分值我们需要先了解CVSS3.0开始引用的一个新机制——“作用域”，作用域反映了软件组件中的漏洞会否影响其以外的资源或获得其以外的权限，有“固定”和“变化”两种形态，分别表示：

unchanged(U) 固定：

被利用的漏洞只能影响由同一当局管理的资源。在这种情况下，脆弱组件和受影响组件是同一个。

changed(C) 变化：

被利用的漏洞可能会影响超出脆弱组件预期授权权限的资源。在这种情况下，脆弱组件和受影响组件并非同一个。

可利用性评分的计算方式比较简单，注意其中权限要求部分会随着作用域的变化而变化，最终计算公式为：

可利用性评分=8.22*攻击途径*攻击复杂度*权限要求*用户交互

影响度评分要稍微复杂些，其计算方式为：

当作用域=固定：影响度分值=6.42*ISCbase当作用域=变化：影响度分值=7.52*(ISCbase−0.029)−3.25*(ISCbase-0.02)^15其中：ISCbase=1-[(1-机密性影响)×(1-完整性影响)×(1-可用性影响)]

2.3 生命周期评价对比

CVSS2.0和CVSS3.1对生命周期评价的要素基本一致，都包括了利用代码成熟度、补丁完善水平和报告可信度三个方面，差别主要在具体的分值上，评价标准对比表如下所示：

计算方式比较简单，2.x和3.x都一样：

生命周期评价得分=10*利用代码成熟度*补丁完善水平*报告可信度

2.4 环境评价对比

CVSS2.0和CVSS3.1在环境评价的要素和记分方式上差别很大。CVSS2.0的环境评价要素如下表所示：

计算公式为：

环境评价得分=[生命周期评价+(10-生命周期评价)*危害影响程度]*目标分布范围

CVSS3.1的环境评价要素主要由保密性需求、完整性需求和可用性需求构成，如下表所示：

计算公式比较复杂，和2.2里讲的“作用域”有一定关系，同时有“有修正”和“无修正”两种计算方式。首先我们需要计算出2.2里基础评分指标的“影响度评分”。

当影响度<=0时，环境评价分值为0

当影响度>0 且 “无修正”：环境评价分值为

Roundup(Roundup(Min[(M.影响度分值+M.可利用度分值),10])*利用代码成熟度*补丁完善水平*报告可信度)

当影响度>0 且 “有修正”：环境评价分值为

Roundup(Roundup(Min[1.08*(M.影响度分值+M.可利用度分值),10])*利用代码成熟度*补丁完善水平*报告可信度)

其中：

1、Roundup为保留小数点后一位并向上取整（小数点后第二位大于零则进一）

2、Min为比较前后两值，取小者

3、M. 代表被修正后的分数，若对应项无修改，则为原值。

4、影响力修正得分公式为：

作用域为固定：影响度修正分=6.42*ISCModified作用域为变化：影响度修正分=7.52*(ISCModified−0.029)−3.25*(ISCModified-0.02)^15其中：ISCModified=Min(1-[(1-M.机密性影响*M.机密性需求)*(1-M.完整性影响*M.完整性需求)*(1-M.可用性影响*M.可用性需求)],0.915)

5、可利用度修正得分公式为：

M.可利用度分值=8.22*M.攻击途径*M.攻击复杂度*M.权限需求*M.用户交互

2.5 漏洞等级

CVSS2.0对漏洞等级的定义有低、中、高三个级别，CVSS3.0开始补充了“严重”这个级别，具体如下表所示，表中的CVSS分数均代表的基础评价分数：

03 评分案例分析

那么是否CVSS评分越高的漏洞就真的越严重呢？我们可以先来看看CVSS对历史经典漏洞永恒之蓝（CVE-2017-0143）的评分结果：

永恒之蓝漏洞的严重性和影响力自然不必多说，但CVSS3.X的最终评分仅为8.1分，甚至都没有进入严重级别（Critical）这一档。由于永恒之蓝爆发时还没有3.1的标准，我们可以先通过3.0的标准（与3.1基本一致）来分析下该漏洞为什么在CVSS的评分不高。

永恒之蓝漏洞的评分详情为：

CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

参考2.2小节里CVSS3.1的评分标准，这里：

AV(Attack Vector)代表攻击途径

AC(Attack Complexity)代表攻击复杂度

PR(Privileges Required)代表权限要求

UI(User Interaction)代表用户交互

S(Scope)代表作用域

C(Confidentiality Impact)代表机密性影响度

I(Integrity Impact)代表完整性影响度

A(Availability Impact)代表可用性影响度

最终结果为：

失分项主要有两个地方，一是攻击复杂度评价给的高，通俗点讲就是该漏洞的利用难度较高。因为永恒之蓝是一个远程溢出漏洞，poc和exp调试比较困难。

另外该漏洞的作用域评价为固定，因为该漏洞只影响SMB协议，不涉及其他组件、服务或协议。从2.2小节里可以看出，作用域一是会影响“权限要求”项的评分，二是会影响基础评价里“影响度”的评分公式。由于永恒之蓝漏洞由于权限要求评价项为“无”，因此这里只会对“影响度”的评分造成影响，以上两个原因造成了永恒之蓝漏洞的CVSS评分并没有大家想的那么高。

另外一些看上去不怎么起眼的漏洞CVSS却会给出较高的评分，例如Samba远程代码执行漏洞（CVE-2021-44142），这个漏洞在Samba默认配置下并不会触发，同时利用稳定性也不高，暴露面中规中矩，但CVSS却给了8.8分，比永恒之蓝评分还要高，评分详情为：

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

可以看出仅因该漏洞的利用复杂度比永恒之蓝低，总体评分就比永恒之蓝高了，这从漏洞影响面来看显然是不太科学的。

此外篇头提到的两个漏洞log4shell（CVE-2021-44228）和spring4shell（CVE-2022-22965）的评分分别为10分和9.8分，事实上这两个漏洞在评分上所有选项都是最高分，唯一区别是一个作用域可变，一个作用域固定，最终影响了计算公式：

Log4j2：

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Spring：

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

这里CVSS对作用域的定义还是比较客观的，因为log4j2是一个组件，只要调用了log4j2相应版本这个系统就会受到威胁，因此作用域为可变；而Spring4Shell只是一个框架，作用域为固定。事实上如果一个漏洞作用域为固定，换言之该漏洞只影响某个独立的组件，那么该漏洞注定得不到10分，最高分也只有9.8分，这也是为什么我们能看到那么多9.8分的经典漏洞的原因。