Palo Alto 对近些年 DNS 历史漏洞的整理分析(下)

安全 漏洞
每隔一段时间,一个新的域名系统(DNS)漏洞被会被发现,从而使全球数十亿设备处于危险之中,DNS漏洞通常是至关重要的。

Palo Alto 对近些年 DNS 历史漏洞的整理分析(上)

新缓解措施

已实现的明显缓解措施是为每个请求随机分配事务ID(而不是使用升序计数器)。这种缓解措施使攻击更加难以执行。其实,MAX_SIZE_OF_QUERY_ID更难。事务ID为16位,因此缓解措施使攻击变得比以前困难65536倍。

这些缓解措施着实使攻击犯难了,不过道高一尺魔高一丈。 16位随机密钥虽然很大,但还不够大。让我们来算算。

  • 为了进行以下计算,我们需要记下一些数据:
  • 典型DNS响应的大小:100字节= 800位;
  • 攻击者的带宽:每秒1兆位= 1000000位
  • 合法响应返回解析器所需的时间:2秒;

有关2秒的注意事项:如今,使用现代互联网连接,即使对于未缓存的域,显然也只需不到两秒即可完成DNS请求。但是出于示例的考虑,我选择了延迟,不过我还选择了过去的网速:每秒1兆位。

有65536个可能的事务ID,我们有两秒的时间窗口发送一个响应,其中包含成功攻击的正确响应。为了计算每次攻击的成功率,我们需要计算出在实际的合法响应到达解析器之前,攻击者可以发送多少响应包。这很容易计算:带宽除以数据包大小乘以时间。

凭借1 Mbit / s的带宽,攻击者可以在一秒钟内发送多达1000000 / 800 = 1250个响应数据包,这意味着攻击者在两秒钟的窗口中可以发送2500个响应数据包。达到可能的攻击所需的尝试次数(即1 Mbit / s带宽至少50%的成功率)约为18次尝试。

完整的计算是这样的,100万是我们用1mbits的连接每秒可以发送的位数。我们将其除以800,这就是产生了每秒可以发送的响应数量。由于2秒的窗口,我们将其乘以2,然后将其除以除以2的16次方,16是事务ID字段的大小。即单次攻击的成功率为了获得成功的攻击,我们需要在x次尝试中成功进行一次尝试。我们的x次尝试称为“实验”,该实验所有可能结果的集合称为样本空间。击中样本空间中任何物体的概率显然是100%(这是方程中最外层的1)。为了获得可能的攻击的机会,我们需要获取整个样本空间并从中减去任何不能“成功地进行至少一次攻击”的内容,也就是所有x次尝试都失败的另一种说法。一次尝试的失败就是“所有的(1)减去一次尝试的成功”也就是1减去成功率。然后,我们告诉Wolfram Alpha,我们正在寻找一个x,该x的值将大于0.5(即50%)。

换句话说,只有18次尝试,带宽为1 Mbit / s的攻击者在缓解攻击后,通过此攻击可以获得的成功率大于50%,可见当年策划这场毁灭性的攻击有多容易。

更多缓解措施

回过头来看选择如此弱的缓解措施似乎有些奇怪,但重要的是要记住,完全重新发明DNS协议是根本不可能的。它可能会毁了互联网,想想所有的设备都有一个内置的解析器。他们会完全停止工作。但还有更多的事情要做。如上所示,事务ID缓解很弱。因此,这次对源端口使用了相同的缓解措施。来自DNS客户端、解析器或名称服务器的每个DNS请求都来自一个源端口,在缓解之前,该端口并未被随机分配。

源端口为16位数字,与事务ID相同,仅用于功能目的。例如,解析器可能尝试使用端口10650,如果先前请求中正在使用该端口,则它将尝试使用10651,依此类推。当然,并非所有16位都可用,因为有用于其他用途的固定端口。

源端口和事务ID一起用作DNS通信的密钥-32位密钥。请记住,因为这在攻击中将非常重要,我将进一步讨论,多出来的这16位大大降低了成功攻击的可能性。

以前,使用1mbit /s带宽时,我们的成功率为3.8%(你可以在Wolfram Alpha中查看相关计算)。使用源端口缓解措施后,如果使用与以前相同的数据,则成功攻击的可能性为0.00005821%,实现与以前相同的成功攻击所需的尝试次数为1190820。这使得攻击的成功不够可靠,实际上,源端口随机化终结了大多数DNS缓存攻击。

