Geekly articles weekly

安全备忘单：虚拟补丁程序

今天我们的文章主题是虚拟补丁。

虚拟补丁程序是一个安全策略层，旨在检测和阻止对已知漏洞的利用。

虚拟补丁程序在流量分析之后开始工作，并防止恶意流量进入易受攻击的应用程序。 因此，虚拟补丁程序（如果适用）可在不修改应用程序源代码的情况下防止利用漏洞。 通常，虚拟补丁是在Web应用程序（WAF）的防火墙上实现的。

那么为什么要虚拟补丁，为什么不只是更新代码呢？

当然，更新代码是第一个推荐的解决方案，但并非总是可能的，因为组织中缺少资源（所有开发人员已经很忙，无法转移到紧急补丁程序中），使用其他人的软件（如何在此处更改代码）或只需要重写一点如果不是该修补程序的所有应用程序。
这并不意味着虚拟补丁和代码更新是互斥的！ 它们通常由不同的命令执行（鉴于这些过程的具体情况），因此补丁和更新可以并行进行。

虚拟补丁的好处如下：

  • 一种快速（相对）的解决方案，可以关闭漏洞，直到不可能发布完整的补丁为止。
  • 如果Web应用程序是您的产品，则它不会违反可能存在的现有业务流程，也就是说，如果计划了该产品的下一个补丁程序（例如，一个月之内），则无需中断整个计划。
  • 如果开发人员当前无法执行此操作，则可以与另一个团队的成员关闭漏洞。
  • 及时性-如果您使用现成的软件，则不知道何时发布您产品的补丁，当然，您也不想让它容易受到攻击。

虚拟补丁的缺点：

  • 这仍然不是万能药。 使用它时，并不能涵盖所有的攻击媒介，因此仍然存在操作危险。
  • 所有临时解决方案的缺点是临时方案将成为永久性方案的可能性。 公司将决定，一旦它起作用，我们将不再碰它，并将一切保持原样。
  • 这是一个附加解决方案，漏洞本身不会消失，而只是隐藏在附加的保护层后面。

虚拟补丁的准备工作可以分为以下步骤：

  1. 准备工作
  2. 威胁识别
  3. 分析方法
  4. 创建一个虚拟补丁
  5. 实施与测试
  6. 恢复/继续工作

公众脆弱性

例如，使用SQL注入和ModSecurity WAF（自开源以来）。

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

WordPress的WordPress购物车插件包含一个漏洞，该漏洞可能允许攻击者执行SQL注入。 问题出在脚本/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php中，其中reqID参数未正确清除。

这可能使攻击者可以在后端嵌入或操纵SQL查询，从而导致获得对数据的非法访问的可能性，并随之而来。

准备阶段

与许多过程一样，准备虚拟补丁程序是重要的组成部分。 在处理发现的漏洞（或更严重的实时攻击）之前，您需要做一些事情。 准备的目的不是要在攻击过程中疯狂地了解虚拟补丁的工作原理以及如何将WAF集成到当前基础结构中（如果没有的话），而是要采取某些深思熟虑的措施。

以下是准备工作中需要涵盖的一些关键点：

  • 监视来自供应商或公共来源的漏洞-如果您使用第三方软件，请确保您已订阅来自供应商的所有紧急邮件。 这将帮助您及时了解软件和相关补丁的新漏洞。
  • 预先准备所有必要的工作，以使虚拟补丁程序可以投入生产-虚拟补丁程序必须快速构建，因此常规的补丁程序验证过程在这里将无法进行。 由于虚拟补丁程序不会更改源代码，因此它们不需要与常规软件补丁程序进行相同数量的测试。 值得将虚拟补丁与防病毒更新或IDS签名更新归为同一类别。 这将大大加快将它们推广到生产的过程。
  • 预先构建用于虚拟补丁程序的实用程序-由于虚拟补丁程序的主要标准是速度，因此，如果需要紧急补丁程序，则安装新软件是个坏主意。
  • 增加系统的日志记录-大多数服务器默认使用的日志标准（CLF）不能提供足够的数据来正确响应事件。 您必须有权访问以下数据：

    ◦请求URI（包括QUERY_STRING）
    ◦所有请求标头（包括cookie）
    ◦完整的请求正文（包括POST加载）
    ◦完整的响应头
    ◦完整的响应主体

威胁检测阶段

当组织发现其Web应用程序中存在漏洞时，此阶段开始。 通常，有两种识别漏洞的方法-主动式和被动式。

主动的方法

组织承担安全工作并执行以下任务的情况：

  • 动态评估应用程序-对正在运行的Web应用程序执行渗透测试和/或自动评估测试，以识别缺陷。
  • 源代码检查-手动和/或自动评估Web应用程序的源代码以检测缺陷。

反应式

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

  • 来自供应商的消息-当您的软件供应商发布有关已发现漏洞的信息时。
  • 公开发布是您在公开来源中使用的软件的发现漏洞的发布。 在这种情况下，您对漏洞的响应应该比从供应商进行报告时更快，因为更多的人知道该漏洞。
  • 安全事件-这意味着攻击已经在进行中。 需要立即采取行动来具体化和关闭漏洞。

