博客家

重新访问Realtek -自动零日分析发现的一组新的关键Wi-Fi漏洞

通过Uriya Yavniely

13分钟阅读

重访Realtek -发现的一组关键Wi-Fi漏洞

在2021年2月3日，我们负责任地披露了Realtek RTL8195A Wi-Fi模块中的六个关键问题这是一种流行的Wi-Fi卡，可以在许多连接设备中找到，比如家用和工业设备。

在成功检测和披露之后，我们将分析扩展到其他模块。通过使用一种独特的自动检测潜在零日漏洞的专有功能扫描模块，这项新的分析发现了两个新的关键漏洞。在另一次负责任的披露之后，Realtek修复了这些新漏洞。这些漏洞存在于Realtek流行的RTL8170C Wi-Fi模块上，影响任何使用该Wi-Fi模块连接到Wi-Fi网络的嵌入式和物联网设备。为了成功利用，攻击者需要与使用RTL8710C模块的设备在同一个Wi-Fi网络上，或者知道网络的PSK。成功利用将导致完全控制Wi-Fi模块，并可能对使用该模块的嵌入式设备的操作系统(如Linux或Android)进行root访问。

据我们所知，这些漏洞并没有在野外被利用。我们的理解是，Realtek团队迅速采取行动修补了这些漏洞，并将修补版本推送到易受攻击的产品中。hth华体会最新官方网站

在这篇博文中，我们将分享漏洞的技术细节，演示它们的利用，并探索我们用来发现它们的自动化方法。

RTL8710C模块

Realtek RTL8710C模块

Realtek RTL8710C模块基于ARM Cortex M3处理器，可用于以下行业的各种应用和众多设备:

  • 农业
  • 汽车
  • 能源
  • 游戏
  • 医疗保健
  • 工业
  • 安全
  • 智能家居

RTL8710C和RTL8195A是Realtek公司为ESP8266等expressif Wi-Fi模块提供替代方案的一部分。与RTL8195A相比，RTL8710C不包括ADC/DAC模块，具有更少的GPIO端口和更低的计算能力，同时更便宜。这意味着它更适合于部署在能源和农业行业的低资源设备。有关此模块的更多信息，请参阅Realtek的文档。

漏洞的总结

我们发现该模块的WPA2握手机制容易受到2个基于堆栈的缓冲区溢出漏洞的攻击。

CVE-2020-27301和CVE-2020-27302要求攻击者知道网络的PSK作为攻击的先决条件，并且可以被滥用来获取使用该Wi-Fi模块的WPA2客户端上的远程代码执行。

由于部分Ameba代码在Realtek Ameba系列的不同Wi-Fi模块之间共享，因此其他Ameba设备可能会出现部分或全部这些问题。例如，我们发现之前研究过的RTL8195A也容易受到上述两种漏洞的攻击。

漏洞技术深度介绍

CVE-2020-27301 - WPA2密钥解析中的堆栈溢出

CVSS v3.1:8.0(AV: /交流:L /公关:L / UI: N / S: U / C: H /我:H: H)

先决条件

此漏洞需要了解网络的PSK。

此漏洞允许利用Wi-Fi客户端设备。

技术细节

作为WPA2 4路握手的一部分，密钥交换发生在“EAPOL”帧(“消息3”):

密钥交换在EAPOL帧消息3

在此密钥交换中，Realtek WPA2客户端调用ClientEAPOLKeyRecvd来处理数据包。

ClientEAPOLKeyRecvd调用DecGTK()函数，该函数解密GTK(组临时密钥)。

在DecGTK()中会调用不安全的AES_UnWRAP():

