Kaminsky利用DNS缓存中毒漏洞和忘记密码接管用户账户

目录导航

“忘记密码” 功能以及 DNS 漏洞如何允许接管用户帐户？

在分析了 146 个 Web 应用程序的 DNS 名称解析漏洞后，Timo Longin（SEC 咨询维也纳）发现一些 Web 应用程序今天仍然存在漏洞。Kaminsky 以及 IP 碎片攻击可能允许通过“忘记密码？”接管这些 Web 应用程序的用户帐户。为了识别易受攻击的 Web 应用程序，此处提供了DNS 重置检查器。

这个攻击向量会影响我吗？
我该如何保护自己？
我应该留意这个攻击媒介吗？

问答部分涵盖了这些以及更多问题。

忘记密码？

很难想象没有这个问题的登录表单。

指定电子邮件地址
接收密码重置网址
更改密码

简单！但是“忘记密码”是怎么回事？与 DNS 漏洞相关的功能？

以下场景使这更接近：

假设攻击者可以将任意 DNS 记录注入 Web 应用程序使用的 DNS 解析器的缓存中（DNS 缓存中毒），然后他就能够操纵电子邮件域到 IP 地址的映射。因此，“gmail.com”的 DNS 名称解析不再必然指向 Google 电子邮件服务器的 IP 地址，而是例如指向攻击者电子邮件服务器的 IP 地址。

这样，攻击者就可以接收所有发往“gmail.com”的电子邮件。包括密码重置电子邮件。
下图说明了这一点：

因此，如果攻击者可以操纵 Web 应用程序的 DNS 名称解析，“忘记密码” 功能可能会被滥用来接管用户帐户。

Dan Kaminsky 已经在 2008 年的 Black Hat 会议上介绍了这种攻击向量[1]。以下对 146 个 Web 应用程序的分析是在 Timo Longin 的毕业论文“Web 应用程序中的 DNS 漏洞”[14] 期间进行的，表明攻击向量在今天仍然具有相关性。

基础知识

那么，如何检查 146 个 Web 应用程序的 DNS 名称解析是否存在漏洞？

通过注册 146 个用户！多次！

当用户在 Web 应用程序上注册时，Web 应用程序最常发送电子邮件以验证电子邮件地址。以电子邮件地址为“[email protected]”为例。为了发送电子邮件，必须首先将所述电子邮件地址的电子邮件域解析为 IP 地址。因此，对于“analysis.example”，必须确定电子邮件服务器的 IP 地址。在几次 DNS 查询之后，这会导致一个类型为“MX”的 DNS 查询被发送到“analysis.example”的权威名称服务器 (ADNS)（见图 2）。

如果我们现在要分析 Web 应用程序的 DNS 名称解析，那么流入和流出 ADNS 的 DNS 流量是一个合适的选项。为了能够以“路径上”的方式操作 DNS 查询和响应，有必要开发下图所示的“DNS 代理”软件组件（参见图 3）。

DNS 代理允许读取和修改 DNS 查询以及发送到 ADNS 和从 ADNS 发送的响应。因此，可以被动地分析 DNS 消息并主动操纵 DNS 响应。此外，在 GitHub 上可以免费获得 DNS 代理或整个分析服务器的源代码！（稍后会详细介绍！）

简而言之：如果用户在 Web 应用程序上注册，则可以检查 Web 应用程序的 DNS 名称解析的属性。

用于 DNS 分析的电子邮件地址

通过上面显示的设置，可以分析 Web 应用程序的 DNS 名称解析。但是，如果电子邮件地址“[email protected]”在多个 Web 应用程序上注册会发生什么？

这会导致多个 Web 应用程序解析“analysis.example”，并且不再可能区分来自不同 Web 应用程序的 DNS 请求。因此，我们必须使用不同的电子邮件地址在不同的 Web 应用程序上注册用户。为此，我们使用了以下格式：

[email protected]

V: Versioning

A:来检查特定的一个ttack要求的方法

I：Web应用程序的身份

如果我们在测试运行 1 中检查 Web 应用程序，使用第一种方法（从 0 开始）和标识符 1337，我们将使用以下电子邮件地址注册用户：

[email protected]

DNS 攻击及其要求

此时，可以区分来自不同 Web 应用程序的 DNS 流量。但实际上应该分析什么？