更高级的漏洞

到目前为止,我们主要关注单个DNS记录的缓存,www.example.com位于93.184.216.34,也称为A记录。我们在受害者自己的DNS服务器(如路由器或Kubernetes集群)上下载恶意软件,通过这种方法,我们努力进行攻击以攻击单个域。

安全研究员Dan Kaminsky在2008年发现了一种更好的方法,它比我们迄今为止在此文中讨论的方法更加有效。这个漏洞在安全界引起了轩然大波,通用执行方法与到目前为止讨论的方法非常相似,这意味着我们仍然需要猜测事务ID和源端口。成功的可能性几乎相同,但是按照卡明斯基的方法,如果我们成功了,我们可能会毁掉更多的记录。

NS记录

顾名思义,名称服务器(NS)记录是DNS记录,指示哪个DNS服务器对域具有权威性,这意味着哪个服务器包含域的实际IP地址。在前面的示例中,example.com的NS记录将是一台服务器,其中包含www.example.com,email.example.com和任何?.example.com的地址。

攻击者的目标是攻击受害者的解析器,使受害者在尝试访问www.example.com,email.example.com或任何?.example.com时,解析器会将请求转发给攻击者的名称服务器,而不是example.com名称服务器。

这样,攻击者就可以控制对example.com的每一个子域的访问,而不是像以前那样仅控制www域。

令人惊讶的是,该攻击与我们在本文中描述的攻击非常相似,但是攻击者没有尝试使用A记录来攻击解析器的缓存,而是会尝试使用NS记录来攻击缓存。

攻击者首先会为他们想要攻击的域配置一个名称服务器,没有什么可以阻止任何人配置他们自己的域名服务器。然而,它通常毫无意义,因为没有其他服务器会指向它。


整个区域攻击

然后攻击者会继续向他们想要攻击的区域的子域发出DNS请求,它必须是一个没有缓存的域,这样他们就可以确定解析器会将请求转发给根服务器。不仅如此,在我们的示例中,该域名的NS记录(example.com的权威域名服务器)也不应该被缓存。如果缓存了请求,解析器将直接将请求转发给权威名称服务器,甚至不需要将请求转发给根服务器。

攻击者使受害者的解析器将其请求转发到根服务器后,根服务器通常会以NS记录进行回复,这大致相当于说:“我不知道答案,但是您可以在那儿询问该服务器。这是它的IP地址。”

为了成功进行攻击,攻击者现在需要在发送根服务器的响应之前超越根服务器并传播包含有恶意软件的响应。这是通过发送带有所需域的NS记录的大量响应来实现的,别忘了攻击者还需要猜测交易ID(可能还有源端口)。

每个NS回复都带有一个“glue”记录,这是名称服务器的实际IP地址。如果采用其他方法,则请求服务器将不知道在哪里可以找到名称服务器。解析器接收此“glue”记录,对其进行缓存并与“glue” 记录指向的名称服务器联系,以获取所请求域的地址。

如果攻击成功,从现在开始,每一个向解析器发出的请求都将到达攻击者的域名服务器,该域名在攻击域区域(www.example.com中的example.com)下没有缓存。

应用空间

使用这种高级攻击,攻击者可以同时对大量域发起攻击。理论上,攻击者甚至可以攻击整个.com域。

尽管攻击整个.com域将是一个挑战,但在某些情况下,攻击者实际上会攻击整个缓存。具体示例如下:

1.2015年1月26日,一个黑客组织设法将访问者重定向至马来西亚航空网站,并将其重定向到另一个显示恶意内容的网站。

2.2011年11月7日,黑客设法攻击了整个互联网服务提供商的缓存,将用户重定向到安装了恶意软件的网站,然后再将他们重定向回他们要求的网站。

3.2009年12月18日,DNS劫持攻击使Twitter暂时受到约一个小时的影响。

每年都会发生数百起此类攻击。

缓解措施

没有实际的新缓解措施发生,因为使用已经使用的事务ID和端口随机化缓解措施几乎已经无法执行此攻击。但是,如果攻击者设法绕过了这些缓解措施,那么使用这种攻击而不是“常规的”单A记录攻击将会严重得多。

与前面一样,使用事务ID和端口随机化一起创建一个足够大的密钥,使攻击者难以猜测,从而起到缓解作用。

