vlambda博客
学习文章列表

过去一段时间让 IT 人员不堪重负，那是因为各组织都在争先恐后地评估他们是否受到了 Log4Shell 漏洞带来的威胁和影响。而这个漏洞出现在假期里还并不是最令人崩溃的，更伤脑筋的是 Log4j CVE 紧随其后，但并不是所有漏洞的出现都值得被重视并修复，我们需要先评估他们的优先级。

而微软显然没有正确的评估漏洞的关键程度就对其进行修复工作，以至于他们在一月发布的Tuesday补丁，使得漏洞造成的混乱更加严重，这一批补丁更新进一步破坏了功能，导致需要尽快进行新一轮的更新。

这就是 IT 和网络安全人员经常要面临的困境：明确哪些漏洞是最严重的并且需要被立刻关注，哪些是风险较低的，需要在什么时候信任并申请更新。

该困境的解决，不仅需要技术人员有深刻的技术理解，还需要周密的修补计划和机智的应对技巧。没有这些的话，他们会经常因为误判一些严重漏洞的风险程度，而耽误最佳修复时间。另一方面，将大量资源用在修复一些脆弱的“漏洞”上，而如果攻击者获取不了系统的管理权限，这些漏洞也许不会被利用，那就会造成精力浪费。

CVSS 评分模型无法衡量风险

美国国家基础设施咨询委员会 (NIAC) 于 2005 年推出的通用漏洞评分系统 (CVSS) 标准旨在帮助组织评估缺陷的“严重性”。CVSS 分数虽然可以很好地评判漏洞的严重性，但还是有不足之处。CVSS 3.1 评分指南强调了， CVSS 评分旨在衡量漏洞的严重性，而并不能评估漏洞所带来的风险。

在对漏洞进行评分时，分析师常常被要求做合理的最坏打算，但经常会发生的情况是，两名资深的网络安全分析师会得出不同的分数，一个“严重”的漏洞可能会被评为不同级别的风险程度，评分的过程充满了主观性。

CVSS 分数是主观的并且经常变化

我们在 Log4j漏洞中注意到了这一点。迄今为止发布的包括Log4Shell（CVE-2021-44228)在内的这五个漏洞，随着其他信息的发掘，其中两个漏洞的风险程度被调整了。

CVE-2021-45046 刚开始被评估成一个“低风险”的 DoS 漏洞，得分为 3.7，后来被提升为“超高危风险”（9.0）。然而，随后发现的另一个 DoS 漏洞 (CVE-2021-45105) 的风险程度则是从一开始的“高风险”降级为“中等风险”。

谨慎对待后续的漏洞报告

“后续是，CVE堆积如山。其他组织、研究人员等认为，如果他们能够发现自己的 Log4j 漏洞那再好不过。因为在每个后续漏洞（CVE-2021-4104、CVE-2021-45046、CVE-2021-45105、CVE-2021-44832）中，如果想要成功造成攻击，需要攻击者先控制Log4j配置文件，或者使用 Log4j 的软件，不然无法实施攻击。”Dormann 解释道。

在披露关键漏洞或攻击技术后，其他漏洞的赏金猎人会受到激励并将注意力转移到寻找类似漏洞上——来丰富他们的 CVE 投资组合或为了拿到更多的赏金奖励，类似的现象在依赖混淆技术被披露出来，或是出现了许多模仿包之后，逐渐形成了趋势。现在也在继续渗透到开源存储库中。

然而，由于开源项目通常是由志愿者组成的小团队在其业余时间对其进行维护，因此很多不必要的功能请求或漏洞报告其实会分散维护人员的精力，导致他们负担过重。

Apache 于1月起草了立场文件，建议“安全指令必须避免给已经在做这项工作的少数维护者带来额外的精神负担。”

在一系列引人注目的漏洞被披露后，处于不利地位的不仅仅是项目的维护人员，使用这些产品的各个组织的安全和IT团队也必须花费大量资源来评估每个漏洞的影响，并为严重漏洞优先安排修补活动。

Dormann特别指出了CVE-2021-45046这个漏洞，在其CVSS分数被修订为9.0后，Dormann警告说，“在一个多月前，CVSS分数变高可能会在该漏洞披露后引发警报，但互联网上还没有发现一个真实的应用程序，真正的受到了它的影响。”确实，一些不了解它的供应商可能随波逐流的声称说他们受到了影响，但实际上他们并没有确认他们的软件确实受到该漏洞了影响。”他继续说。

