关闭

nginx解析漏洞允许缓存投毒攻击

589人阅读 评论(0) 收藏 举报
分类:

http://p2.qhimg.com/t01945e41c136169d9b.jpg

http://p7.qhimg.com/t01945e41c136169d9b.jpg

许多nginx用户会使用Google 公共 DNS,OpenDNS 或ISP 的解析器解析器等解析程序指令来配置 nginx,但是这当中存在很大的风险,唯一安全的选择是在本地主机上运行一个解析器。

  我发现,不仅 nginx 的存根 (stub) 解析器会生成非随机的或可预见的 DNS txids,连每个 nginx 的工作进程都会在每个 DNS 查询中使用相同的 UDP 源端口。

  只要使用一个简短的脚本就可以在Linux (GNU C 库) 中预测Nginx 的 txids。

  这些缺陷允许恶意攻击者发送欺骗性的 DNS 回复去感染解析程序缓存,导致 nginx 代理 HTTP 会向任何攻击者指定的上游服务器发送请求,从而访问到浏览器的恶意内容。

  奇怪的是 nginx 开发人员并不认为这存在任何安全问题。在我向 security-@nginx.org 报告之后,他们只修补一部分问题并且拒绝修补其他问题,也没有发布安全咨询。所以我觉得必须要公开我的调查结果,告知nginx 用户他们所面临的潜在风险 。


  细节



  Nginx 生成 DNS txids所使用的是用于在 Linux/Unix 上random() 和在 Windows 上 rand () 的宏ngx_random() 。

  问题 1:

在 Windows 上,nginx 从来没有通过 srand()发送种子 PRNG ,所以 C盘会默认为 1,导致 txids 总是遵循同样的次序,而不是随机种子︰ 41,18467,6334、 26500,19169,15724......

  问题 2:

在 Linux 上,对于random() 的依靠使得 txids 变得可预测,因为特定配置下的 nginx 会将random() 值泄漏给远程用户:当ngx_mail_core_module 启用时通过 SMTP/POP3/IMAP CRAM-MD5盐功能,或有时会通过标头暴露客户的$request_id 变量。

  问题 3;

在所有平台上,nginx的每个工作进程都允许 OS 选择随机的 UDP 源端口发送 DNS 查询。工作进程会重用遍又一遍的在同一端口发送所有查询,直到 nginx 重新启动。既然猜测 txid是可行的,攻击者只需要蛮力进入源端口就可以感染 nginx 的解析程序缓存。OS TCP/IP 堆栈通常会从Linux中的一系列的 28232 个端口和Windows 上的16384个 端口中选择。攻击者可以一次性确认正确端口。随后,他就可以使用一个假DNS 答复进行攻击,因为端口已知,txid也是可预测的。


攻击场景



  首先,成功感染 nginx 的 DNS 缓存的要求是,攻击者需要︰

•知道nginx 尝试解析的主机名 ;

•知道配置nginx 所使用的解析器 。

场景 1

  此方案演示如何利用问题 1。

  使用下面的nginx.conf 在 Windows 上运行Nginx︰

1
2
3
4
5
6
7
8
9
10
11
12
# nginx.conf
http {
  server {
    listen       9980;
    server_name  frontend.example.com;
    resolver     8.8.8.8;
    location / {
      set $target http://backend.example.com;
      proxy_pass $target;
    }
  }
}


  如果 Nginx 实例相对繁忙 (例如说每两次或更多次才能处理一个请求,以保持 nginx 每次在缓存项过期后不断解决后端名称问题),那么︰

1.攻击者可以看到后端的主机名,并且能看见1 小时之内的TTL 。

2.现在他可以确定,当启动 nginx 代理第一次请求 t = 0时,它会用txid = 41发出一个 DNS 查询等。这是因为,正如我刚才所解释的那样,在 Windows 中nginx 未能种子 PRNG,因此始终会生成相同的序列。

3.攻击者确定 nginx 什么时候会启动,也知道它会用哪个txid来发送下一个 DNS 查询。

4.攻击者等待后端的 IP 地址在nginx 的缓存中过期。例如这可能在 t = 100 h发生,那么攻击者就会知道 nginx 将使用随机值序列中第 101随机值由 rand () 返回。当它再缓存中过期时,nginx可能需要几百毫秒查询 8.8.8.8才能作出答复。在同一时间攻击者可以随机地将多个诈骗 DNS 回复与预测 txid 发送到不同的 UDP 端口,在这段时间里他能够发送 1000次诈骗答复。

5.第一次的中毒尝试将可能失败,因为 Windows 从一系列的 16384 端口 (49152 – 65535)中只选择一个源端口。所以如果他失败了,攻击者下次尝试会再从 nginx 的缓存过期后端的 IP 地址进行无限量的尝试。