如果(EapolKeyMsgRecvd.)[20] & 7) == 1 ) { … // RC4 decryption, not relevant } v__size_1 = EapolKeyMsgRecvd.Octet[112] + (EapolKeyMsgRecvd.Octet[111] << 8); AES_UnWRAP(EapolKeyMsgRecvd.Octet + 113, v__size_1, kek, keklen, tmp2); // OVERFLOW

上面的代码选择了一种解密方法:RC4解密ifEapolKeyMsgRecvd。[20] & 7== 1，否则选择AES解密。

EapolKeyMsgRecvd。Octet包含802.1x认证层，因此攻击者可以通过清除给出的比特来选择AES解密方法EapolKeyMsgRecvd。[20] & 7。

v__size_1也是用户控制的，因为它是一个大端无符号短码&EapolKeyMsgRecvd。八隅体[111]。

如果使用AES，那么DecGTK()调用AES_UnWRAP()，它将解密加密中的数据EapolKeyMsgRecvd。八隅体[113](加密的GTK字节)到tmp2与V__size_1作为大小。

问题是v__size_1不检查tmp2的固定缓冲区大小，所以v__size_1可以像0xFFFF一样大，而tmp2的大小只有0x101。这意味着AES_UnWRAP可以超越tmp2的边界，甚至超越DecGTK的堆栈帧并覆盖函数的返回地址。

开发场景

真实世界的攻击者可以通过以下方式利用受害者客户端设备上的CVE-2020-27301漏洞:

  1. 嗅探Wi-Fi数据包，查看受害设备连接的无线网络，并获取该网络的SSID。
  2. 准备一个恶意接入点(AP)，该接入点将执行攻击并具有准确的SSID。
  3. 向受害设备发送死亡报文，并以高于原有网络的声音广播，使设备连接到恶意AP。
  4. 正常执行4路握手，并提供带有很长的加密GTK值的epol - key消息

下面的图表说明了这一点:

开发场景

CVE-2020-27302 - WPA2密钥解析中的堆栈溢出

CVSS v3.1:8.0(AV: /交流:L /公关:L / UI: N / S: U / C: H /我:H: H)

先决条件

此漏洞需要了解网络的PSK。

此漏洞允许利用Wi-Fi客户端设备。

技术细节

DecGTK()中还有另一个基于堆栈的缓冲区溢出，就在CVE-2020-27301的脆弱代码之后:

if ((EapolKeyMsgRecvd.)[20] & 7) == 1 ) { … // RC4 decryption, not relevant } v__size_1 = EapolKeyMsgRecvd.Octet[112] + (EapolKeyMsgRecvd.Octet[111] << 8); AES_UnWRAP(EapolKeyMsgRecvd.Octet + 113, v__size_1, kek, keklen, tmp2); if ( !_wrap_memcmp(tmp2, bv, 8u) ) { v__size = v__size_1; v__src = &tmp2[8]; _wrap_memcpy(kout, v__src, v__size); // OVERFLOW return 1; }

正如我们前面提到的，攻击者控制着EapolKeyMsgRecvd. octet等可以强制解密方法为AES。

v__size_1也是用户控制的，因为它是一个大端无符号短码&EapolKeyMsgRecvd。八隅体[111]

当使用AES时，DecGTK()调用AES_UnWRAP()，它解密&EapolKeyMsgRecvd中的数据。将Octet[113]转换为tmp2，并将v__size_1作为大小。

在调用AES_UnWRAP()之后，将调用_wrap_memcmp()来检查tmp2的前8个字节是否等于预期的AES IV (0xA6的8个字节)，如果它们等于- DecGTK()将调用_wrap_memcmp()以便从其中复制字节&tmp2[8] with v__size_1作为大小，要知道哪个是参数。

DecGTK只从ClientEAPOLKeyRecvd()调用，它传递一个固定大小的输出缓冲区(kout)0 x80字节。

传递给_wrap_memcpy()的大小不会被检查，因此将v__size_1设置为大于0x80(例如0xFFFF)的值将导致传递的参数kout发生堆栈溢出。

利用场景与上面提到的CVE-2020-27301相同。

开发演示

由于没有缓冲区溢出缓解措施(例如金丝雀、ASLR)，因此利用是微不足道的。

我们的测试设置由RTL8195A开发板(受害者)和连接到ALFA网络Wi-Fi适配器的PC(攻击者)组成。RTL8195A还连接到JTAG调试器，因此我们可以获得gdb输出:

开发演示

PoC漏洞是通过修改开源实现的hostapd。攻击者充当AP(通过运行我们修改的hostapd)，并向通过WPA2连接到它的任何客户端发送恶意加密的GTK:

在开发视频中，可以在右侧窗口中看到“发送恶意加密的GTK”。

视频演示了堆栈溢出，它最终将返回地址覆盖到无效地址0x95f98179。这是一个“随机”地址，因为缓冲区经过AES解密，但是——因为攻击者完全知道所有的加密参数(网络的PSK等)，可以实现对返回地址的精确控制——这留给读者作为练习。

自动检测CVE-2020-27301和CVE-2020-27302

寻找缺失的函数符号

上述cve是通过自动化零日检测分析检测到的。在本节中，我们想详细说明这个过程，因为这个特定的情况需要有趣的预处理，这使我们改进了自动化的某些方面。

当我们第一次分析编译的Wi-Fi模块二进制文件时，我们没有得到任何实质性的结果，导致我们手动查看二进制文件。我们意识到许多重要的符号丢失了，因为二进制代码引用的地址不包括在二进制中:

寻找缺失的函数符号

通常，这些符号是由我们基于仿真的函数占卜引擎自动定义的——例如，为了找到ntohs()，我们可以模拟一个候选函数，传递一个数字，并期望该数字的按位交换版本作为返回值)。然而，在这种情况下，实际的函数实现无处可寻!

过了一会儿，我们意识到这些函数调用是调用RTL8710 ROM，它实现了很多重要的功能，例如我们经常用作漏洞源(例如recv)和接收器(例如strcpy)的指示器的所有“libc”函数。