Dormann 认为，在没有对应用程序中组件的“上下文关系”进行检测时（例如，某些组件中的特定类或方法有时会更易受攻击），仅仅因为应用程序是含有 Log4j 的特殊版本，就声称该应用程序易受攻击，这显然是不对的。“那么 CVE 的 CVSS 分数很有可能并不能准确的反映其影响不同产品的严重性。”

如何判定漏洞的优先级？

在确定优先级时，参考漏洞的CVSS 分数只是第一步，分析师还需要具体评估在它们各自的环境中可能会带来的最坏情况。可以让不明身份的攻击者远程操控的漏洞通常被视为“高”或“超高危”级别风险程度，并且应该被优先考虑修复，尤其是在使用的组件易受攻击的情况下。

至于其他漏洞，例如，被评为中等风险的，如果它们是完全依赖于另一个漏洞来实现攻击的（例如，作为漏洞链的一部分），或需要攻击者做出某类权限操作的，那么针对它们的修补工作就可以稍微延后一些，将重心放在评估和消除能利用这类漏洞的初始攻击向量上。

Log4j这样的日志框架使得评估漏洞的风险级别变得更加困难。这是因为，例如，运行一个易受攻击的Log4j版本的日志服务器，即使它不是直接面向互联网的，但记录其活动、请求和输入（合法和恶意）的Web服务器也足以触发漏洞，即使是在外围设备后面的日志服务器上。

因此，即使乍一看 Log4Shell 漏洞在您的环境中似乎没有被利用，但对于那些外围控制和易受攻击的组件在您的网络中的位置进行全面评估，可能有助于得出更好的结论。

CERT/CC的“特定利益相关者漏洞分类 (SSVC)框架”旨在评估漏洞对其环境的适用性，并为漏洞分析人员提供了更好的解决方法，即用一个一刀切的模块化决策系统，该系统具有明确定义的部分，漏洞管理人员可以根据其“上下文”选择和使用。

“SSVC是关于在漏洞管理期间可靠地将证据转化为决策，并旨在成为决策者和分析师之间的连接点，从而让领导层可以做出基于风险的决策，分析师可以持续收集证据并执行这些决策。”Dormann解释道。

尽管 SSVC 本身可能不足以解决所有问题，比如对 log4j 这样的库中的漏洞进行评分，但该框架确实有助于判定漏洞的优先级，并做出决策。

顺便说一句，与信息安全专业人士社区聚集的社区保持联系是非常有益的，并且可以节省时间，社交媒体上也是如此。订阅infosec（信息安全）摘要和开源项目邮件列表可以及时获取来自合格可靠专业人士的信息，他这些专业人士可能会帮你了解哪些漏洞更为重要。诚然，任何通信类文章都需要组织的内部团队进一步去审查，但它至少给分析师指了一条明路。

更新还是不更新？

其次，验证和审查更新也是十分具有挑战性的一步，它同时需要人工干预和自动化。虽然为易受攻击的组件下载和应用最新补丁是应对漏洞的推荐行为，也可能会提供解决方法。决策者必须评估怎么选择才可以获得更好的结果：是自动修复还是手动应用解决方案。

如果应用解决方案带来的好处超过下载可疑更新所带来的成本和潜在风险，那么可能选择手动应用解决方案更好。更新配置文件有可能破坏某些东西，但与下载未经审查的更新的风险相比，风险相对可控，如参考 SolarWinds 示例和可疑依赖项的情况。

并且，使用自动化SCA工具和 Log4j 扫描器，例如CISA、Google和Microsoft的漏洞分析工具，或是国内的悬镜源鉴OSS和奇安信开源卫士，都是不错的选择，可以发现潜伏在应用程序中的特定易受攻击的代码片段和类，准确地识别应用在被执行的过程中调用的第三方组件风险。

另一方面，像微软 1 月补丁Tuesday这样的错误补丁更难提前预测，不过幸运的是它只是一个罕见的例子。这些更新引起的问题只能在有些人已经受到影响之后，通过信息安全社区成员、邮件列表和社交媒体渠道被发现。

微软确实之后发布了紧急带外 (OOB) 更新来解决那些由错误的操作系统更新引起的问题，但仍然没有解决最初由有问题的更新造成的混乱和困境：是立即使用补丁Tuesday的更新还是先在实验室环境中测试下？另一种办法是，在没有补丁的情况下，依靠主动监控解决方案去提供安全保护。

“尽管 Microsoft 提供了官方补丁，但 [CVE-2022-21907] 提醒我们，软件的功能给了攻击者滥用的机会去进行恶意的行为。”来自Virsec公司的Kim说道， “与其试图不断修补和识别这些漏洞，企业更应该寻找一种实时监控解决方案来保护应用软件及其功能免受此类攻击。”

相关阅读