最近的漏洞

即使DNS协议被认为是安全的,开发人员也可能无法安全地实现它。

例如,存在一个普遍的误解,即随机函数应该是不可预测的,因此可以将其用于生成加密密钥。但是,这些函数并不用于密码学或安全性。不幸的是,在DNS实现的情况下经常会发生随机化函数的误用。

仅在两年前,使用用于随机化CoreDNS中事务ID的函数就发生了这种情况。开发人员选择使用math.rand,它是Golang中非加密安全的伪随机数生成器。这是一个大问题。如果攻击者可以预测交易ID,则他们绝对能够按照本文前面所述的方式攻击CoreDNS的缓存。这意味着每个使用CoreDNS作为其DNS解析器的应用程序都容易受到恶意DNS记录的攻击。换句话说,由于CoreDNS主要用于Kubernetes,因此整个集群中每个节点中的每个应用程序都容易受到此攻击。

另一个示例是几周前才发现的一项新技术,该技术使用Internet控制消息协议(ICMP)来确定服务器上哪些端口已关闭,从而揭示了哪些端口实际上是打开的。这在DNS攻击中使用,可以大大减少攻击者需要猜测的端口数量,从而降低了前面解释的端口随机缓解措施的有效性。

当然,还有一些与缓存不相关的典型漏洞,例如缓冲区溢出。 dnsmasq是许多Linux发行版和路由器中使用的常见DNS解析器,甚至在Kubernetes的早期版本中也使用过。近年来,发现dnsmasq易受众多内存漏洞的影响,这些漏洞可能导致拒绝服务(DoS),远程代码执行(RCE)等问题。

总结

本文中描述的DNS攻击如果成功,将是毁灭性的。由于有了现代的缓解措施,攻击者不太可能发动DNS攻击,除非与解析器应用程序中的任何其他漏洞结合在一起。不幸的是,这样的漏洞至今还经常被发现。

多年来,研究人员发现了可以缓解我们在本文中讨论的一些缓解漏洞的措施,例如,用户数据报协议(UDP)分段。

尽管如此,随着当今安全浏览和证书的使用,即使攻击者设法攻击某个域的DNS服务器,由于证书不匹配,浏览器的受害者很可能不会加载该页面。但是,通过使ISP的DNS解析器攻击并将请求转发到不存在的IP地址,该技术仍然可以用于巨大的DoS攻击。

Palo Alto Networks的用户可以通过多种方式免受本文所述的攻击,Palo Alto Networks下一代防火墙可以通过检测可疑DNS查询和异常DNS响应来阻止DNS攻击。与消耗或大量通信量有关的攻击可通过防火墙内置的DoS或区域保护配置文件来处理,这些保护是通过DNS安全服务覆盖DNS威胁和指示器的补充。

此外,Prisma Cloud可以通过警告过时和易受攻击的组件以及云中配置错误的应用程序来保护集群。本文描述的大多数攻击都要求破坏集群的内部网络,以便能够从内部向DNS服务器发送恶意数据包,此类漏洞几乎总是通过利用过时且配置错误的应用程序而发生。

本文翻译自:https://unit42.paloaltonetworks.com/dns-vulnerabilities/如若转载,请注明原文地址。

 

责任编辑:姜华 来源: 嘶吼网
相关推荐

2021-02-04 10:40:46

漏洞DNS缓存攻击

2018-04-12 17:44:48

2012-07-20 09:56:20

checkpointpaloalto防火墙

2017-03-06 18:43:09

2021-12-19 07:33:19

Palo Alto网络安全网络犯罪

2019-04-02 08:30:03

2015-05-29 19:01:39

Palo AltoSaaS安全性

2014-01-07 15:29:45

2013-05-14 10:41:16

Palo AltoNGFWUTM

2020-04-03 15:38:51

派拓网络CloudGenixPalo Alto N

2011-12-11 17:52:40

2018-12-17 10:02:24

网络安全趋势网络安全派拓网络

2021-09-29 10:13:16

Azurescape漏

2021-01-04 14:16:11

网络安全

2018-03-22 18:08:29

2020-02-18 17:54:36

云威胁云安全派拓网络

2014-04-18 10:58:45

2010-12-08 09:02:24

2017-06-28 15:31:18

2017-03-23 10:37:56

点赞
收藏

51CTO技术栈公众号