针对忘记密码功能的Kaminsky攻击实现账户接管

2021年11月15日21:46:21已关闭评论74 views字数 10594阅读35分18秒阅读模式

译文来源：https://sec-consult.com/blog/detail/forgot-password-taking-over-user-accounts-kaminsky-style/。受个人知识所限及看法偏见影响，部分内容可能存在过度曲解或误解。望师傅们包含并提出建议，感激。

"忘记密码"功能结合DNS漏洞攻击将可能导致用户账号接管

摘要

在分析了146个web应用的DNS域名解析漏洞后，Timo Longin（Vienna 安全顾问）发现，一些web应用程序中至今仍然存在漏洞。Kaminsky攻击以及IP碎片攻击可能会允许通过“忘记密码？”功能实现对web应用的用户账户接管。为了识别出存在漏洞的web应用，这里提供了DNS Reset Checker（DNS重置检查器）。

这种攻击向量对我有影响吗？
我该如何做好防护？
我应该对这种攻击向量保持警惕吗？

在后面的Q&A部分中将涵盖上述以及更多的问题。

忘记密码？功能

很难想象一个登录表单中如果没有这一功能会是什么样子。

指定邮箱地址
接收密码重置的URL
修改密码

这一操作非常简单！但是“忘记密码？”功能又是如何与DNS漏洞相关联的呢？

下面的情景将会让我们更容易理解这一问题：

假设攻击者能够将任意的DNS记录注入到web应用程序使用的DNS解析器的缓存中（这一操作称为DNS缓存投毒），那么他将能够操纵电子邮件域名与IP地址之间的映射。因此，像是“gmail.com”这样的DNS域名解析就不一定会再导向Google电子邮件服务器的IP地址，而是会导向攻击者电子邮件服务器的IP地址。

这样一来，攻击者就可以收到所有以“gmail.com”为目的地的电子邮件。其中就包括那些重置密码的邮件。

下图说明了这个问题：

针对忘记密码功能的Kaminsky攻击实现账户接管

因此，如果攻击者能够操纵web应用的DNS域名解析的话，“忘记密码？”的功能就会被滥用，以此来实现用户账户的接管。

Dan Kaminsky在2008年的BlackHat大会上已经介绍了该攻击向量[1]。在Timo Longin的毕业论文“web应用程序中的DNS漏洞”[14]中，对146个web应用程序进行了如下分析，表明该攻击向量在今天仍然具有相关性。

基本原理

那么，你是如何检查146个web应用的DNS域名解析是否存在漏洞的呢？

通过注册146个用户！重复多次操作！

当一个用户在一个web应用上进行注册时，web应用一般都会发送一封电子邮件来验证该邮箱是否有效。以该邮箱地址为例“[email protected]”。要想发送一封电子邮件，上述的邮箱地址域名就必须首先能够被解析为一个IP地址。因此，对于“analysis.example”来说，就必须先确定该电子邮件服务器的IP地址。经过几次DNS查询后，在一个发往“analysis.example”的权威域名服务器（ADNS）类型为“MX”的DNS查询中发现了结果（见图2）。

针对忘记密码功能的Kaminsky攻击实现账户接管

如果我们现在想分析web应用DNS域名解析情况的话，那么流向和来自ADNS的DNS流量就是一个合适的选择。为了使其能够以“on-path”的方式操纵DNS的查询与响应，有必要开发下图所示的“DNS代理”软件组件（见图3）。

针对忘记密码功能的Kaminsky攻击实现账户接管

该DNS代理能够允许读取和修改DNS查询，以及发送到ADNS的响应。因此，也就可以实现对DNS报文的被动分析，以及对DNS响应的主动操控。此外，该DNS代理或者说是整个分析服务器的源码都是在GitHub上免费提供的！（后续更新中将包含更多功能！）

简而言之：如果一个用户在一个web应用上进行注册操作，就有可能检查到web应用的DNS域名解析的属性。

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

通过上面的配置，可以分析出web应用的DNS域名解析情况。但是，如果使用电子邮箱地址“[email protected]”在多个web应用中进行注册，会发生什么呢？

这将导致“analysis.example”会被多个web应用解析，并且不再可能区分来自不同web应用的DNS请求。出于这一原因，我们必须在不同的web应用中使用不同的电子邮箱地址注册用户。为此，我们采取了以下格式：

[email protected]

V：Versioning（版本号）

A：检查特定攻击（attack）要求的方法

I：web应用的标识符（Identifier）

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

[email protected]

DNS攻击及其要求

关于这一点，可以对来自不同web应用的DNS流量进行区分。但实际上应该分析什么呢？

