C114通信网  |  通信人家园

信息安全
2017/10/24 13:12

全体路由器闻风丧胆的WPA2漏洞 支付密码们还有安全可言吗?

爱活网  

作为一个只喜欢纸上谈兵的家伙,最近曝出 WPA/WPA2 协议存在漏洞(可被 KRACK 密钥重装攻击)的时候,我还是有那么点小激动的——毕竟这么多年了,被无数人验证安全性有保证的 WPA2,竟然此刻也被曝出了漏洞,这不是人生一大乐事吗?而且,或许非安全行业的同人并不知道,协议被曝出漏洞也算得上是难得。

三年前,我们曾经写过一篇蹭邻居家 WiFi 网的文章,作为“黑客入门(一)”系列的开篇之后就再也没有下文了。这篇文章现在看来虽有诸多值得商榷之处,不过却很明确地提到,无线网络的数据传输就在空气中进行,遭遇数据劫持的情况比有线肯定要严重得多。想想,我们在星巴克上个 WiFi,有个黑客和你一起坐在店里,从空气中劫持你的数据——他知道你在做什么,你下单买个东西,他连银行卡密码都知道了,这不是很恐怖么?所以说无线传输最基本的诉求就是数据加密,早年 WEP 加密协议被曝出严重漏洞后,如今最常见的 WiFi 加密协议就是 WPA/WPA2 了,看看你家路由器的 WiFi 设置项有没有这玩意儿。

所以在 WEP 加密年代,华强北销售的“破解王”们才能如此猖獗地让你蹭邻居家的网,因为由于加密机制缺陷,那时候的 WiFi 密码破解太简单了。现如今 WPA/WPA2 也曝出漏洞了,我们是不是该写篇如何蹭邻居家 WiFi 下篇了?咳…别这么不严肃,WPA2 协议本身曝出漏洞,听来可以是震惊全球的大事,因为现如今大量接入 WiFi 的设备都在用这货,不管你是高端大气上档次的 Netgear,还是低调奢华有内涵的小米路由器。如果我们坐在家里用手机连 WiFi,刷个淘宝,付账的功夫,支付密码就因为 WPA2 协议漏洞的问题被盗了,又岂止是被邻居蹭网如此单纯的事?更何况如果是企业网络呢?

不过可能事情并没有这么严重,至少就这次的漏洞来看,上面说的这些可能都不会发生。

这是协议层面的一连串漏洞

做安全生意的人,以及安全研究人员都喜欢将某个漏洞或缺陷的危害无限放大,并告诉你:我最近发现了一个超级牛逼的漏洞,可能影响全人类。别听他们的,随便一个 Apache 低危漏洞,在他们那里都恨不得吹成很快人类就要毁灭的国际大事。不过这次来自鲁汶大学(KU Lenven)imec-DistriNet 研究团队的两名研究人员 Mathy Vanhoef 和 Frank Piessens 却实实在在发现了属于协议层面的漏洞,听起来很高级啊。

协议漏洞是什么意思?平常我们听到的不少漏洞,比如 Windows、Linux 被曝出漏洞,都是可以由厂商修复的;其中有一些比较严重的漏洞,比如说 TCP 连接利用漏洞(CVE-2016-5696)[1],还有各种 3G 网络可被窃听,数据可被解密的漏洞,虽然和协议似乎还挺有关系,但大部分都是具体实施层面(implemention)的漏洞。即这些漏洞都算不上是协议本身的漏洞,而是某些厂商,在遵循该协议具体应用到实际软件或硬件产品的过程中,产生的漏洞。

而且就当代的实际情况来看,标准设立都越来越注重安全性,这和早年很不一样。比如 2G 通讯时代,GSM 的数据加密算法 A5 很多年前就被曝出安全问题[2];加上 2G 身份认证机制缺陷,伪基站、电信诈骗都显得相当稀松平常。到 3G/4G 时代,尤其 LTE 标准的安全性让大部分黑客都知难而退,选择主攻运营商或终端设备实施层面的漏洞。

实施层面的漏洞,绝大部分是可以通过打补丁来修复的(虽然对某些领域而言,情况可能会比较复杂,比如医疗领域的 IoT 设备,修复漏洞的成本就相当高)。而协议层面的漏洞是怎样一副面貌呢?好比 GSM A5 加密本身的安全问题,以 GSM 通讯在世界上的实施广度,这样的安全问题是几乎没有机会得到解决的。