6.Nginx 将然后代理攻击者服务器的所有请求,直到 TTL 过期。下一次感染尝试就会简单得多,因为此时攻击者已经知道哪一组端口是无效的。

  截至 2016 年 8 月 24 日,这种攻击在发布到目前为止的所有 nginx 版本上都有效。我的报告公布后,开发人员在 2016 年 8 月 4 日进行了修补,因此即将发布的1.11.4版本应该会包括此修复程序。然而 nginx 开发人员认为这不是一个安全漏洞,尽管一切都那么显而易见。

场景2

  此方案演示如何利用问题 2。

  它需要使用CRAM-MD5验证启用 (不是默认)将nginx 配置为 SMTP、 POP3 或 IMAP 这样它才能将$request_id 报告给客户端。

  我选择在这里展示使用 SMTP 的终结点在 Linux/Unix 上运行Nginx的过程︰

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# nginx.conf
http {
  server {
    listen       9980;
    server_name  frontend.example.com;
    resolver     8.8.8.8;
    location / {
      set $target http://backend.example.com;
      proxy_pass $target;
    }
  }
}
mail {
  server_name    my-name;
  auth_http      http://localhost/;
  smtp_auth      cram-md5;
  server {
    listen   1025;
    protocol smtp;
  }
}


  使用此配置,nginx会通过CRAM-MD5 盐泄漏用于 SMTP/POP3/IMAP 认证的 random() 值︰

1
2
3
4
5
6
7
8
9
10
$ telnet localhost 1025
[...]
220 my-name ESMTP ready
HELO foo
250 my-name
AUTH CRAM-MD5
334 PDE2OTM3OTc3NS4xNDcxOTgyODMxQG15LW5hbWU+
  
$ echo PDE2OTM3OTc3NS4xNDcxOTgyODMxQG15LW5hbWU+ | openssl base64 -d
<169379775.1471982831@my-name>


  169379775 < 169379775.1471982831@my-name > 中的整数就是由 random() 返回的值。GNU C 库的这一功能允许攻击者预测未来的返回值。我写了示范 Python 脚本script cram-md5-predict-random.py连接到 nginx 的 SMTP 终结点︰

1
2
3
4
5
$ ./cram-md5-predict-random.py 
Connecting to localhost:1025...
[...]
Next random() value will be: 693589235 (75% prob.) or 693589236 (25% prob.)
Next DNS txid will be: 21747 or 21748


  接下来我们可以通过运行 nginx 试图解决 backend.example.com 数据包时在浏览器中请求 http://localhost:9980 验证此 txid 预测。

1
2
3
4
$ tcpdump -n "port 53 and host 8.8.8.8"
[...]
15:15:31.419931 IP 10.110.0.117.44335 > 8.8.8.8.53: 21747+ A? backend.example.com. (37)
15:15:31.527168 IP 8.8.8.8.53 > 10.110.0.117.44335: 21747 NXDomain 0/1/0 (94)


 攻击者感染 nginx 的 DNS 缓存会采取的步骤︰

1.攻击者会运行runs cram-md5-predict-random.py来预测下一个 txid 值 (其中有 75%的机会是正确的)。

2.然后他要么采用强力方法开始不断发送欺骗的 DNS 回复到nginx 的不同的 UDP 端口;最终等到 nginx 的缓存后端 IP 地址过期,nginx 尝试重新解析它并将接受欺骗答复发送到正确的端口。或者攻击者可能只有当 nginx 试图重新解析后端主机名时才发送欺骗的 DNS 回复以节省网络带宽。

3.当 nginx 重新解析主机名时,它可能需要几百毫秒来接收合法的答复。在这段时间,攻击者就可以发送欺骗性的 DNS 回复。

4.第一次的感染尝试可能会失败,因为默认情况下的 Linux 会从一系列28232个端口中选择端口 (net.ipv4.ip_local_port_range = 32768 60999)。如果失败了,攻击者下次会尝试再从 nginx 的缓存过期后端的 IP 地址进行无限量的尝试。

5.Nginx 然后就会代理攻击者服务器的所有请求,直到 TTL 过期。


修复方案︰