为了弄清这一点，我们研究了以前的DNS攻击，并将其分解以确定其攻击要求。通过这种方式，可以确定DNS域名解析必须具备哪些属性才是可攻击或是存在漏洞的。

请看以下两个例子：

攻击要求——IP分片：由Amir Herzberg和Haya Schulman发现的DNS攻击[2]要求DNS解析器能够接受IP碎片化的DNS响应。这个要求可以通过使用DNS代理主动操纵DNS响应来进行检查。例如，用于测试IP碎片的DNS响应看起来如下（见表）。

```sh
;; 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.
```

该DNS响应的长度超过了最大传输单元（MTU），因此必须分成多个IP包再进行传输（IP分片）。如果请求的DNS解析器接受这个碎片化的DNS响应，它就会进行试图解析“a.jlguehdhzo.if.0100001337.analysis.example”。只要DNS代理收到了这样的请求，我们就可以认为该web应用的DNS解析器支持IP分片。

攻击要求——源端口随机化。另一个例子是Kaminsky攻击的要求[1]。其中一个要求是，DNS请求具有低熵性，这样的话DNS响应很容易就可以被猜解到。这种低熵的结果就是源端口不是随机分配的。我们可以通过分析DNS代理的日志文件来检查这一要求。散点图特别适合用于这一目的（见图4）。

针对忘记密码功能的Kaminsky攻击实现账户接管

而在本例中，源端口是随机选择的，因此Kaminsky攻击方式几乎是不可行的。

无休止的DNS解析

现在，DNS代理允许检查多个web应用的各种攻击要求。然而，我们还需要讨论关于DNS代理一个更重要的细节。具体来说，就是DNS代理在任何情况下都不会透露出电子邮件服务器的IP地址。这是为什么呢？

如果一个web应用设法将一个电子邮件域名解析为一个IP地址，作为结果，请求的邮件将会被发出。这也意味着web应用将不需要再进行任何DNS查询了。

出于这一原因，我们从所有的DNS响应中删除了所有包含电子邮件服务器IP地址的DNS记录。例如，如果一个web应用试图解析在IP碎片化的DNS响应中返回的DNS记录（“a.jlguehdhzo.if.0100001337.analysis.example”），那么DNS代理就会删除由ADNS发起的应答响应部分。这样一来，web应用随后就会再次尝试解析电子邮件域名，以此我们就可以对不同的攻击要求进行逐一检查。

马上注册！

现在，时间到了！没有什么能够阻止我们对146个web应用的DNS域名解析进行分析了！

测试流程如下（见图5）。

针对忘记密码功能的Kaminsky攻击实现账户接管

一切都从注册开始。在本例中，我们使用邮箱地址”[email protected]“在标识符为”000001“的web应用中进行注册。此时就会发起一次DNS域名解析，可以用来测试一个或多个攻击要求。为了了解哪些攻击要求已经被测试，哪些还没有被测试，可以检查DNS代理的日志文件。根据已经检查过得要求，我们可能还需要注册更多的用户。为了不多次测试同一攻击要求，我们可以在电子邮件地址的格式中指定执行的测试方法来进行区分（01XX000001.analysis.example）。

在经过了大约20个小时的用户注册以及几百个小时的研究、脚本编写和分析后，现在已经有了结果。

146个web应用的DNS（不）安全性

那么，这些被评估的web应用的DNS安全情况究竟如何呢？

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

Kaminsky攻击：在146个应用中共有2个
IP碎片攻击：在146个应用中共有62个

注：由于正在进行的披露流程，我们不会公布这些web应用的具体名称。

Kaminsky攻击：在146个web应用中，有2个满足了为Kaminsky攻击测试的攻击要求。这些要求具体如下：

低熵的DNS请求
没有使用/执行DNS安全功能（DNSSEC、DNS cookies等）
能够触发大量的查询到一个”受害者“域名的DNS查询（如，”gamil.com“）

DNS请求的低熵性在这里表现得特别有意思。前面说过，它可以用UDP源端口的散点图来进行展现。一家在线赌场的DNS名称解析散点图如下所示（见图6）。

针对忘记密码功能的Kaminsky攻击实现账户接管

每第二个DNS请求都会使用源端口30200，其他DNS请求使用逐渐递增的源端口。这样就使得攻击者很容易就会猜到使用的端口并进行Kaminsky攻击。

第二个具有可猜测源端口的web应用（一个新闻网站）的散点图如下（见图7）。

针对忘记密码功能的Kaminsky攻击实现账户接管

在这种情况下，源端口被递增地分布在三个“层次”上，这也导致它们非常容易被猜中。