再比如前两个月,趋势科技的研究人员发现 CAN 协议漏洞 [3]。CAN 是汽车网络各部分组件进行通讯的协议,问题出在 CAN 标准的信息系统中,设备读取 CAN 信息的特定值时会生成错误消息——利用这些错误消息的处理流程,攻击者就能让系统过载,让汽车组件进入 Bus Off 状态。比如说可以因此关闭安全气囊之类的关键系统。这样的漏洞是无法通过固件升级修复的,需要修改 CAN 标准才行——就已经生产的汽车而言,几乎是个无解的存在。

而这次打破 WPA2 安全性的 KRACK 攻击,涉及到的是一连串漏洞,CVE 漏洞编号 CVE-2017-13077/13078/13079……13088,几乎都可以认为是协议层面的漏洞。不过这些漏洞并非组合起来的一条攻击链,而是不同密钥方案中 4 次握手的密钥重装漏洞(或者接受请求重传漏洞)。这么说来,是协议漏洞,且既然这个星球上这么多人都在用 WiFi,那人类安全性岂不全面完蛋了?你家的路由器,你的苹果手机,你的 ThinkPad 笔记本,还有你的银行账号…问题是,以 CVE-2017-13077 漏洞为例,其基本情况如下:

这个漏洞在 NVD 漏洞库的危害程度定义为“Medium”(危害程度有 Low、Medium、High 和 Critical 四档),且攻击难度略“High”(后续可能会有调整)。What?不是说好了协议漏洞都很牛掰吗?

这究竟是个什么样的漏洞,可以用来蹭网吗?

华强北估计很关注本地漏洞 PoC,毕竟涉及到新一波的“破解王”生意啊。不过很遗憾地说,这次的 KRACK 攻击是无法破解出采用 WPA2 加密无线网络的 WiFi 密码的,所以蹭网想都别想了;家里的 WiFi 密码什么的,也不用改了。有一定网络工程基础的同学可能会觉得奇怪,既然连 WiFi 密码都破解不出来,攻击又如何窃听用户的无线传输数据呢?因为无线传输数据都是经过加密的,攻击者拦截到之后就是一堆乱码而已,解密理论上需要 WiFi 密码。在 WiFi 密码不可知的情况下,这些数据也能破解出来?

在说漏洞之前还是照例说些背景知识。客户端(比如你的手机)接入 WiFi 网络的时候,WiFi 热点(下文称为 AP)会首先对你进行身份认证,对我们普通用户而言,身份认证最直接的表现就是需要我们输入 WiFi 密码。在随后的过程中,对于 WPA 而言,客户端需要和 AP 首先进行所谓的“4 次握手”,双方建立起关系才能继续互通消息。4 次握手完成后,你的手机才能上网。客户端与 AP 四次握手的方式如下图所示(4-way handshake 阶段):

说简单点,就是客户端和 AP 之间来回发 4 则消息(图中的 Msg1、2、3、4,上图的 r 是 replay 计数器)。四次握手的过程中,双方会协商一个 PTK 会话密钥(注意这个 PTK,这里我们不讨论 GTK 群组密钥的情况)。客户端在接收到 Msg3 之后,就会安装双方协商好的 PTK 密钥(并给 AP 回传 Msg4)——如上所述,此后,客户端和 AP 之间的普通数据传输就会利用密钥来加密,这才保证了空气中数据交流的安全性。

但由于无线网络的不稳定性,Msg3 在传输过程中可能会丢失。考虑到这一点,802.11i 标准要求,如果 AP 发出 Msg3 之后,没有收到客户端的响应,就会认为 Msg3 可能没送到,于是就会再次发出 Msg3(或 Msg1)。这样一来,AP 可能多次发出 Msg3,客户端也有可能多次收到 Msg3。客户端每次收到 Msg3 都会重新安装一次 PTK 密钥,重置增量传输包数(随机数)和接收 replay 计数器(客户端必须处理再度收到的 Msg1 或 Msg3 是 802.11r 规定的)。

问题的症结就在这里,攻击者可以在此扮演中间人的角色,恶意拦截并阻止 AP 收到 Msg4(如下图中间列所示)。这样一来,AP 一直收不到客户端发出的 Msg4,AP 就会给客户端反复发送 Msg3。原本客户端在收到 Msg3 之后安装密钥,并传出 Msg4。此后,客户端就认为四次握手已经结束了,所以开始用协商好的密钥进行常规数据通讯。但这个时候再度收到 Msg3,唯有再度重装相同 PTK 密钥,重置随机数。

加入中间人角色,此图仅考虑客户端在安装 PTK 密钥后,仍接收明文 Msg3 的情况

