虚拟补丁速查表¶

简介¶

本速查表旨在提供一个简洁的虚拟补丁框架，组织可依此最大化及时实施缓解保护措施。

定义：虚拟补丁¶

一个安全策略执行层，用于阻止并报告已知漏洞的利用尝试。

当安全执行层分析事务并拦截传输中的攻击时，虚拟补丁开始发挥作用，从而使恶意流量永远无法到达Web应用程序。虚拟补丁的结果影响是，虽然应用程序的实际源代码本身未被修改，但漏洞利用尝试并未成功。

为什么不直接修复代码¶

从纯技术角度来看，首要的修复策略是组织在Web应用程序源代码中纠正已识别的漏洞。这一概念得到了Web应用程序安全专家和系统所有者的普遍认同。不幸的是，在实际业务场景中，存在许多更新Web应用程序源代码并不容易的情况，例如：

资源匮乏 - 开发人员已被分配到其他项目。
第三方软件 - 代码无法由用户修改。
外包应用开发 - 更改将需要一个新项目。

重要的是：代码层面的修复和虚拟补丁并非互斥。它们是由不同团队（OWASP 构建者/开发人员 vs. OWASP 防御者/运维安全）执行的流程，可以并行运行。

虚拟补丁的价值¶

虚拟补丁的两个主要目标是：

最小化修复时间 - 修复应用程序源代码需要时间。虚拟补丁的主要目的是尽快为已识别的漏洞实施缓解措施。这种响应的紧迫性可能有所不同：例如，漏洞是通过内部代码审查或渗透测试识别的，与作为实时事件响应的一部分发现漏洞相比。
攻击面缩小 - 重点是最小化攻击向量。在某些情况下，例如缺少正向安全输入验证，可能实现100%的攻击面缩小。在其他情况下，例如缺少XSS缺陷的输出编码，您可能只能限制暴露。请记住 - 10分钟内减少50%优于48小时内减少100%。

虚拟补丁工具¶

请注意，上述定义并未列出任何特定工具，因为有多种不同的选项可用于虚拟补丁工作，例如：

中间设备，如WAF或IPS设备
Web服务器插件，如ModSecurity
应用层过滤器，如ESAPI WAF

为便于示例，我们将使用开源的ModSecurity WAF工具来展示虚拟补丁示例。

虚拟补丁方法论¶

虚拟补丁，像大多数其他安全流程一样，不应该随意处理。相反，应该遵循一个一致的、可重复的流程，这将提供最大的成功机会。以下虚拟补丁工作流程模仿了IT事件响应的行业公认实践，并包含以下阶段：

准备。
识别。
分析。
虚拟补丁创建。
实施/测试。
恢复/跟进。

公共漏洞示例¶

让我们以以下SQL注入漏洞作为本文其余部分的示例

WordPress Shopping Cart Plugin for WordPress
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php
reqID Parameter prone to SQL Injection.

描述:

WordPress 的 WordPress 购物车插件包含一个缺陷，可能允许攻击者执行SQL注入攻击。

问题在于/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php脚本未能正确清理用户提供给reqID参数的输入。

这可能允许攻击者在后端数据库中注入或操纵SQL查询，从而实现任意数据的操纵或泄露。

准备阶段¶

在虚拟补丁方面，正确利用准备阶段的重要性再怎么强调也不为过。您需要做很多事情来设置虚拟补丁流程和框架，在实际处理已识别的漏洞，或者更糟的是，对实时Web应用程序入侵作出反应之前。关键是，在实时入侵期间，不是提出安装Web应用程序防火墙和虚拟补丁概念的理想时机。真实事件期间，紧张气氛高涨，时间至关重要，因此，在风平浪静时打下虚拟补丁的基础，并在事件发生时准备就绪。

以下是在准备阶段应处理的几个关键事项：

公共/供应商漏洞监控 - 确保您已订阅您正在使用的所有商业软件的供应商警报邮件列表。这将确保在供应商发布漏洞信息和补丁数据时，您能收到通知。

虚拟补丁预授权 – 虚拟补丁需要快速实施，因此标准软件补丁的正常治理流程和授权步骤需要加快。由于虚拟补丁实际上并未修改源代码，因此它们不需要像普通软件补丁那样进行大量的回归测试。将虚拟补丁与杀毒软件更新或网络IDS签名归为同一类别，有助于加快授权过程并最大限度地减少扩展测试阶段。

