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

  • Comments Off on 针对忘记密码功能的Kaminsky攻击实现账户接管
  • 8 views
  • A+

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


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

wKg0C2ECBZ2AeVS7AACwqZL6TWc616.png

摘要

在分析了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”为目的地的电子邮件。其中就包括那些重置密码的邮件

下图说明了这个问题:

图1:利用DNS缓存投毒将电子邮件重定向[14]

因此,如果攻击者能够操纵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)。

图2:web应用、DNS解析器及域名“analysis.example”的ADNS间的DNS流量

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

图3:通过DNS代理的DNS流量[14]

该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.

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代理收到了这样的请求,我们就可以认为该web应用的DNS解析器支持IP分片。

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

图4:UDP源端口随机分配的散点图

而在本例中,源端口是随机选择的,因此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)。

图5:检查web应用DNS漏洞的测试流程[14]

一切都从注册开始。在本例中,我们使用邮箱地址”[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)。

图6:静态源端口分配的Web应用

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

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

图7:源端口分配递增的Web应用[14]

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

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.