1.放弃使用random()/rand() 作为 PRNG 生成 txids。改为使用getrandom(2的系统调用、/ dev/urandom 或者 CryptGenRandom() 的熵。

2.随机化 UDP 源端口的每个 DNS 查询。

  但开发商拒绝考虑这些问题中的任何一个安全问题,也没有发表安全咨询,所以漏洞还是没有得到解决︰他们还在继续使用 random()/rand(),并且他们仍然没有随机化每个查询的源端口。

受影响 nginx 版本

  截至 2016 年 8 月 24 日,所有曾经附带解析器的 nginx 版本都会受到影响:

•0.6.18版本以上,包括0.6.39版本

•0.7版本以上,包括0.7.69版本

•0.8版本以上,包括0.8.55版本

•1.0 版本以上,包括1.0.15版本

•1.2 版本以上,包括1.2.9版本

•1.4 版本以上,包括1.4.7版本

•1.6 版本以上,包括1.6.3版本

•1.8 版本以上,包括1.8.1版本

•1.10 版本以上,包括1.10.1版本

•1.11版本以上,包括1.11.3版本

  即将发布的如 1.11.4 版本应该会包含部分问题的修复程序,但是绝不是全部。

原文地址:

http://blog.zorinaq.com/nginx-resolver-vulns/

本文转载自 zorinaq
原文链接:http://blog.zorinaq.com/nginx-resolver-vulns/

0
0
查看评论

WiFi流量劫持—— JS脚本缓存投毒

在上一篇《WiFi流量劫持—— 浏览任意页面即可中毒》构思了一个时光机原型,让我们的脚本通过HTTP缓存机制,在未来的某个时刻被执行,因此我们可以实现超大范围的入侵了。   基于此原理,我们用NodeJS来实现一个简单的样例。得益于node强大的IO管理,以及各种封装好的网络模块,我们可以很容易实现...
  • yongxiaokang1
  • yongxiaokang1
  • 2015-02-05 13:41
  • 831

Nginx最新解析漏洞

昨晚黑锅在微博上发了老外爆的Nginx漏洞,开始并没几个人关注,小我马上架环境测试验证了,我人品好随手在网上试了两个网站也验证了这个漏洞,于是乎马上就在微博上传开了。 这个漏洞是7月20日发的,老外做了非常详细的分析,大家可以深入参考: 这里我就说说关于这个漏洞的几个隐蔽点和关键点: 一.老肉...
  • yangjiehuan
  • yangjiehuan
  • 2015-06-10 14:23
  • 8549

HTTP Response Splitting 攻击

翻译自https://www-304.ibm.com/support/docview.wss?uid=swg27019020#Conclusions 摘要:     国外将其归结为一种新的WEB应用漏洞攻击技术,可以构造跨站、缓存投毒和劫持敏感用户信息等。攻击是由于...
  • cqf539
  • cqf539
  • 2011-08-23 19:04
  • 1156

文件解析漏洞总结-Nginx

与Apache相比,Nginx算是后起之秀,但大有赶超之势。百度一番,又谷歌一番,最终只找到了三个已公开的、关于Nginx的解析漏洞,记录如下
  • wn314
  • wn314
  • 2017-08-18 22:01
  • 2741

Nginx工作原理和优化、漏洞。

1.  Nginx的模块与工作原理 Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置...
  • hguisu
  • hguisu
  • 2013-05-16 11:04
  • 122760

常见服务器解析漏洞(IIS,nginx,apache)

一.IIS6.0   目录解析:/xx.asp/xx.jpg    xx.jpg 可替换为任意文本文件(e.g. xx.txt),文本内容为后门代码   IIS6.0 会将 xx.jpg 解析为 asp 文件。 后缀解析:/xx....
  • xing_anksh
  • xing_anksh
  • 2013-09-30 14:18
  • 2885

解析漏洞总结

一、IIS 5.x/6.0解析漏洞 IIS 6.0解析利用方法有两种 1.目录解析 /xx.asp/xx.jpg 2.文件解析 sp.asp;.jpg 第一种,在网站下建立文件夹的名字为 .asp、.asa 的文件夹,其目录内的任何扩展名的文件都被IIS当作asp文件来解析并执行。...
  • whatday
  • whatday
  • 2017-01-31 07:16
  • 1981

nginx解析漏洞允许缓存投毒攻击

许多nginx用户会使用Google 公共 DNS,OpenDNS 或ISP 的解析器解析器等解析程序指令来配置 nginx,但是这当中存在很大的风险,唯一安全的选择是在本地主机上运行一个解析器。   我发现,不仅 nginx 的存根 (stub) 解析器会生成非随机的或可...
  • qq_27446553
  • qq_27446553
  • 2016-08-31 00:57
  • 589

centos6.5安装Nginx-nginx-1.10.3.tar.gz

第一次在centos上装nginx,期间遇到好多问题,同时也被nginx的大小给震惊,linux版的nginx太小了,apache2比nginx大多了,废话不多说了,下边进入主题, 1:安装Nginx依赖包    yum install  pcre pcre-d...
  • laiyijian
  • laiyijian
  • 2017-03-15 18:30
  • 2718

python黑帽子:利用scapy进行arp缓存投毒

from scapy.all import * import os import sys import threading import signal #interface = 'en1' target_ip = '192.168.43.141' gateway_...
  • qq_38619030
  • qq_38619030
  • 2017-08-05 22:45
  • 317
    个人资料
    • 访问:810000次
    • 积分:8250
    • 等级:
    • 排名:第2947名
    • 原创:23篇
    • 转载:844篇
    • 译文:2篇
    • 评论:26条
    最新评论