我们考虑根据它们的使用猜测这些外部函数调用是什么，例如strcmp()通常会提供一个缓冲区参数和一个硬编码的字符串。

但是以这种方式自动查找符号可能容易出错，在strcmp()示例中，此函数可能只是计算硬编码字符串的散列并将其存储在给定的缓冲区中。此外，它需要使用硬编码字符串调用strcmp()，该字符串可能在其他固件中找不到。

所以，我们尝试了一种不同的方法来寻找这些符号。幸运的是，我们找到了一些该板的示例代码。

使用libc函数通过访问位于我们缺失的ROM节中的函数指针来执行。

例如，要查找“memcpy”的相关偏移量，我们可以查看-

组件/ soc /瑞昱/ 8710 c / misc / bsp / ROM / romsym_is.so

节{…utility_stub = 0x8c0;…}

组件/ soc /瑞昱/ 8710 c / misc /工具/ include / utility.h

struct struct utility_func_stubs_s{…Int (*memcmp)(const void *av, const void *bv, size_t len);// Offset 0xC void *(*memcpy)(void *s1, const void *s2, size_t n);//偏移量0x10…} utility_func_stubs_t;

函数偏移量

编译完示例代码后，我们可以很容易地提取每个效用函数的偏移量:

从这里开始，我们只需要编写一个预处理器来加载基于这些硬编码地址的函数符号。除非ROM本身改变，否则这些ROM地址不会改变，因此该技术应该适用于针对RTL8710模块的所有固件。

检测堆栈溢出

在所有符号都被正确定义之后，我们再次运行自动分析，并得到了更实质性的结果，正如预期的那样。在CVE-2020-27301和CVE-2020-27302的情况下，我们相关的不安全复制扫描程序将找到一个接收函数，如memcpy()，并跟踪到达该接收函数的“用户输入”。

平台只有在找到源和接收器时才会报告漏洞-当查看CVE-2020-27302时，接收器在这种情况下是memcpy(从ROM映射中识别)，因此平台的识别是微不足道的。然而，在裸机固件中查找“用户输入”的来源要棘手得多，因为可能没有recv()函数或其他已知的输入函数。该平台使用了许多不同的技术和启发式来估计特定变量是否来自“用户输入”，但在这种情况下，证明有用的技术是网络转换启发式。

理论上，ntohs()转换的任何值都来自网络输入，因此，平台将其视为外部数据或“用户输入”。

问题是ntohs()和htons()最终执行相同的代码:

(n >> 8) | ((n << 8) & 0xff00)

因此ntohs()和hons()可能彼此相同，在某些情况下是相同的函数。

Htons()在对数据进行编码以便通过网络发送数据时经常使用，因此我们需要将接收(用户输入)流和发送(非用户输入)流分开。为了区分这些流，平台将向后跟踪数据缓冲区，以确保ntohs正在非常量缓冲区上工作。例如，如果平台识别了一个直接的常量赋值，如:

但f[4] = 0x1337;…ntohs (buf [4]);

系统假定这是一个htons()调用(而不是ntohs())，并且不将其标记为用户输入。

对于CVE-2020-27302的漏洞代码路径，我们可以在DecGTK()的代码中看到，在网络数据转发之前，对其执行了ntohs()操作:

v__size_1 = EapolKeyMsgRecvd。Octet[112] + (EapolKeyMsgRecvd.)Octet[111] << 8);

由于这个操作，系统知道将v__size_1标记为来自用户输入，然后将其提供给memcpy。再加上系统观察到memcpy的目标是一个固定大小的堆栈缓冲区，并且没有进行大小检查->我们就有了一个堆栈溢出候选对象。

常见问题解答

Q1。我如何知道我的设备是否易受攻击?

2021年1月11日之后构建的任何版本都针对上述所有问题进行了完全修补。

构建日期通常可以从二进制固件中提取为一个简单的字符串。

例如，通过运行以下命令并观察类似的输出来查找固件中的任何构建日期:

# strings realtek_firmware.bin | grep -P '2021|2020|2019|2018|2017' 2021/05/10-17:14:47

Q2。我可以应用哪些补丁来解决这个问题?

ambz2 SDK的更新版本可以从以下网站下载瑞昱的网站。

最新版本的ambz2 SDK (7.1d)包含针对上述所有问题的补丁。

第三季。如果我无法更新设备的固件，我该如何降低风险?

使用一个强大的、私有的WPA2密码短语将防止利用上述问题。

问题吗?想法吗?如有任何疑问，请致电research@www.si-fil.com与我们联系安全漏洞。

除了发现并负责任地披露漏洞作为我们日常活动的一部分之外，JFrog安全研究团队还通过授权组织通过自动安全分析发现漏洞来增强软件安全性。有关JFrog DevOps平台安全特性的更多信息和更新-点击这里。

受欢迎的标签

试试JFrog平台

在云中或自托管

开始试验

或预订演示