提前部署虚拟补丁工具 - 由于事件响应期间时间至关重要，此时再获取安装新软件的批准将是糟糕的时机。例如，您可以将ModSecurity WAF以嵌入模式安装在您的Apache服务器上，或者作为Apache反向代理服务器。这种部署的优势在于，您可以为非Apache后端服务器创建修复。即使您在正常情况下不使用ModSecurity，最好也将其“待命”，以便在需要时启用。
增加HTTP审计日志记录 – 大多数Web服务器使用的标准通用日志格式（CLF）无法提供足够的数据来执行适当的事件响应。您需要访问以下HTTP数据：
- 请求URI（包括QUERY_STRING）
- 完整的请求头（包括Cookie）
- 完整的请求体（POST负载）
- 完整的响应头
- 完整的响应体

识别阶段¶

识别阶段发生于组织意识到其Web应用程序中存在漏洞之时。通常有两种不同的识别漏洞的方法：主动和被动。

主动识别¶

这发生于组织自行评估其Web安全态势并执行以下任务之时：

动态应用程序评估 - 道德攻击者对实时Web应用程序进行渗透测试或运行自动化Web评估工具以识别缺陷。
源代码审查 - 道德攻击者使用手动/自动化方法分析Web应用程序的源代码以识别缺陷。

由于定制编码的Web应用程序是独一无二的，这些主动识别任务极为重要，因为您无法依赖第三方漏洞通知。

被动识别¶

识别漏洞的三种主要被动方法有：

供应商联系（例如预警） - 发生在您正在使用的商业Web应用程序软件供应商披露漏洞时。例如微软的活动保护计划（MAPP）
公开披露 - 您正在使用的商业/开源Web应用程序软件的公开漏洞披露。由于更多人了解该漏洞，公开披露的威胁级别会增加。
安全事件 – 这是最紧急的情况，因为攻击正在活跃进行。在这种情况下，必须立即进行修复。

分析阶段¶

以下是开始分析阶段的推荐步骤：

确定虚拟补丁适用性 - 虚拟补丁非常适合注入型缺陷，但可能无法为其他攻击类型或类别提供足够的攻击面缩小。应彻底分析底层缺陷，以确定虚拟补丁工具是否具有足够的检测逻辑能力。
利用错误跟踪/票务系统 - 将漏洞信息输入错误跟踪系统，用于跟踪和度量。建议您使用您已在使用的票务系统，如Jira，或者您可以使用专业工具，如ThreadFix。
验证漏洞名称 - 这意味着您需要有漏洞公告、漏洞扫描等指定的正确公共漏洞标识符（如CVE名称/编号）。如果漏洞是主动而非通过公开公告识别的，则应为每个漏洞分配自己的唯一标识符。
指定影响级别 - 了解Web漏洞的严重程度始终很重要。信息泄露可能不会与SQL注入问题以相同的方式处理。
指定受影响的软件版本 - 您需要识别列出的软件版本，以便确定您已安装的版本是否受影响。
列出触发问题所需的配置 - 某些漏洞可能只在特定配置设置下才会显现。
列出概念验证（PoC）利用代码或攻击/测试期间使用的有效载荷 - 许多漏洞公告都附带了展示如何演示漏洞的利用代码。如果这些数据可用，请务必下载进行分析。这在后续开发和测试虚拟补丁时将非常有用。

虚拟补丁创建阶段¶

创建精确虚拟补丁的过程受两个主要原则的约束：

无误报 - 在任何情况下都不要阻止合法流量。
无漏报 - 绝不能遗漏攻击，即使攻击者故意尝试规避检测。

应谨慎行事，尽量减少违反这两条规则的情况。可能无法100%遵守这些目标，但请记住，虚拟补丁是为了降低风险。业务所有者应该明白，虽然您获得了缩短“修复时间”指标的优势，但您可能并未对缺陷实施完全修复。

手动创建虚拟补丁¶

正向安全（允许列表）虚拟补丁（推荐解决方案）¶

正向安全模型（允许列表）是一种全面的安全机制，为应用程序提供独立的输入验证包络。该模型指定了有效输入的特征（字符集、长度等…），并拒绝任何不符合规范的内容。通过为应用程序中每个页面的每个参数定义规则，应用程序受到一个独立于其代码的额外安全包络的保护。

允许列表ModSecurity虚拟补丁示例¶

为了创建允许列表虚拟补丁，您必须能够验证正常、预期的输入值是什么。如果您在准备阶段实施了适当的审计日志记录，那么您应该能够审查审计日志以识别预期输入类型的格式。在这种情况下，reqID参数应该只包含整数字符，因此我们可以使用此虚拟补丁

