CVSS谬误——你能相信世界上最流行的漏洞度量吗?

转录:

Brian Moussalli:
你好,每个人。今天我们将讨论CVSS谬论，并提出一个问题，你能信任世界上最流行的漏洞度量吗?
我叫Brian Moussalli。我是JFrog安全公司的安全研究技术主管。我们将讨论什么是常见的漏洞评分系统，为什么CVSS不是一个准确的度量标准，我们将看看几个现实生活中的例子。
常见的漏洞评分系统是什么?它是一个免费开放的标准，用于评估软件和硬件漏洞的严重程度，由事件响应和安全团队论坛开发。目前的版本是3.1，于2019年发布。CVSS实际上提供了三种评级方法。
第一个是基础评分，它根据几个特征反映了漏洞的严重程度，我们将在下一张幻灯片中详细讨论。第二种是时间评分，它根据随着时间变化的因素(如利用代码的可用性)调整漏洞的基本严重程度。第三个分数是环境分数，它根据特定计算环境中是否存在缓解措施来调整基本和时间严重程度。
CVSS是用来做什么的?复杂的环境中充满了第三方软件包、硬件等等。无论是您的组织网络还是您在生产环境中使用的docker容器，几乎所有东西都是由第三方软件或硬件组件组成的，这些组件随时都可能受到攻击。这一事实会给您的组织或产品带来风险，并需要采取补救措施，但在生产环境中补救可能在时间和工作方面代价高昂。出于这个原因，我们希望优先考虑产品环境中的漏洞修复。
输入CVSS。CVSS给了我们一个分数，这有助于我们了解威胁的严重程度以及我们应该惊慌到什么程度。没有人喜欢被黑客攻击，因为补救需要软件开发人员或IT或DevOps团队的工作，所以应该正确地进行。
基础分数是如何计算的?我们有几个指标构成可利用性评分，还有另一组指标用于影响评分。这两个组合给出了基础分数和向量字符串，我们可以在下面的图片中看到。
访问向量度量显示了此漏洞可能如何被利用，是本地攻击还是可以使用网络连接进行的攻击。访问复杂度度量是指利用漏洞的难度。特权所需度量是指攻击者为了利用漏洞而必须拥有的特权。用户交互指标指定利用此漏洞是否需要除攻击者之外的人员交互。范围度量是指此漏洞对其他模块或资源的影响。2022世界杯阿根廷预选赛赛程机密性度量是指对易受攻击组件管理的信息资源机密性的影响，高的是完全失去机密性。2022世界杯阿根廷预选赛赛程完整性度量是指对组件受保护资源的影响。例如，如果攻击者能够在利用后修改文件，高是完整性的完全损失。可用性度量是指对组件可用性的影响，高的是完整的，可用性的损失，如拒绝服务。
为什么CVSS不是一个准确的度量?CVSS没有考虑到的关键组件是代码先决条件，比如哪些是易受攻击的函数或者这些函数的所有使用都是易受攻击的?此信息可以表示为当前基字符串或向量字符串配置的先决条件，例如服务的脆弱配置是什么，它是默认配置还是普通配置。环境先决条件就像所有Windows, Linux或mac，它们都是脆弱的吗?
让我们来看看一些例子，看看我到底是什么意思。cve - 2016 - 10749。它是cJSON中的缓冲区溢出。让我们来看看CVE的描述。第一个函数，即2016年10月2日之前cJSON中的解析字符串函数，有一个缓冲区过读，由一个以双引号开始，以反斜杠结束的字符串所证明。此漏洞的基本得分为9.8，这是非常重要的。是这样吗?
让我们来看看。正如我们在利用示例中看到的，为了利用此漏洞，攻击者必须控制cJSON解析函数的输入。这意味着CVE的可利用性和影响是高度上下文相关的。这取决于在我们的产品或环境中如何使用易受攻击的功能。如果cJSON库已经安装了，但是没有人使用它，那就非常非常无趣了。另一方面，如果一个软件使用带有用户控制输入的cJSON解析函数，那就非常有趣了。向量字符串中的攻击向量读取网络，但这实际上不是那么准确。
CVSS基础评分没有考虑攻击向量是否依赖于上下文，这意味着它需要易受攻击的软件组件使用用户输入调用此函数。在这种情况下，用户输入是理解CVE是否与我相关以及是否应该引起临界CVE应该引起的恐慌的关键。所需的特权指标也是如此，在本例中没有，但是利用此漏洞所需的特权取决于使用库的上下文。它可能只在需要事先身份验证的系统中可用。影响评分也是一样。影响也可能取决于上下文，并依赖于易受攻击的进程或服务运行的权限。
让我们来看看另一个CVE。下一个漏洞是Apache mod_sed模块中的越界写漏洞。它是一个过滤器模型，提供与新的流编辑器命令行工具相同的功能，但用于HTTP请求和响应。同样，我们看到它得到了9.8分，这很关键，但真的是这样吗?
让我们来看看。默认情况下不使用Mod_sed，实际上它是非常罕见的。这是一个难得的过滤器模块。为了使Apache可被利用，必须将其配置为使用sed模块。正如我们在这个配置中看到的，这个mod_sed模块可以定义为某个端点的输入筛选器。在本例中，它是HTTP路由目录，这意味着对服务器的所有请求都将由该模块处理，但这是不寻常的。在现实中，攻击者必须猜到正确的易受攻击端点，否则他们应该能够访问Apache的配置文件，这是非常、非常、非常不可能的。在这种情况下，我建议攻击复杂度不要太低。
CVSS评分没有考虑其他缓解措施，例如限制请求大小，这在这种CVE情况下可能有所帮助。成功利用CVE的另一个要求是发送到服务器的数据的大小。它需要向服务器发送超过2gb的数据。这是CVSS中没有表达的另一件事，但在缓解和补救方面至关重要。这个漏洞可以通过在Apache的配置中使用LimitRequestBodySize指令来缓解，这是非常容易添加的。在我看来，这真的真的将风险从关键的9.8降低到更低的水平。
结论:CVSS对于初始评估是有用的，但不能解释几个先决条件，如代码先决条件。当一个特定的功能是脆弱的，在我看来，攻击向量的值应该是上下文相关的。上下文选项不存在，所以每个人都使用网络，这是非常不准确的，引起混乱，或者可能不是混乱，但导致cve得到很高的基础分数，利用分数。影响力评分也是如此。影响分数分数非常与上下文相关。在很多时候，它们依赖于漏洞可能产生的特定影响。如果是流程或服务拥有的特权，配置先决条件也没有考虑到，或者脆弱配置有多常见，还是默认配置?我们可以在CVSS基础分数和向量字符串中指定所有这些信息。
此外，还有Windows、Linux或macOS等环境附加条件。他们都很脆弱吗?有一些库或软件服务可以在这三种操作系统或其他操作系统上运行，但它们是否都一样容易受到攻击?我们无法通过基础得分，可利用性得分或影响力得分来判断。关键是环境，环境，环境。要了解漏洞的全部影响和严重程度，需要了解完整的背景。这就是我们需要的，以便在我们的组织中最好地利用CVSS评分，当我们优先考虑哪些需要补救和哪些需要修复时。
这里有一个来自JFrog x射线的例子，你可以在其中看到上下文分析。您可以看到，除了显示给用户的CVSS分数之外，还有一个JFrog严重性度量和上下文分析字段，它们告诉用户CVE是否实际适用于他们的情况。下面，您可以看到，这取决于客户端第一方代码实际使用易受攻击的函数，从而对其环境构成真正的威胁。客户端将获得指向易受攻击代码的特定指针，该指针具有确切的文件和行。这可以帮助他们以最好的方式修复这个漏洞，无论是改变发送给函数的参数，这使它变得脆弱，还是确保用户输入不会进入脆弱的函数，以防用户输入可能是一个问题。
底线是我们应该始终考虑CVE的全部背景，不幸的是，CVSS不足以理解和帮助我们优先考虑我们应该如何在补救中指导我们的资源。2022世界杯阿根廷预选赛赛程如果您有任何问题，请随时发邮件给我，邮箱是brianm@www.si-fil.com。非常感谢。