博客家

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

通过Uriya Yavniely

13分钟阅读

重新访问Realtek - Set的关键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)的潜在根访问。

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

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

RTL8710C模块

Realtek RTL8710C模块

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

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

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

漏洞的总结

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

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

由于部分阿米巴代码在Realtek阿米巴系列的不同Wi-Fi模块之间共享，因此其他阿米巴设备可能也存在部分或全部这些问题。例如，我们发现之前研究的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-way握手的一部分，密钥交换发生在“EAPOL”帧(' Message 3 '):

密钥交换在EAPOL帧-消息3

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

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

在DecGTK()中，不安全的AES_UnWRAP()将被调用:

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); // OVERFLOW

上面的代码选择一种解密方法:RC4解密如果EapolKeyMsgRecvd。八重奏[20]和7== 1，否则选择AES解密。

EapolKeyMsgRecvd。Octet包含802.1x身份验证层，因此攻击者可以通过清除所给出的位来选择解密方法为AESEapolKeyMsgRecvd。八重奏[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值的eapoll - 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.八位字节等可以强制解密方法为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_memcpy()以便从&tmp2[8]与v__size_1作为大小，to kout是一个参数。

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，它实现了许多重要的功能，例如所有“libc”函数，我们经常将其用作漏洞源(例如recv)和漏洞接收器(例如strcpy)的指示器。

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

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

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

使用libc函数，通过访问位于ROM部分的函数指针来执行。

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

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

section{…utility_stub = 0x8c0;．.．｝

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

Typedef struct utility_func_stubs_s{…Int (*memcmp)(const void *av, const void *bv, size_t len);//偏移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()和htons()可能彼此相同，在某些情况下是同一个函数。

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

Buf [4] = 0x1337;．.．ntohs (buf [4]);

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

关于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_固件.bin | grep -P '2021|2020|2019|2018|2017' 201/05/10 -17:14:47

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

ambz2 SDK的更新版本可以从瑞昱的网站．

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

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

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

问题吗?想法吗?如有任何问题，请通过research@m.si-fil.com与我们联系安全漏洞．

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

受欢迎的标签

试试JFrog平台

在云端或自托管

开始试验

或预约演示