- 1python闭包贴吧_python中的闭包
- 2创建一个线上的笔记管理仓库（Typora+PicGo-Core+阿里云OSS+Git）_oss git
- 3认识爬虫：beautifulsoup4 库如何使用三种方式提取 html 网页元素？_python beautifulsoup查找html标签
- 4openssl漏洞补丁修复
- 5SonarQube Docker环境部署流程_docker sonarqube
- 6OpenCV+OpenCV-Contrib源码编译_opencv contrib编译
- 769、Flink 的 DataStream Connector 之 Kafka 连接器详解
- 8【云原生】Kubernetes微服务Istio：介绍、原理、应用及实战案例
- 9ue5获取actor的名称将其转成json的字符串再通过websocket发出去
- 10我遇见的靠谱面试官
解读 CVSS 通用评分系统中最具争议的 Scope_cvss scope
赞
踩
CVSS, Common Vulnerability Scoring System, 即通用漏洞评分系统，简言之就是一个对安全漏洞进行打分的标准。网络安全人员按照 CVSS 评分的维度对漏洞打分，截至到今天，CVSS 已经升级到 3.1 版本。实际上 CVSS 评分还有一些令人模糊的灰色地带，尤其是最具争议的 Scope，本次就在这里解读一下关于 Scope，到底该不该 Changed。
在线打分：
CVSS 基础解读
如果你是网络安全相关的从业者，对 CVSS 一定不会陌生，其打分维度也比较简单，如下所示。主要包括
- 攻击向量，即攻击者利用什么样的路径进行攻击，包括网络攻击，局域网攻击（蓝牙/WIFI），本地和物理攻击
- 攻击复杂度，即攻击者完成一次攻击需要的条件是否苛刻，是否可以重复攻击，例如暴力破解密码，中间人攻击，钓鱼攻击，条件竞争，这些都是复杂度高的案例
- 用户交互，即攻击者完成一次攻击，需要受害者提前做出某种行为，例如点击事件，安装应用
- 作用域，这是一个最具争议的维度，CVSS 官方解释让其具有一定的模糊性，当某个授权范围约束的组件的漏洞能够影响其他授权范围约束的资源，说明作用域/范围发生了变化
- CIA，即信息安全常说的机密性、完整性和可用性，比较简单，不再赘述
CVSS 评分一定要设定攻击场景，基于攻击场景打分。 也就是说，一个合格的漏洞评估人员，不仅要理解漏洞原理，还需要对实际的攻击场景有一个清晰的认识，这样才能对漏洞合理评分。
CVSS Scope 解读
打分维度最具模糊性的代表是 Scope，CVSS 3 引入，官方定义的模糊性导致了打分可能会出现较大，一些安全测试人员会使用 /S:C/(Scope: Changed) 提高漏洞的最终得分，事实上，Scope 并不是严重漏洞的专属，也不是一些高级漏洞的特例，一些一般问题甚至提示问题，都可以 Changed，而一些所谓的严重问题甚至致命问题，Scope 也不一定 Changed。
CVSS 3.1 对 Scope 的描述已经变得清晰起来，并且结合 Vulnerable Component（易受攻击的组件），Impacted Component（受影响组件） 两个概念，使其打分更加合理。
When a vulnerability in a component governed by one security authority is able to affect resources governed by another security authority, a Scope change has occurred.
CVSS 3.1 Scope 官方定义，其实这个定义总体上来说，与原先大体一致，即 当某个授权范围约束的组件的漏洞能够影响其他授权范围约束的资源，说明作用域/范围发生了变化。
评分说明
- Vulnerable Component 易受攻击的组件是一个独立的 Scope 作用域，Impacted Component 易受影响的组件也是一个独立的 Scope 作用域，因此，当易受攻击的组件存在漏洞，并且会影响到易受影响的组件的安全，让攻击者可以访问易受影响的组件的资源，此时“作用域”或者翻译成“范围”发生了改变。
- Scope 发生改变时，AV/AC/UI/PR 基于 Vulnerable Component 选择，而 CIA 则是基于 Impacted Component。
- 虚拟机/沙箱逃逸，允许以较低权限级别运行高权限的指令（处理器级别），这是最为典型的 Scope Changed 的漏洞，也是没有任何异议的。
- Web 应用程序中的漏洞影响用户客户端（例如 Web 浏览器），Scope 发生改变，例如 XSS，Web 服务器的路径穿越，注意 SQL 注入仍然没有改变作用域，这是因为 SQL 注入影响的仍然是目标服务器。
- 分布式组件/网络设备可能会造成 Scope Changed（例如针对 ARP/DNS 协议的攻击）。
- 通过利用应用程序中允许用户限制访问与跨多个安全范围的其他组件共享的资源（例如，操作系统资源，如系统文件）的漏洞，攻击者可以访问他们不应访问的资源。由于已经存在跨信任边界的有效路径，因此没有范围更改。
案例分析
Juniper 公司 Junos 设备代理 ARP 拒绝服务漏洞（CVE-2013-6014）（9.3 CRITICAL）
在未编号的接口上启用代理 ARP 时，允许远程攻击者执行 ARP 投毒攻击，并可能通过精心制作的 ARP 消息获取敏感信息。
| Metric | Value | Comments |
|---|---|---|
| Attack Vector | Adjacent Network | 利用此漏洞需要与目标系统建立网络邻接关系 |
| Attack Complexity | Low | 制作 ARP 数据包以利用此漏洞的复杂性很低 |
| Privileges Required | None | 非特权用户可以生成 ARP 数据包 |
| User Interaction | None | 攻击不需要任何用户交互 |
| Scope | Changed | 易受攻击的组件是 Junos 设备本身，而受影响的组件是 ARP 条目中毒的任何设备 |
| Confidentiality | High | 攻击者可以读取针对目标订阅者的任何流量 |
| Integrity | None | 虽然修改易受攻击组件上的路由表会对完整性产生影响，但对下游（受影响的）组件的完整性影响为无 |
| Availability | High | 对下游（受影响的）组件的可用性的影响导致对目标订阅者拒绝服务 |
思科访问控制绕过漏洞（CVE-2012-1342）（6.1 MEDIUM）
运行 IOS XR 软件版本 3.9、4.0 和 4.1 的思科运营商路由系统 (CRS-X) 允许远程攻击者通过分段数据包绕过 ACL 条目，即错误 ID CSCtj10975。该漏洞允许未经身份验证的远程攻击者绕过设备访问控制条目 (ACEs) 并发送本应被拒绝的网络流量。它只影响具有特定 ACE 结构的设备。
| Metric | Value | Comments |
|---|---|---|
| Attack Vector | Network | 攻击者可以从易受攻击的组件进行多跳访问 |
| Attack Complexity | Low | 创建符合标准（非第一片段）的数据包的复杂性很低 |
| Privileges Required | None | 非特权用户可以启动数据包流 |
| User Interaction | None | 攻击不依赖于任何用户交互 |
| Scope | Changed | 易受攻击的组件是 CRS 本身，而受影响的组件是受 CRS 保护的下游网络和设备 |
| Confidentiality | None | 影响是针对防火墙之外的网络和设备（受影响的组件）而不是 CRS（易受攻击的组件）进行评分的。任何机密性损失都是次要影响 |
| Integrity | Low | 利用会对受 CRS（易受攻击的组件）保护的网络或设备（受影响的组件）造成完整性影响 |
| Availability | None | 影响是针对防火墙之外的网络和设备（受影响的组件）而不是 CRS（易受攻击的组件）进行评分的。任何可用性都是次要影响（例如，有针对性的 DoS 攻击） |
Wordpress 插件 XSS（CVE-2012-1342）（6.1 MEDIUM）
这是一个最典型的 XSS 攻击的打分。
| Metric | Value | Comments |
|---|---|---|
| Attack Vector | Network | 只能通过网络利用该攻击。我们假设易受攻击的 WordPress 网站已连接到 Internet，因为这是一种常见的部署方式 |
| Attack Complexity | Low | 攻击者可以重复攻击成功 |
| Privileges Required | None | 攻击者不需要任何特权即可执行攻击 |
| User Interaction | Required | 受害者需要单击攻击者创建的恶意链接 |
| Scope | Changed | 易受攻击的组件是易受攻击的 WordPress Web 服务器。受影响的组件是受害者的浏览器 |
| Confidentiality | Low | 受害者浏览器中与易受攻击的 WordPress 网站相关的信息可以被恶意 JavaScript 代码读取并发送给攻击者 |
| Integrity | Low | 恶意 JavaScript 代码可以修改受害者浏览器中与易受攻击的 WordPress 网站相关的信息 |
| Availability | None | 恶意 JavaScript 代码无法显着影响受害者的浏览器 |
Google Chrome 沙箱逃逸漏洞（CVE-2012-5376）（9.6 CRITICAL）
Google Chrome 中的进程间通信 (IPC) 实现允许远程攻击者绕过预期的沙箱限制，实现对渲染器进程的访问，达到任意文件写的目的。
| Metric | Value | Comments |
|---|---|---|
| Attack Vector | Network | 受害者必须访问可能存在于本地网络之外的恶意网站 |
| Attack Complexity | Low | 攻击者不需要为这种攻击进行任何特殊操作 |
| Privileges Required | None | 攻击者不需要任何权限来执行此攻击 |
| User Interaction | Required | 受害者必须单击攻击者提供的特制链接 |
| Scope | Changed | 基于攻击者正在突破 Chrome 受控沙箱环境的假设，易受攻击的组件是 Google Chrome，受影响的组件是运行 Chrome 的操作系统 |
| Confidentiality | High | 最坏的情况是 Chrome 以管理权限运行。攻击者可以覆盖系统配置并授予攻击者访问系统上任何数据或管理特权的权限 |
| Integrity | High | 最坏的情况是 Chrome 以管理权限运行。攻击者可以覆盖任何文件，包括重要的系统文件 |
| Availability | High | 最坏的情况是 Chrome 以管理权限运行。攻击者可以通过覆盖特定系统文件或通过系统重新配置拒绝用户访问来导致系统崩溃 |
英特尔 DCI 问题（CVE-2018-3652)（7.6 HIGH）
第五代和第六代英特尔至强处理器 E3 家族、英特尔至强可扩展处理器和英特尔至强处理器 D 家族中 DCI（直接连接接口）的现有 UEFI 设置限制允许有限的物理存在攻击者通过调试接口访问平台机密。
| Metric | Value | Comments |
|---|---|---|
| Attack Vector | Physical | 攻击者必须能够物理访问 DCI 端口才能连接调试设备 |
| Attack Complexity | Low | 调试设备是现成的硬件，任何人都可以从英特尔购买 |
| Privileges Required | None | 攻击者可以完全访问处理器的状态，直接绕过所有安全保护 |
| User Interaction | None | 受影响的系统在 BIOS 设置屏幕中默认启用 DCI 支持 |
| Scope | Changed | 攻击者被授予对系统用户通常无法访问的硬件级别的机器状态的完全访问权限。所有基于软件的安全机制和许多基于硬件的安全机制都被完全绕过 |
| Confidentiality | High | 目标机器的整个运行状态完全暴露。任何进入内存的秘密都会暴露 |
| Integrity | High | 目标机器的整个运行状态可以修改为硬件允许的任何状态 |
| Availability | High | 击者可以通过多种方式永久拒绝服务，包括但不限于更换操作系统和修改通常无法访问的控制引导过程的 UEFI 变量 |
其他案例
本地提权或者 Android 中的应用组件漏洞，需要通过安装恶意应用来进行攻击怎么打分？
Android 本地安装应用攻击
CVE-2022-33708：Galaxy Store 中的 AppsPackageInstaller 中的不正确输入验证漏洞允许本地攻击者以 Galaxy Store 权限启动活动。
7.8 HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
因此，Android 本地安装应用，在 AV 是 Local 的基础上，PR 应该是 Low，即需要一定的权限。一个应用安装在本地，如果什么权限都不申请，几乎是做不了事情的。
Windows 本地提权攻击
CVE-2022-30138：Windows 后台打印程序特权提升漏洞。
7.8 HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
因此，本地攻击在多数场景下是需要一定的权限，当然也需要结合实际场景，看看我们的恶意应用或者恶意用户成功完成一次攻击，并造成相应影响，到底需不需要部分权限。
总结
作为安全测试人员，CVSS 是我们最为常用的一种评估漏洞风险的手段。但是实际上很多安全研究者并没有深究背后的打分机制，许多漏洞的评分也值得商榷。本次，我们深入探讨 CVSS 打分中最具争议的 Metric，即 Scope， 并结合相关案例给出实际评分标准，目的是希望大家都能够对漏洞进行合理评分。