说这么多,感觉挺装(kan)逼(bu)的(dong),其实这里的核心在于客户端反复收到 Msg3,并反复重装 PTK 密钥。这个过程会重置相应数据保密性协议的随机数——记住这个随机数。攻击者因此也就可以控制该随机数重复使用,在掌握一定已知条件(比如你事先就知道某个数据包本身的内容,根据 paper 的描述,这个已知条件并不难造)的情况下,就可以解密,甚至伪造数据包了(伪造数据包的方法还涉及到解密 TCP SYN 包,攻击者需要获取某个连接的 TCP 序列号,并劫持 TCP 连接)。控制了这个随机数有什么价值?为什么就能解密数据包?如果你关心这个问题,请继续往下看。

在此之前,我们来看个更有趣的发现:有个东西叫 wpa_supplicant,这是 Linux 系统中普遍使用的一个 Wi-Fi 客户端。在研究人员研究 KRACK 攻击的过程中发现,wpa_supplicant 2.4/2.5 版本在收到重新传送的 Msg3 之后,会安装“全零(all-zero)”加密密钥(TK,注意这个 TK 密钥,TK 密钥是真正用于加密常规传输的数据的)。这太不可思议了,已经算是非常大型的加密漏洞——但听起来像是实施层面的漏洞。然而这种方案似乎也是遵循 802.11 标准指导的结果,“802.11 标准间接地建议,在 TK 密钥安装后就将其从内存中清除”(实施层面的理解错误?)。wpa_supplicant 2.6 虽然已经尝试修复该问题(仅在首次收到 Msg3 后才安装 TK 密钥),但由于考虑得仍然不够周到,所以攻击者仍然有办法迫使客户端安装全零密钥。

全零加密密钥漏洞可以用来干嘛?在加密密钥已知的情况下,解密数据还是难事吗?不过接下来才是最关键的,Android 系统就采用 wpa_supplicant(修改版):Android 6.0 及更早版本就存在这个“全零加密密钥漏洞”。实际上,Chromium 也存在此漏洞(还有 Android Wear 2.0)。对普通终端用户而言,这个意外发现的漏洞应该是目前 KRACK 攻击最大的影响所在,Android 才是本次漏洞的最大受害者(不知道国内早前是否有手机制造商修改了 Android 原生的 wpa_supplicant)。

在这部分的最后,装逼又要开始了,咱来聊聊上面提到控制 Msg3 重传来重复使用随机数这件事究竟有什么价值。如果你对这部分的原理细节不感兴趣,那么请直接跳过到下一小标题。

WPA 的数据保密协议主要有 TKIP、(AES-)CCMP、GCMP。这三种协议都采用流密码来加密数据帧,随机数的重复使用基本就意味着密钥流的重复使用,最终就可以进行数据包的解密。这里还需要对更多 WPA2 涉及的密钥做解释。

对任何加密协议而言,密钥都不可能只有一个。首先,在四次握手的过程中,握手数据就需要加密,所以握手期间最先有了 PMK 密钥(PMK 密钥源于共享 WiFi 密码)。如上所述,握手阶段会协商出 PTK 密钥(即所谓的会话密钥)。这个 PTK 密钥是怎么来的呢?它的来源包含了 PMK 密钥、ANonce(AP 随机数)、SNonce(客户端随机数),以及 AP 和客户端的 MAC 地址。PTK 密钥生成之后还会进行切分,切分成 KCK(密钥确认密钥)、KEK(密钥加密密钥)和 TK 密钥。KCK 与 KEK 密钥是专门用来保护握手信息的,TK 密钥则如前文所述用于对普通数据进行加密。

这里以 TKIP 数据保密协议为例(虽然这个协议已经逐渐被抛弃),如果我们选择 TKIP 为数据保密协议。承接上一段,随后 TK 密钥部分还会再行切分,切分为 1 个 128 位加密密钥,和两个 64 位 MIC 密钥。其中一个 MIC 密钥用于 AP 到客户端的通讯加密,而另一个密钥则用于客户端到 AP 的通讯加密。加密采用 RC4 算法,每个数据包的密钥,都混合了 128 位加密密钥、发送方 MAC 地址和一个增量 48 位随机数。这里的随机数在传出一帧之后就会增加,作为接收方的 replay 计数器——在安装 TK 时会重置为 1。

802.11 标准下的 4 次握手状态机(State Machine)