为了找到这一点，我们查看了以前的 DNS 攻击并将它们分解以确定它们的攻击要求。通过这种方式，可以确定 DNS 名称解析必须具有哪些属性是可攻击的或易受攻击的。

找到以下两个示例：

攻击要求 – IP 分片： Amir Herzberg 和 Haya Schulman [2] 发现的DNS 攻击需要 DNS 解析器来接受 IP 分片的 DNS 响应。可以通过使用 DNS 代理主动操纵 DNS 响应来检查此要求。例如，用于测试 IP 分片的 DNS 响应如下所示（见表）。

;; QUESTION SECTION:

;0100001337.analysis.example.          IN      MX



;; ANSWER SECTION:

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

此 DNS 响应的长度超过最大传输单元 (MTU)，因此必须在多个 IP 数据包中传输（IP 分片）。如果请求的 DNS 解析器接受了这个分片的 DNS 响应，它会尝试解析“a.jlguehdhzo.if.0100001337.analysis.example”。一旦 DNS 代理收到这样的 DNS 请求，我们就可以假设 Web 应用程序的 DNS 解析器支持 IP 分片。

攻击要求 – 源端口随机化：另一个例子是Kaminsky 攻击的要求[1]。要求之一是 DNS 请求具有低熵，因此很容易猜测 DNS 响应。这种低熵是由于源端口不是随机分配的。我们可以通过分析 DNS 代理的日志文件来检查此要求。散点图特别适合此目的（见图 4）。

在这种情况下，源端口是随机选择的，这使得 Kaminsky 攻击几乎不可行。

永恒的 DNS 解析

现在，DNS 代理允许检查多个 Web 应用程序的各种攻击要求。但是，我们需要讨论一个关于 DNS 代理的更重要的细节。即，DNS 代理在任何情况下都不会泄露电子邮件服务器的 IP 地址。这是为什么？

如果 Web 应用程序设法将电子邮件域解析为 IP 地址，则将发送要发送的电子邮件。这意味着 Web 应用程序不需要进行任何进一步的 DNS 查询。
因此，我们删除了在所有 DNS 响应中显示电子邮件服务器 IP 地址的所有 DNS 记录。例如，如果 Web 应用程序尝试解析 IP 分段 DNS 响应（“a.jlguehdhzo.if.0100001337.analysis.example”）中返回的 DNS 记录，则 DNS 代理会删除 ADNS 设置的应答部分。这样，Web 应用程序随后会再次尝试解析电子邮件域，并且可以一个接一个地检查不同的攻击要求。

现在注册！

现在是时候了！没有什么能阻止我们分析 146 个 Web 应用程序的 DNS 名称解析！

测试过程如下所示（见图 5）。

一切从注册开始。在这种情况下，我们使用电子邮件地址“[email protected]”在具有标识符“000001”的网络应用程序上注册。这将启动可用于测试一项或多项攻击要求的 DNS 名称解析。要查看哪些攻击要求已经过测试，哪些还没有完成，可以查看 DNS 代理的日志文件。根据已检查的要求，我们可能需要注册更多用户。为了不多次测试相同的攻击要求，我们可以在电子邮件地址（01XX000001.analysis.example）中指定要执行的测试方法。

经过大约20 小时的用户注册和数百小时的研究、编写脚本和分析，结果现已可用。

146 个 Web 应用程序的 DNS (in) 安全性

那么，所评估的 Web 应用程序的 DNS 安全性如何？

针对 5 种不同的 DNS 攻击，总共测试了 8 种不同的攻击要求。至少一次满足所有攻击要求的 DNS 攻击如下：

kaminsky攻击：146 次中的 2 次
IP 分片攻击：146 次中的 62 次

注意：由于正在进行的披露过程，我们不会发布 Web 应用程序的具体名称。

Kaminsky 攻击：针对 Kaminsky 攻击测试的攻击要求满足 146 个 Web 应用程序中的 2 个。这些要求具体如下：

DNS 请求的低熵
不使用/执行 DNS 安全功能（DNSSEC、DNS cookie 等）
可能会触发对“受害者”域（例如“gmail.com”）的大量 DNS 查询

DNS 请求的低熵在这里特别有趣。如前所述，它可以通过 UDP 源端口的散点图进行可视化。在线赌场易受攻击的 DNS 名称解析的散点图如下所示（见图 6）。