IP碎片攻击： 在测试的146个web应用程序中，有62个符合以下要求的，对IP碎片攻击进行分析：

Web应用的DNS解析器接受IP分片化的DNS响应
未使用/执行DNS安全功能（如DNSSEC、DNS cookies等）
能够触发大量的查询到一个”受害者“域名的DNS查询（如，”gamil.com“）

有关这一点还应该明确指出，这里只检查了有关web应用的DNS域名解析的要求。比方说，IP碎片攻击还要求攻击者能够将从目标ADNS发送到目标DNS解析器的DNS响应进行分片。

其他数据：什么是DNS的安全功能？DNSSEC又是什么？下表中给出了一个简单的概述：

| DNS安全功能 | 使用情况 | 强制执行情况 * |
| ------------------ | ----------- | ----------------- |
| DNSSEC | 20个 | 9个 |
| DNS cookies | 1个 | 1个 |
| 0x20 编码 | 0个 | 0个 |
| EDNS缓存大小限制 | 0个 | 0个 |

*：如果一个DNS安全功能被用于每一个DNS查询中，则被视为已使用。例如，如果0x20编码只用于“MX”查询，而“A”、“AAA”和其他记录类型的查询却不受其保护。攻击者就可以利用这种安全功能的缺失。考虑到这一原因，DNS安全功能的使用情况就被忽略了，除非它被实际用于每个DNS查询中。

**：在某些情况下，DNS的安全功能可以选择使用，但不强制执行的。例如，DNS解析器可以请求签名认证的DNS响应，而不对其进行验证。当安全功能用于这种方式时，他们不提供额外的保护。因此“Enforcement（强制执行情况）”一栏表明DNS安全功能是否被使用以及是否被强制执行。

DNS重置检查器（DNS Reset Checker）

之前提到过，本文所使用的分析服务器在Github上免费提供。它是包含在DNS重置检查器中的两个工具之一，可以在这里找到：

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

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

前面讲过，分析服务器被用来获取DNS数据以及检查攻击要求。日志分析器用于分析收集到的数据。日志分析器可以分析散点图、探测到的攻击要求、DNS安全功能和更多的东西。除了上面看到的散点图之外，还提供了以下信息：

```sh
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.
```

偷看日志分析器的信息

关于如何安装和使用DNS重置检查器的详细说明可参见GitHub。

问题与解答（Q&A）

我应该在以后的安全评估中留意到这种攻击向量吗？

答案是肯定的！由于这种攻击方法可能会导致账户被接管，如果适用的话，它应该包括在安全评估当中。此外，检查这种攻击向量可以通过一个搭建好的分析服务器进行快速检测。

我怎样才能知道自己是否会受到这一影响呢？

如果对所使用的DNS解析器和一般的DNS基础设施存在不确定性，最简单的办法就是使用DNS Reset Checker来尽可能地找出答案！

我应该如何做好防护？

要想阻止这种攻击向量，主要是应该确保web应用的DNS基础设施的安全。在 Google [3]和DNS flag day[4]中可以找到一些用于保护DNS解析器的实践案例。也可以使用像是Google [5]、Cloudflare[6] 或是思科[7]这种大型的公共DNS供应商。针对新型DNS攻击的对策[8]通常都是由这些大型供应商进行快速实施的。

在确保DNS基础设施的安全后，要想确定漏洞是否仍然存在，还是可以借助DNS Reset Checker来进行检查。

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

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

即便是我没有使用公共DNS解析，还是会受到DNS漏洞的影响是吗？

是的，至少是受部分影响。正如Dan Kaminsky在2008年已经强调过的那样[1]，并且在实验环境中已经再次证明了，使用私有DNS解析器并不能有效阻止Kaminsky攻击。

在电子邮件流量中使用TLS可以防止DNS漏洞吗？

理论上讲，是可以的。和在浏览器中一样，DNS漏洞的严重性可以通过使用TLS来抑制。但是，必须考虑到TLS是被正确使用的情况下。通常情况下，TLS只是与自签名和非信任证书一起使用（Mayer等人的研究[11]）。这仅仅提供了对被动观察者的保护，但是没有对主动攻击者（on-path）的行为进行防护。

账户接管是web应用中DNS漏洞的唯一利用方式吗？

并不，根据使用DNS的web应用的其他功能，像是服务器端请求伪造（SSRF）或类似的攻击也可能发生。在Dan Kaminsky的演讲中可以找到一些这样的攻击向量[1]。在本文中，我们只是重点讨论了“忘记密码？”的功能，因为这一功能是被大多数Web应用所使用的。

