苹果设备被曝存在PEAP认证漏洞,研究人员对官方修复方案存疑

缅甸皇家娱乐在线

Apple设备暴露于PEAP身份验证漏洞,研究人员怀疑官方修复

雷锋网5月18日发现,Apple设备在PEAP身份验证方面存在缺陷,而攻击者可以强制Apple设备访问恶意热点。

研究人员表示,即使身份验证服务器(RADIUS)无法证明密码的真实性,该错误仍然允许攻击者强制任何Apple设备(iOS,macOS或tvOS)与恶意接入点关联。

以下是雷锋报告内容的完成情况。

第一次遇到CVE-2019-6203

报告作者Dominic说,当我们准备去年Defcon的演讲时,迈克尔(另一位研究员)和我正试图实施hostapd-wpe的EAP攻击测试。在此攻击中,身份验证服务器将接受任何用户名,后续操作不是将密码内容返回给工作站(因为它不知道密码),而是将EAP成功消息发送回工作站。

“对于迈克尔的奉献精神,我拒绝了很长时间。因为我认为这种攻击不起作用。因为在MSCHAPv2中,验证服务器实际上证明了密码内容返回决策方的过程,即使不是,我认为这个决定该段也将拒绝继续执行,毕竟这是安全的重点。“

让Dominic感到惊讶的是,在唯一的测试中,hostapd-wpe的EAP攻击测试成功,几乎所有实验性Apple设备(iPad,iPhone,Macbook)都成功连接到恶意接入点。由于WPE是由Brad Antoniewicz编写的,我不得不问他问题出在哪里:

bf0033b057d04c82bb8ef55934f21ec9.png

之后,Dominic对这一发现进行了大量研究,并于4月尝试了CVE-2019-6203漏洞攻击的复发实验。

重现Apple漏洞

重复攻击的第一步是找出漏洞的位置。通常,PEAP-MSCHAP v2身份验证过程分为两个阶段:

1.验证服务器标识并建立TLS隧道。服务器将服务器的证书信息发送给客户端,然后建立TLS隧道以保护传输的数据。

2.通过TLS隧道中的MSCHAP v2进行双向认证。

在第4帧和第5帧中,验证者和客户端的响应都由双方的Challenge + passwordHash +用户名计算,并发送给另一方进行验证。

那你如何重现Apple漏洞呢?

c064ae66072b4d51b34fa949fdab4214.png

d135f770eaf842a5998076fb035589e5.png

2008年,安全研究员Joshua Wright写了一个名为FreeRADIUS的补丁。 Wright的WPE攻击测试也使用绕过PEAP-MSCHAP v2的方式。最后,它可以通过建立假PEAP-MSCHAPv2热点获取个人用户请求,并在第二阶段获取Challenge,NTResponse和Username。

“在这项研究中可以采用类似的原则。” Dominic说,我使用相同的方法在CPE认证的CVE-2019-6203上复制漏洞攻击。

具体方法如下:

安装:

Hostapd-这是在Kali中使用“apt-get install hostapd-wpe”完成的,如下所示。

使用-e开关运行它以启用“EAP Success”

在iOS设备上,在Wifi下,连接到“hostapd-wpe”网络。选择信任证书。可以使用任何凭据。

设备将连接,运行dnsmasq以分发DHCP将显示设备以获取IP。

尝试使用以下示例配置将wpa_supplicant用于同一客户端连接将不起作用:

网络={

SSID=“hostapd -

Wpe“key_mgmt=WPA-EAP

EAP=PEAP

阶段2=“AUTH=MSCHAPV2”

同一性=“测试”

密码=“密码”

Ca_cert=“/etc/hostapd-wpe/certs/ca.pem”

}

因此,您将看到请求者将拒绝最终的消息验证者并断开连接。

修复问题和解决方案

在定期试用中,未修补的Apple设备会跳过发送验证器响应并仅在第7帧中发送MSCHAPv2成功帧。这使得易受攻击的Apple设备在其有状态机制中很容易被跳过。然后它发送PEAP响应 hostapd-wpe以向其发送EAP-Success。

根据Dominic的说法,这意味着如果Apple设备连接到具有未知用户密码的恶意AP,它将不仅会获得NetNTLMv1质询响应,而且设备也将连接到网络。由于EAP网络通常是企业网络,因此Apple设备会认为它是相关的(无用户交互),此时也可以执行响应式攻击。

这个漏洞影响到2019年3月25日之前的iOS,macOS和tvOS版本,包括MacBook,iPhone,iPad,Apple TV和其他Apple设备。但是,Dominic的难点在于,修补后的设备在PEAP,MSCHAPv2和WPA2级别上显示完全相同的行为,即设备仍然连接到网络,在某些情况下甚至会请求DHCP。这是一个例子:

379a90a023d0433197ea575c4fea4838.png

目:

1a9a803f3a984d90ab45baf471b59413.png

多米尼克解释说,这有点像守卫建筑物的保安人员,任何进入的人都会被驱逐出去。虽然它具有解决问题的效果,但是它会泄漏其他危险信号非常令人担忧。

“然而,当测试修复的系统时,我注意到了一个异常值。当设备连接但导出不同的PMK时,握手的第二个消息是MIC证明(这是repo中使用的WPA代码)当然,我认为这只是一个意外,因为PMK来自外部TLS会话并且未启用加密绑定,这应该是不可能的。“

目前,多米尼克还无法确认问题是否真的存在。他说,他将使用多台Apple设备在以后的研究中进行实验,以找出答案。

建议:

验证在最终EAP-Success消息中发送的消息验证器,并且不允许iOS/macOS设备连接到无法证明用户密码知识的恶意接入点。

可以在以下位置找到执行此验证的wpa_supplicant示例:

Https://w1.fi/cgit/hostap/tree/src/eap_peer/mschapv2.c#n112

,看多了