每隔一个 DNS 请求使用源端口 30200，其他 DNS 请求使用增量源端口。这使得攻击者很容易猜测使用的源端口并执行 Kaminsky 攻击。

具有可猜测源端口的第二个 Web 应用程序（新闻站）具有以下散点图（参见图 7）。

在这种情况下，源端口增量分布在 3 个“级别”上，这也使它们易于猜测。

IP 分片攻击：测试的 146 个 Web 应用程序中有 62 个满足以下要求，分析了 IP 分片攻击：

Web 应用程序 DNS 解析器接受 IP 分段的 DNS 响应
不使用/执行 DNS 安全功能（DNSSEC、DNS cookie 等）
可能会触发对“受害者”域（例如“gmail.com”）的大量 DNS 查询

此时应注意，仅检查了有关 Web 应用程序的 DNS 名称解析的要求。例如，IP 分片攻击还要求攻击者可以对从目标 ADNS 发送到目标 DNS 解析器的 DNS 响应进行分片。

其他数据： DNS 安全功能如何？DNSSEC 呢？下表给出了简要概述：

DNS 安全功能	用法*	执行**
DNSSEC	146 中的 20	146 中的 9
DNS cookie	146 中的 1	146 中的 1
0x20 编码	146 中的 0	146 中的 0
EDNS 缓冲区大小限制（<= 1232 字节）	146 中的 0	146 中的 0

*：如果 DNS 安全功能用于每个 DNS 查询，则认为使用了该功能。例如，如果 0x20 编码仅用于“MX”查询，“A”、“AAAA”和其他记录类型的查询仍然不受保护。攻击者可以利用此类安全功能的缺失。出于这个原因，DNS 安全功能的使用将被忽略，直到它实际用于每个 DNS 查询。

**：在某些情况下，可以选择使用 DNS 安全功能，但不会强制执行。例如，DNS 解析器可以请求签名的 DNS 响应而无需验证它们。当以这种方式使用安全功能时，它们不会提供任何额外的保护。因此，Enforcement 列指示是否使用和强制执行 DNS 安全功能。

DNS 重置检查器

如前所述，所使用的分析服务器可在 GitHub 上免费获得。它是DNS 重置检查器中包含的两个工具之一，可在此处找到：

https://github.com/The-Login/DNS-Reset-Checker

DNS 重置检查器由分析服务器和日志分析器组成。

如前所述，分析服务器用于获取 DNS 数据以及检查攻击要求。该日志分析器来分析所收集的数据。可以使用日志分析器分析散点图、探测的攻击要求、DNS 安全功能等等。除了上面看到的散点图外，还提供了以下信息：

Analysis of domain identifier: 999997

General Info

* Number of DNS resolver IPs: 64

* Public DNS resolvers: Outgoing IP addresses of big public DNS resolvers: 32 / 64

* Number of queries received: 346

* Active methods probed: ip_fragmentation, edns_removal, recursive_delegation

* EDNS maximum size: Not all DNS requests specified a response size.

* DNS cookies: At least one DNS query did not include a DNS cookie.

* DNSSEC: At least one DNS query did not require DNSSEC.

* Removal of EDNS (OPT): A response with a missing EDNS record was returned by the server and accepted by the resolver.

* IP fragmentation: An IP fragmented response was returned by the server but denied by the resolver.

* 0x20 Encoding: At least one DNS query did not use 0x20 encoding.

偷看日志分析器提供的信息

可以在 GitHub 上找到有关如何安装和使用 DNS 重置检查器的详细说明。

问答 (Q&A)

我是否应该在未来的安全评估中寻找这种攻击媒介？

当然是！由于此攻击向量可能允许帐户接管，因此如果适用，应将其包含在安全评估中。此外，使用已设置的分析服务器可以相当快地检查此攻击向量。

我怎么知道我是否受到影响？

如果对使用的 DNS 解析器和 DNS 基础设施存在不确定性，最简单的方法是使用 DNS 重置检查器！

我该如何保护自己？

为了防止这种攻击媒介，主要应该保护 Web 应用程序的 DNS 基础设施。可以在Google [3] 和DNS 标志日[4]上找到一些保护您自己的 DNS 解析器的最佳实践。也可以使用大型公共 DNS 提供商，例如Google [5]、Cloudflare [6] 或Cisco [7]。这些大型提供商通常会快速实施针对新 DNS 攻击的对策[8]。