如何针对DNS Reset Checker的结果进行评级？

要对DNS Reset Checker的结果进行评级的话，你可以看一下已满足的攻击要求。根据已满足的攻击要求，相关的DNS域名解析可以被赋予较高或较低的风险。

例如，如果使用了可猜解的UDP源端口，就满足了Kaminsky攻击的一个关键要求，因此Kaminsky攻击就很可能发生。就说明了会存在较高风险。

如果IP分片的要求满足，但是其他攻击要求并不明确，那么成功攻击的概率也就会非常的低，相应地，风险也较低。

到底为什么是146个web应用呢？

在最初的测试中，不少用户都在大约190个web应用（Alexa前500名中的一些）上注册过。由于部分web应用只允许使用大型供应商的电子邮件地址（gmail.com、outlook.com等），或者并没有采用发送注册电子邮件的形式进行注册验证。因此最终就检查了这其中符合条件的146个web应用。

是否也检查了诸如SAD（Side channel AttackeD DNS）和DNSpooq等新型攻击的攻击要求呢？

没有，因为分析是在这些攻击方式发布之前完成的。它们的攻击要求的测试方法可能会包含在DNS Reset Checker的后续版本中。

在这项研究之前，是否已经有了关于web应用中DNS安全问题的研究了呢？

或多或少吧。大多数针对互联网上DNS安全的分析都是针对互联网上可用的开放式的DNS解析器。这样虽然可以检测到DNS解析器中是否存在漏洞，但是并不能检测到web应用中的使用情况。

目前暂未发现有专门针对Web应用中DNS安全问题的分析。

不是已经有了检查DNS安全性的在线工具了吗？

确实，已经有了几个检查DNS安全性的在线工具（例如GRC[12]或DNS-OARC[13]）。不过，这些工具只是测试了系统指定的DNS解析器和DNS域名解析。由于web应用有时会使用无法从互联网上访问到的DNS解析器，因此以这种方式进行测试还是存在局限性的。

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

在内部安全评估过程中，利用内部web应用的“忘记密码？”功能来获取电子邮件中的密码重置URL是常见的手法。这一点在本地网络中实现起来很容易，因为恶意的中间人攻击可以利用ARP欺骗等来重定向web应用发送的密码重置电子邮件给攻击者。基于这种攻击向量，并考虑到潜在的破坏性后果，有人试图将这一概念应用于互联网上的web应用中。

参考

[1] D. Kaminsky, Black ops 2008: It's the end of the cache as we know it, Black Hat USA 2, 2008.

[2] A. Herzberg und H. Schulman, „Fragmentation considered poisonous,“ in 2013 IEEE Conference on Communications and Network Security (CNS), 2013.

[3] https://developers.google.com/speed/public-dns/docs/security

[4] https://dnsflagday.net/2020/#action-dns-resolver-operators

[5] https://developers.google.com/speed/public-dns

[6] https://www.cloudflare.com/learning/dns/what-is-1.1.1.1

[7] https://www.opendns.com/cisco-opendns/

[8] https://blog.cloudflare.com/sad-dns-explained/

[9] A. Herzberg und H. Shulman, „Security of patched DNS,“ in European Symposium on Research in Computer Security, Berlin, Heidelberg, 2012.

[10] https://www.kb.cert.org/vuls/id/800113/

[11] W. Mayer, A. Zauner, M. Schmiedecker und M. Huber, „No need for black chambers: Testing TLS in the e-mail ecosystem at large,“ in 2016 11th International Conference on Availability, Reliability and Security (ARES), 2016.

[12] https://www.grc.com/dns/dns.htm

[13] https://www.dns-oarc.net/oarc/services/dnsentropy

[14] T. Longin, DNS-Schwachstellen in Webapplikationen: Eine Untersuchung der Sicherheit der DNS-Namensauflsung von Webapplikationen, 2020.

左青龙
微信扫一扫

右白虎
微信扫一扫

针对忘记密码功能的Kaminsky攻击实现账户接管

摘要

忘记密码？功能

基本原理

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

DNS攻击及其要求

无休止的DNS解析

马上注册！

146个web应用的DNS（不）安全性

DNS重置检查器（DNS Reset Checker）

问题与解答（Q&A）

参考

Vulnhub之trollcave-v1-2

Vulnhub之Os-hackNos-1

shiro框架学习

2023 USTC Hackergame WriteUp

sqli-labs通关笔记

横向移动工具开发：wmiexec-Pro

Andariel新攻击活动分析

域渗透实战之Forest

内网安全之隧道代理

CORS跨域资源共享攻击

在线咨询

微信