开发CVE-2016-5696利用程序要面临的一些问题

2016年8月,Linux爆出了编号为CVE-2016-5696的TCP连接漏洞。关于该漏洞的一般性描述,可见该篇文章。其官方Paper在这里阅读

笔者作为某国企的安全研究人员,在研读了其Paper和寻找了大量网站后,并没有发现现成的Exploit代码或者工具,于是想自己写一个来对内网安全进行确认。

关于该漏洞,其主要问题是规范RFC 5961在试图增强TCP安全性时,引入了一个新的安全问题,而Linux算是被坑,因为Linux内核组完全按照规范做了实现(BSD或者AIX为什么没有该问题,大概是并没有完全实现其要求吧)。简述一下其原理就是Linux有一个默认内核参数sysctl_tcp_challenge_ack_limit=100。而Challenge Ack是在TCP过程中对于收到异常包时给予的回应,而该内核参数的意思是每秒钟全局只能发送100个Challenge Ack包。于是因为这个全局阀值的存在,第三方就可以通过发送异常包引出Challenge Ack,从而观察其个数来猜测通讯双方的一些参数。

比如,笔者要破环TCP双方的链路,首先就要猜测出客户端的IP和端口以及服务器端的IP和端口。一般来说服务器端的IP和端口是公开的,假设我们可以通过木马或者其它手段知道客户端IP的情况下,重点就落在了猜测其客户端端口上。这时候,我们冒充客户端端口发送SYN请求到服务器,如果该端口的连接确实已经存在,则会引出服务器消耗一个Challenge Ack来提示客户端,而与此同时我们再作为第三方发送100个RESET请求到服务器,因为服务器已经消耗了一个Challenge Ack,根据全局100个共享Challenge Ack的原则,此时只能给出99个Challenge Ack,从而可以断定客户端使用着探测端口。

官方Paper在叙述其原理时,也描述了一个困难:时间同步。按照其思路,这101个包(1个假冒的SYN包,和100个探测RESET包)必须在服务器的一秒这个时间窗口内完成。如果跨越了两个时间窗口,则不会达到效果(因为一秒后该值又恢复到了100)。为了解决这个问题,Paper也提出了先同步探测方和服务器时间窗口的方法,发送多于100个RESET,确认只受到100个Challenge Ack,否则做5ms微调。

笔者仅仅实施了上述TCP探测的第一阶段,除了上述的问题,还遇到以下一些值得思考的问题:

  • 带宽影响。首先因为带宽的存在,你没办法一次性探测所有的端口范围(如果可行,那可以一次性发送65535个SYN和100个RESET来确认确实存在连接,再做二分法减小端口区间来查找)。因此你每次只能探测一个很小的范围,笔者在内网范围内,探测1000个端口,大概要1秒时间,那么探测32768-61000这个范围(客户端建立连接的端口范围),大概要20秒的时间。这对于想破坏短时连接,几乎不可行。
  • 波动和丢包。因为该漏洞原理的特殊性,所有的工作要在1s中内完成。因此,互联网上如果延时达到了100ms以上,很多事情都变得不可预测了。或许你刚同步好的时机,瞬时就被不稳定的发包速率打乱了。更甚至,如果出现了丢包,对于Challenge Ack,是不会补发的,就会出现统计错误。
  • 开发问题。笔者使用Scapy3K这个框架来做的发包控制。首先要说明的一个问题是,在Linux或者macOS上,由于内核不允许应用层建立三次握手(每次尝试握手,内核都会补发一个RESET包将连接断开),我们必须在防火墙上设置丢弃内核自动步伐的RESET包。在Linux上可以执行iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP,在macOS上,要用pfctl添加规则block drop proto tcp from any to xxx.xxx.xxx.xxx flags R/R。其次,按照规范,我发送100个序号从2-101的RESET包时,服务器都会返回ack=1的Challenge Ack回来。对于框架API来说,它无法把握回执和请求的关系,于是这些Challenge Ack都会被丢弃,程序无法退出。因此,必须使用sniff接口去抓包。但是因为sniff的延迟性,大概需要个3秒才能全部抓到。再加上程序循环处理等因此,因此这个过程大概要4秒的样子。之后同步的时间大概早就错乱了。

笔者只是完成了第一阶段探测代码,但是因为第二,第三个阶段的探测原理上差不多,也会遇到同样的问题。综上所述,笔者很怀疑是否可以在一个普通网络环境下做出一个稳定的Exploit代码。或许,这个CVE就像POODLE一样,是一个理论上确实存在,但是实际上很难探测的CVE。希望有安全人员继续努力。我的代码在这里

转载请注明来源 https://story.tonylee.name/2016/09/06/kai-fa-cve-2016-5696li-yong-cheng-xu-yao-mian-lin-de-yi-xie-wen-ti/