分析阶段

分析阶段的建议步骤：

  • 确定虚拟补丁如何适合您的情况-这对于消除与输入有关的缺陷（即注入）非常有用，但可能无法为其他类型或类别的攻击提供足够的保护水平。 应该对潜在问题进行详细而彻底的分析，以确定虚拟补丁软件是否将提供足够水平的检测和覆盖。
  • 让您的系统参与跟踪错误/任务-将漏洞信息输入到跟踪器中，以进行进一步的跟踪和调查。
  • 验证漏洞-查找漏洞的正式名称（如果存在）。 如果通过主动方法检测到它，则必须给它提供自己的唯一编号/名称。
  • 确定风险级别-了解利用此漏洞对您的影响有多重要始终很重要。 例如，这将是信息泄漏还是访问数据库。
  • 确定哪些软件版本存在风险-了解您是否面临风险很重要。
  • 确定在哪种软件配置下可能会出现问题-某些漏洞仅在软件的某些配置下才会出现。
  • 列出攻击/测试期间使用的概念验证漏洞或有效负载的清单-许多漏洞出版物随附证明漏洞的PoC代码。 如果有此类数据，请对其进行分析。 这对于进一步开发和测试虚拟补丁很有用。

创建虚拟补丁的阶段

创建良好的虚拟补丁的过程与两个方面有关：

  • 无误报-在任何情况下都不会阻止正常流量
  • 没有误报-即使攻击者故意试图避免检测，也永远不会错过攻击。

必须努力使这两个规则的影响最小化。 遵循这两个规则可能（最经常发生）是不可能的，但请务必记住，虚拟补丁程序旨在降低风险。

手动创建虚拟补丁
虚拟补丁中的积极方法（白名单，白名单）

这种方法是为Web应用程序创建独立的输入验证。 该方法确定有效数据的特征（字符集，长度等），并禁止任何不符合这些条件的内容。 通过为Web应用程序每个页面上的每个参数定义规则，我们将应用程序包装在独立于其源代码的附加保护层中。

基于ModSecurity中的白名单创建虚拟补丁的示例
为了创建列入白名单的虚拟补丁，我们必须能够验证正常的期望值。 如果在准备阶段中预先配置了正确的日志记录，则通过日志查看，您应该能够理解预期输入值的格式。

一个例子。

在这种情况下，reqID参数应仅包含整数，以便我们可以应用此虚拟补丁程序：

 # # ,     1    "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" # # ,   reqID     # 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参数，并仅允许输入整数。 但是，值得记住的是，攻击媒介几乎永远不会单一，攻击者可以用其他方式尝试运气。

虚拟补丁中的负面方法（黑名单，黑名单）

此方法基于定义某些已知攻击的规则列表，而不是仅允许有效流量。

在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 '"

谨防创建针对特定漏洞的虚拟补丁

当然，这看起来很有吸引力并且节省时间。 例如，如果pentest在您的页面上找到XSS并使用了以下负载：

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

创建专门阻止此类负载的虚拟补丁将是不合理的，但是在工作量和速度方面可能很有吸引力。 需要创建一个虚拟补丁来解决整个问题，而不是解决特定问题。

自动创建虚拟补丁

由于漏洞数量的增加，手动创建补丁可能变得难以忍受，而自动化成为必不可少的步骤。 如果使用自动化工具（例如，漏洞扫描程序）发现了漏洞，则有可能将这些工具的报告转换为补丁。 最受欢迎的补丁程序自动化工具可以直接导入WAF（自然，如果您的解决方案支持此功能），OWASP ModSecurity核心规则集（CRS）脚本和ThreadFix虚拟补丁程序。

实施和测试阶段

为了正确测试我们的新虚拟补丁，我们可能需要以下工具：

  • 网页浏览器
  • 用于终端的Web实用程序（例如curl和wget）
  • 本地代理
  • ModSecurity AuditViewer

步骤：

  • 首先在“仅日志”模式下实施虚拟补丁程序，以确保不会阻止正常的用户流量（false-positive选项）。
  • 如果使用任何特定工具或命令发现了此漏洞，请请求重新检查。
  • 如果由于可以绕过虚拟补丁程序而导致重新测试失败，则需要返回分析步骤以确定如何最好地解决问题。

恢复/继续阶段

  • 更新您的票务系统中的数据-尽管可能会安装虚拟补丁的最后期限，但最好跟踪和更新跟踪系统中的更改。 这将允许更充分，更充分地处理原始问题，而遗漏某些细节的可能性较小。 它还使您可以更准确地评估在解决问题的每个阶段花费的时间。
  • 定期重新评估-这有助于了解已经/即将删除哪些虚拟补丁，因为例如已经/将应用成熟的源代码补丁。
  • 设置虚拟补丁程序的报告-这将有助于了解它们涉及的时间和次数。 反过来，这将为您提供有关您更可能面临哪些风险的统计信息。

Source: https://habr.com/ru/post/zh-CN481774/

More articles:


All Articles