又是好枯燥的几段话啊,总之就是随机数在其中扮演重要作用。我们的目标是破解 MIC 密钥(就是用于双方通讯加密的密钥)。对 TKIP 而言,获得 MIC 密钥大致上是这么做的:攻击过程首先利用随机数的重复使用,来解密一个完整的 TKIP 包,这个包包含了 MIC 字段。由于此间消息可靠性采用 Michael 算法,利用 Michael 算法的弱点(给定明文帧和解密 MIC 值的情况下就能)获得 MIC 密钥。

这也基本解释了为什么,KRACK 攻击可以解密数据包,监听无线传输,但却无法获得 WiFi 密码(也无法还原完整的 PTK 密钥),也就没有办法蹭网的原因。不过我们在此探讨得非常理论,整个过程还面临很多实际问题,比如说攻击者这个“中间人”的位置究竟该怎么建(建立一个恶意 AP,在真正的 AP 和客户端之间转发数据包);还有更麻烦的,比如在某些具体实施方案中,客户端如果在一次收到 Msg3 之后安装 PTK 密钥,就只接受加密信息了,忽略 AP 重新传出的未加密 Msg3,这怎么办?

实际上整个攻击过程面临的实际问题还非常多,有兴趣的可以去仔细研究下原 paper[4]。

为什么说这个漏洞危害程度有限?

在实际攻击中,有两个例子很有趣,即 iOS 和 Windows 系统,它们不接受 Msg3 信息的重传(如下图第二列 Re.Msg3 所示)。这样一来,上面提到的 KRACK 攻击岂不是无效了?因为不接受 Msg3 重传,也就几乎破坏了 KRACK 攻击的立足点。不过这篇 paper 依旧花篇幅介绍了 802.11R Fast BSS Transistion(FT) 握手过程中,针对 AP 的 KRACK 攻击,也能令 iOS 和 Windows 投降(802.11R FT 是为了减少客户端从相同网络下的一个 AP 漫游到另一个 AP 的切换时间而设的)。这么看来,就针对 iOS 和 Windows 的攻击,KRACK 还是比较受限的(不过似乎也受到 GTK 群组密钥握手攻击的影响)。

等一等,不是说所有 WiFi 设备都受影响吗?怎么还会存在不接受 Msg3 重传的奇葩?不是 802.11 规定的吗?的确,iOS 和 Windows 这部分的具体实施方案违反了 802.11 标准。从这个角度来看,在某些更细致的实施方案中,违反标准的存在也并不奇怪。

针对具体实施方案差异导致的不同后果,除了 iOS 这类特例,还有个例子。在进行 KRACK 攻击的过程中,攻击者作为中间人,致使 AP 收不到客户端发出的 Msg4。在攻击阶段性完成后,攻击者仍然需要将 Msg4 再转发给 AP(因为要进行后续通讯信息的窃听,就需要完成四次握手,回看本文的第二张表格,阶段 4),从我们的常识来判断,这个转发过程其实是会遇到困难的,因为转发的 replay 计数器可能不是最新的。

但 802.11 标准中提到,AP 可以接受四次握手过程中的任意 replay 计数,不需要是最新的(此外,802.11 标准中还提到,初始四次握手的 Msg4 需要以明文发送,但几乎所有客户端都会采用加密方式发送)。上面这张表格的第二列,列出了不同产品在 replay 技术检查方面是否要求最新 replay 计数。

这些例子其实是为了说明,针对 802.11i 的具体实施方案存在各种差别。所以我们才说,在这次的安全事件中,Android 在消费用户中显然更容易被攻击。但也因为这些实施方案差别,不同产品应对 KRACK 攻击时的耐受性各不相同,如 macOS 的攻击条件就相对苛刻。也因为实施方案差异,各厂商都以很快的速度推出了自己的补丁,修复了可能被 KRACK 攻击的情况。

针对 KRACK 攻击的缓解方案,研究人员的建议主要在于,数据保密性协议的实施方案,要求检查密钥是否已经安装——如果已经安装则不再重置相应随机数和 replay 计数器,密钥仅安装一次。所以即便是协议漏洞,这次的安全问题不算太大。

值得一提的是,漏洞的存在性是一回事,攻击难度又是另外一回事。比如信息安全领域具有奇幻色彩的边信道(side-channel)攻击,在实验室中可以不计成本的方式,用电子探针获取电、磁、热特性实施攻击,但这种攻击方式很多情况下的成本之高,是一般黑客根本无力承担的;再比如理论上一直都存在针对存储介质的比特位翻转攻击,在普通人看来都只能是天方夜谭。