可以使用 DNS 重置检查器检查在保护 DNS 基础设施后漏洞是否仍然存在。

我的 DNS 解析器都是最新的，所以我很安全……对吧？

使 DNS 解析器保持最新是朝着正确方向迈出的一步，但 DNS 名称解析中的漏洞可能仍然存在。例如，NAT/PAT 设备等网络基础设施会对 UDP 源端口的随机性产生影响，从而允许 Kaminsky 攻击（参见Herzberg 等人[9] 和漏洞说明 VU#800113 [10]）。这也是我们不讲DNS解析器的安全性，而是讲整个DNS名称解析的安全性的原因。

即使我不使用公共 DNS 解析器，DNS 漏洞也会影响我吗？

是的，至少部分是。正如 Dan Kaminsky 在2008 年[1] 中强调的那样，并在实验室环境中再次验证，私有 DNS 解析器的使用并不能防止 Kaminsky 攻击。

是否可以通过对电子邮件流量使用 TLS 来防止 DNS 漏洞？

理论上，是的。与在浏览器中一样，使用 TLS 可以降低 DNS 漏洞的严重性。但是，必须考虑到必须正确使用 TLS。通常使用 TLS，但仅用于自签名和不受信任的证书（Mayer 等人[11]）。这提供了针对被动观察者的保护，但不能针对主动攻击者（在路径上）提供保护。

帐户接管是在 Web 应用程序中利用 DNS 漏洞的唯一方法吗？

不，根据使用 DNS 的 Web 应用程序的其他功能，服务器端请求伪造 (SSRF) 或类似攻击也是可能的。在Dan Kaminsky 的演示文稿 [1] 中可以找到一些这样的攻击者向量。在本文中，我们重点介绍了“忘记密码？” 功能，因为它被许多 Web 应用程序使用。

如何对 DNS 重置检查器的结果进行评级？

要对 DNS 重置检查器的结果进行评级，您可以查看满足的攻击要求。根据满足的攻击要求，可以为有问题的 DNS 名称解析分配更高或更低的风险。

例如，如果使用可猜测的 UDP 源端口，则满足 Kaminsky 攻击的主要要求之一，因此 Kaminsky 攻击很可能成为可能。因此，存在高风险。
如果IP分片是可能的，但其他攻击要求不明确，那么攻击成功的概率就比较低。因此，风险较低。

为什么正好是 146 个 Web 应用程序？

在初始测试期间，用户注册了大约 190 个 Web 应用程序（Alexa Top 500 等）。由于某些 Web 应用程序仅允许来自大型提供商（gmail.com、outlook.com 等）的电子邮件地址或不发送注册电子邮件，因此最终检查了 146 个 Web 应用程序。

是否还检查了 SAD（Side channel AttackeD DNS）和 DNSpooq 等新攻击的攻击要求？

不，因为分析是在这些攻击发布之前完成的。其攻击要求的测试方法可能会包含在 DNS 重置检查器的未来版本中。

在此研究之前，是否已经对 Web 应用程序的 DNS 安全性进行了研究？

部分以及间接。大多数有关 Internet 上 DNS 安全性的分析都涉及 Internet 上可用的开放 DNS 解析器。这样，可以检测到 DNS 解析器易受攻击，但不能检测到 Web 应用程序使用它。

没有找到专门针对 Web 应用程序的 DNS 安全性的分析。

是否已经存在用于检查 DNS 安全性的在线工具？

是的，有几个用于检查 DNS 安全性的在线工具（例如GRC [12] 或DNS-OARC [13]）。但是，这些只测试系统指定的 DNS 解析器的 DNS 名称解析。由于 Web 应用程序有时会使用无法从 Internet 访问的 DNS 解析器，因此以这种方式进行的测试是有限的。

这个攻击向量是如何“重新发现”的？

在内部安全评估中，通常的做法是利用“忘记密码？” 内部 Web 应用程序的功能，用于获取电子邮件中的密码重置 URL。这在本地网络中很容易做到，因为可以使用 ARP 欺骗将 Web 应用程序发送的密码重置电子邮件重定向到攻击者，从而实现中间人恶意攻击。基于此攻击向量并考虑到潜在的破坏性后果，尝试将此概念应用于 Internet 上的 Web 应用程序。