介绍

此备忘单的目标是提供一个简洁的虚拟修补框架，组织可以遵循该框架以最大限度地及时实施缓解保护。

定义：虚拟补丁

一个安全策略执行层，可防止和报告已知漏洞的利用尝试。

当安全执行层分析事务并拦截传输中的攻击时，虚拟补丁就会起作用，因此恶意流量永远不会到达 Web 应用程序。虚拟补丁带来的影响是，虽然应用程序本身的实际源代码没有被修改，但利用尝试并没有成功。

为什么不直接修复代码？

从纯粹的技术角度来看，首要的补救策略是让组织更正 Web 应用程序源代码中已识别的漏洞。这个概念得到了 Web 应用程序安全专家和系统所有者的普遍认同。不幸的是，在现实世界的业务情况中，会出现许多情况下更新 Web 应用程序的源代码并不容易，例如：

• 缺乏资源- 开发人员已经分配给其他项目。
• 第 3 方软件- 用户不能修改代码。
• 外包应用程序开发- 更改将需要一个新项目。

重要的一点是 -代码级修复和虚拟修补不是相互排斥的。它们是由不同团队（OWASP Builders/Devs vs. OWASP Defenders/OpSec）执行的进程，可以串联运行。

虚拟补丁的价值

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

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

虚拟修补工具

请注意，上面的定义没有列出任何特定工具，因为有许多不同的选项可用于虚拟修补工作，例如：

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

出于示例目的，我们将展示使用开源ModSecurity WAF 工具的虚拟修补示例。

虚拟修补方法

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

1. 准备。
2. 鉴别。
3. 分析。
4. 虚拟补丁创建。
5. 实施/测试。
6. 恢复/跟进。

示例公共漏洞

让我们以下面的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 签名归为同一组有助于加快授权过程并最大限度地减少扩展测试阶段。
• 提前部署虚拟修补工具- 由于在事件响应期间时间至关重要，因此必须获得批准才能安装新软件，这将是一个糟糕的时间。例如，您可以在 Apache 服务器或 Apache 反向代理服务器上以嵌入式模式安装 ModSecurity WAF。此部署的优点是您可以为非 Apache 后端服务器创建修复程序。即使您在正常情况下不使用 ModSecurity，也最好将其“放在甲板上”，以便在需要时启用。
• 增加 HTTP 审核日志记录——大多数 Web 服务器使用的标准通用日志格式 (CLF) 无法提供足够的数据来进行正确的事件响应。您需要有权访问以下 HTTP 数据：
  • 请求 URI（包括 QUERY_STRING）
  • 完整的请求标头（包括 Cookie）
  • 完整的请求正文（POST 有效负载）
  • 完整响应标头
  • 完整响应正文

识别阶段

识别阶段发生在组织意识到其 Web 应用程序中的漏洞时。通常有两种不同的方法来识别漏洞：Proactive和Reactive.

主动识别

当组织自行评估其网络安全状况并执行以下任务时，就会发生这种情况：

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

由于自定义编码的 Web 应用程序是独一无二的，因此这些主动识别任务非常重要，因为您无法依赖 3rd 方漏洞通知。

反应式识别

识别漏洞的三种主要反应方法：

• 供应商联系（例如预警） - 当供应商披露您正在使用的商业 Web 应用程序软件的漏洞时发生。示例是 Microsoft 的主动保护计划 (MAPP)
• 公开披露- 您正在使用的商业/开源 Web 应用程序软件的公开漏洞披露。随着越来越多的人了解该漏洞，公开披露的威胁级别也会增加。
• 安全事件——这是最紧急的情况，因为攻击是活跃的。在这些情况下，必须立即进行补救。

分析阶段

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

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

虚拟补丁创建阶段

创建准确的虚拟补丁的过程受两个主要租户的约束：

1. 没有误报- 在任何情况下都不要阻止合法流量。
2. 没有误报- 永远不要错过攻击，即使攻击者故意试图逃避检测。

应注意尽量减少这两个规则中的任何一个。可能无法 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/ "[email protected] 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/ "[email protected] ^[0-9]+$" 

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

• 注意- 您应该确保正确分配规则 ID 并在错误跟踪系统中跟踪它们。
• 注意：创建虚拟补丁时有许多规避向量。请查阅OWASP 最佳实践：虚拟修补文档，以更深入地讨论反规避方法。

负安全（黑名单）虚拟补丁

负面安全模型（黑名单）基于一组检测特定已知攻击的规则，而不是只允许有效流量。

示例黑名单 ModSecurity 虚拟补丁

以下是公共咨询提供的示例PoC 代码：

http://localhost/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 包含脚本，可将 [OWASP ZAP 等工具的 XML 输出自动转换为 ModSecurity 虚拟补丁]。参考这里。
• ThreadFix 虚拟补丁- ThreadFix 还包括将导入的漏洞 XML 数据转换为用于 ModSecurity 等安全工具的虚拟补丁的自动化流程。参考这里。
• 直接导入到 WAF 设备- 许多商业 WAF 产品能够导入 DAST 工具 XML 报告数据并自动调整其保护配置文件。

实施/测试阶段

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

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

测试步骤

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

恢复/跟进阶段

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

参考

• OWASP 虚拟修补最佳实践。
• OWASP 使用 ModSecurity 保护 WebGoat。

作者和主要编辑

瑞安巴尼特 - [email protected]

乔什·兹拉丁 - [email protected]

克里斯蒂安·福里尼 - [email protected]