KRACK 攻击在解决安全研究者提到的诸多实际操作问题后,在“解密数据”和“窃取敏感信息”的问题上,还面临很大的挑战。比如说现如今大量 web 和 App 连接采用 HTTPS 加密的方式,其加密的层级和 WPA/WPA2 不一样,也就是说即便解开了 WPA2 加密,还有另外层级的加密等着攻击者去解——即便的确有绕过 HTTPS 实施方案的先例,这就又得费一番功夫了,更何况如果加上 VPN 的加持呢…要说窃取支付宝密码这件事,仅靠 KRACK 攻击,恐怕还差得非常远。

而在更具体的攻击过程中,研究人员还提到,利用其攻击 PoC 脚本的可靠性是存在空间上的限制的:

“如果受害者离真实网络(也就是 AP)非常近,那么脚本可能会不起作用,因为受害人此时直接和真实网络进行通讯。”

毕竟研究人员提出,“中间人攻击”的方案主要还是依托于建立一个恶意 AP 来欺骗受害者连接的。敢情到要攻击你家 WiFi,还得首先闯进你家去才行啊。在此可考虑的攻击场景:你的某个朋友最近行为举止怪异,穿着打扮黑暗,印堂发黑,经常在屏幕前码代码,某一天他去你家,口袋里还装个古怪的小玩意儿,也不告诉你要干嘛——别怀疑,他正在进行 KRACK 攻击。作为一个纸上谈兵的人,本文纯粹为喜好探寻原理的人准备。

不过最后还是要说:当代网络攻击通常都是以组合拳的方式进行的,KRACK 即便对攻击条件有一定的要求,却也可以作为全套攻击方案中的一个环节——作为攻击链中的一部分存在后,还可以产生更大的危害。不过其存在价值在我看来,可能更偏重于针对明确目标的窃听攻击,以窃取信息为目的(比如针对企业);或配合其他攻击产生危害。一个实际可行的攻击场景:比如说广播模式下的 NTP(网络时间协议),在此模式下,客户端初始化后监听广播 NTP 包来同步时钟。KRACK 攻击在此可以让客户端的时间凝固(对 NTP 广播帧进行 replay),这样一来可进一步对 TLS 证书、DNSSEC、Kerberos 认证、比特币等造成影响。

无论如何,为安全考虑,任何实际存在的安全问题,而且是已经被证明行之有效的攻击方案,都应该得到重视。所以苹果、谷歌、微软之类的厂商都以较快的速度为终端产品推出了修复 KRACK 攻击的补丁,所有用户都应该第一时间打上补丁——至于 AP 端,家中的无线路由器、WiFi 放大器等 AP 设备也都应该第一时间安装厂商所推的新版固件,比如 360 似乎在漏洞出现的 2 天内就为路由器和扩展器产品推了专门的固件补丁。另外,老生常谈的那几样,不明来源的 WiFi 不要连接,使用公共 WiFi 时也需要谨慎。

据说 WiFi 联盟对此已经有了测试计划。他们打算在其全球认证实验室网络中对漏洞进行测试,为 WiFi 联盟成员提供漏洞检测工具,向设备制造商通告漏洞细节,告知用户安装最新安全补丁的重要性。有趣的是,这份 paper 的作者早在 7 月份将漏洞上报给 OpenBSD,OpenBSD 最早发布补丁,而且是在所有人都不知道的情况下默默发布的 [5]。

WPA2 有漏洞并不可怕,数字世界的任何位置理论上都存在缺陷。判断某个系统安全与否的标准在于:攻击某资产,所需耗费的成本,已经超过资产本身的价值;或攻击不具有简单可复制性(如大部分攻击都是首次攻击投入成本大,后续攻击成本越来越小或几乎零成本,如 iOS 越狱),我们就可以认为这个系统是安全的。

参考来源:

[1]Linux 设备 TCP 连接的有趣漏洞:传说中的 Off-Path 劫持, http://www.freebuf.com/column/133862.html

[2]Hacking GSM A5 crypto algorithm by using commodity hardware, http://securityaffairs.co/wordpress/52666/hacking/gsm-crypto-hacking.html

[3]The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard, http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/

[4]Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://papers.mathyvanhoef.com/ccs2017.pdf

[5]OpenBSD Errata: August 30th, 2017, https://marc.info/?l=openbsd-announce&m=150410604407872&w=2

给作者点赞
0 VS 0
写得不太好

免责声明:本文仅代表作者个人观点,与C114通信网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。

热门文章
    最新视频
    为您推荐

      C114简介 | 联系我们 | 网站地图 | 手机版

      Copyright©1999-2025 c114 All Rights Reserved | 沪ICP备12002291号

      C114 通信网 版权所有 举报电话:021-54451141