##
## Verify we only receive 1 parameter called "reqID"
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'"
  SecRule &ARGS:/reqID/ "!@eq 1"

##
## Verify reqID's payload only contains integers
##
SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "!@rx ^[0-9]+$"

此虚拟补丁将检查指定页面上的reqID参数值，并阻止除整数之外的任何字符作为输入。

注意 - 您应确保正确分配规则ID并在错误跟踪系统中进行跟踪。
注意：创建虚拟补丁时存在多种规避向量。有关反规避方法的更深入讨论，请参阅OWASP 最佳实践：虚拟补丁文档。

负向安全（阻止列表）虚拟补丁¶

负向安全模型（拒绝列表）基于一套规则，这些规则检测特定的已知攻击，而不是只允许有效流量。

阻止列表ModSecurity虚拟补丁示例¶

以下是公开咨询中提供的示例PoC代码

https:///wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1

查看有效载荷，我们可以看到攻击者插入了一个单引号字符，然后在末尾添加了额外的SQL查询逻辑。基于这些数据，我们可以像这样禁止单引号字符

SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'"
  SecRule ARGS:/reqID/ "@pm '"

哪种虚拟补丁方法更好 – 正向安全还是负向安全¶

虚拟补丁可以采用正向或负向安全模型。您决定使用哪种模型取决于具体情况和一些不同的考虑因素。例如，负向安全规则通常可以更快地实施，但可能的规避也更频繁。

另一方面，正向安全规则提供更好的保护，但它通常是一个手动过程，因此对于大型/动态网站而言，不具备可扩展性且难以维护。虽然为整个站点手动制定正向安全规则可能不可行，但当漏洞警报识别出特定问题位置时，可以有选择地采用正向安全模型。

警惕特定于漏洞利用的虚拟补丁¶

您应该抵制走捷径并快速创建特定于漏洞利用的虚拟补丁的冲动。

例如，如果授权渗透测试在某个页面上识别出XSS漏洞并在报告中使用了以下攻击载荷：

<script>
  alert('XSS Test')
</script>

仅仅阻止该精确载荷的虚拟补丁是不明智的。虽然它可能提供一些即时保护，但其长期价值会显著降低。

自动化虚拟补丁创建¶

随着漏洞数量的增加，手动创建补丁可能变得不可行，自动化手段可能变得必要。如果漏洞是使用自动化工具识别的，并且有XML报告可用，则可以利用自动化流程将此漏洞数据自动转换为保护系统的虚拟补丁。

三个示例包括：

OWASP ModSecurity 核心规则集（CRS）脚本 - OWASP CRS包含将ZAP等工具的XML输出自动转换为ModSecurity虚拟补丁的脚本。参考此处。
ThreadFix 虚拟补丁 - ThreadFix还包括将导入的漏洞XML数据自动转换为ModSecurity等安全工具的虚拟补丁的自动化流程。参考此处。
直接导入WAF设备 - 许多商业WAF产品能够导入DAST工具的XML报告数据并自动调整其保护配置文件。

实施/测试阶段¶

为了准确测试新创建的虚拟补丁，可能需要使用除Web浏览器之外的应用程序。一些有用的工具是：

Web浏览器。
命令行Web客户端，如Curl和Wget。
本地代理服务器，如ZAP。
ModSecurity AuditViewer – 允许您加载ModSecurity审计日志文件，对其进行操作，然后将数据重新注入任何Web服务器。

测试步骤¶

最初以“仅记录”配置实施虚拟补丁，以确保您不会阻止任何正常用户流量（误报）。
如果漏洞是由特定工具或评估团队识别的 - 请求重新测试。
如果因规避而导致重新测试失败，那么您必须返回分析阶段，以确定如何更好地修复问题。

恢复/跟进阶段¶

更新票务系统数据 - 尽管您可能需要加快虚拟补丁的实施，但仍应在正常的补丁管理流程中跟踪它们。这意味着您应该创建适当的变更请求工单等，以便其存在和功能得到记录。更新票务系统还有助于识别不同漏洞类型的“修复时间”指标。请务必正确记录虚拟补丁规则ID值。
定期重新评估 - 您还应该定期进行重新评估，以验证在Web应用程序代码已用真正的源代码修复更新后，是否以及何时可以移除先前的虚拟补丁。我发现许多人选择保留虚拟补丁，因为它们提供了更好的识别/日志记录能力，优于应用程序或数据库本身的功能。
运行虚拟补丁警报报告 - 运行报告以识别您的虚拟补丁是否以及何时被触发。这将显示虚拟补丁相对于源代码修复时间暴露窗口的价值。