ASUS 的多款路由器包含一个名为 infosvr 的服务，该服务监听 LAN 或 WLAN 接口上的 UDP 广播端口 9999。ASUS 的某个工具使用该服务来自动定位本地子网中的路由器，以简化路由器配置。此服务以 root 权限运行，并包含一个无需身份验证的命令执行漏洞。该服务的源代码以及路由器其余部分的代码均可从 ASUS 支持网站 获取。
分配给此问题的 CVE 编号为 CVE-2014-9583（唉，终究不是 CVE-2014-10000 :-/）。
目前，适用路由器（RT-AC66U、RT-N66U 等）的所有已知固件版本均被假定存在漏洞。测试针对 3.0.0.376.2524-g0013f52 版本进行。
以下路由器/固件版本已确认存在漏洞：
| 路由器 | 固件版本 | 验证者 |
|---|---|---|
| RT-N66U | 3.0.0.4.376_1071-g8696125 | Friedrich Postelstorfer |
| RT-AC87U | 3.0.0.4.378_3754 | David Longenecker |
| RT-N56U | 3.0.0.4.374_5656 | @argilo |
| RT-AC68U | 3.0.0.4.376_3626-g9a8323e | @Arie |
| DSL-N55U | 3.0.0.4.374_4422-gc83c78f | @S2- |
| DSL-AC68U | 3.0.0.4.376_2158-g340202b | @magJ, @gitFurious |
| RT-AC66R | 3.0.0.4.376_2524-g0013f52 | @asgh |
| RT-AC66R | 3.0.0.4.376_3602 | @facerolling |
| RT-AC55U | 3.0.0.4.376_6587-gaa506e9 | @pellaeon |
| RT-N12HP_B1 | 3.0.0.4.374_1327 | @vittee |
| RT-N16 | 3.0.0.4.220 | @xorrbit |
此外，运行基于社区支持的 asuswrt-merlin 固件的路由器，在 376.49_5 版本之前均存在漏洞。
使用 2015 年 1 月 12 日或之后发布的固件版本的路由器应不受影响。下表记录了未受影响路由器/固件的报告。
| 路由器 | 固件版本 | 验证者 |
|---|---|---|
| RT-AC66R | 3.0.0.4.376_3754-g5ef7c1f | @asgh |
| RT-N12HP_B1 | 3.0.0.4.376_3754-g5ef7c1f | @vittee |
请查看以下摘自 ASUSWRT-Merlin 项目（ASUS 代码的增强分支）的代码片段。你可以在此处查看完整文件（强烈推荐，笑料十足）。
177 char *processPacket(int sockfd, char *pdubuf)
178 {
...
202 phdr = (IBOX_COMM_PKT_HDR *)pdubuf;
...
207 if (phdr->ServiceID==NET_SERVICE_ID_IBOX_INFO &&
208 phdr->PacketType==NET_PACKET_TYPE_CMD)
209 {
...
收到 INFO_PDU_LENGTH（512）字节的数据包后，便会调用 processPacket 函数。具体存在漏洞的代码路径为 main->processReq->processPacket。随后，该服务将数据包强制转换为一个结构体，并检查 ServiceID 和 PacketType 字段是否与预期值匹配。
以下代码块被认为包含此漏洞的根本原因。
222 if (phdr->OpCode!=NET_CMD_ID_GETINFO && phdr->OpCode!=NET_CMD_ID_GETINFO_MANU)
223 {
224 phdr_ex = (IBOX_COMM_PKT_HDR_EX *)pdubuf;
225
226 // Check Mac Address
227 if (memcpy(phdr_ex->MacAddress, mac, 6)==0)
228 {
229 _dprintf("Mac Error %2x%2x%2x%2x%2x%2x\n",
230 (unsigned char)phdr_ex->MacAddress[0],
231 (unsigned char)phdr_ex->MacAddress[1],
232 (unsigned char)phdr_ex->MacAddress[2],
233 (unsigned char)phdr_ex->MacAddress[3],
234 (unsigned char)phdr_ex->MacAddress[4],
235 (unsigned char)phdr_ex->MacAddress[5]
236 );
237 return NULL;
238 }
239
240 // Check Password
241 //if (strcmp(phdr_ex->Password, "admin")!=0)
242 //{
243 // phdr_res->OpCode = phdr->OpCode | NET_RES_ERR_PASSWORD;
244 // _dprintf("Password Error %s\n", phdr_ex->Password);
245 // return NULL;
246 //}
247 phdr_res->Info = phdr_ex->Info;
248 memcpy(phdr_res->MacAddress, phdr_ex->MacAddress, 6);
249 }
该代码块首先排除了几个 OpCode 值，推测这些值按设计无需身份验证。然后，它调用 memcpy，并可疑地将返回值与零进行比较。这强烈表明作者本意是使用 memcmp。话虽如此，即使该检查实现正确，知道设备的 MAC 地址也远不足以构成身份验证。
以下代码块被注释掉了，但表明作者曾尝试检查密码。不过，在这种情况下，密码被硬编码为 “admin”。
接下来，以下 switch 语句根据提供的 OpCode 分派处理。
251 switch(phdr->OpCode)
252 {
...
428 case NET_CMD_ID_MANU_CMD:
429 {
430 #define MAXSYSCMD 256
431 char cmdstr[MAXSYSCMD];
432 PKT_SYSCMD *syscmd;
...
440 syscmd = (PKT_SYSCMD *)(pdubuf+sizeof(IBOX_COMM_PKT_HDR_EX));
...
443 if (syscmd->len>=MAXSYSCMD) syscmd->len=MAXSYSCMD;
444 syscmd->cmd[syscmd->len]=0;
445 syscmd->len=strlen(syscmd->cmd);
446 fprintf(stderr,"system cmd: %d %s\n", syscmd->len, syscmd->cmd);
447 #if 0
...
512 #endif
513 {
514 sprintf(cmdstr, "%s > /tmp/syscmd.out", syscmd->cmd);
515 system(cmdstr);
如果攻击者指定 OpCode 值为 NET_CMD_ID_MANU_CMD，前面的代码块会将数据包强制转换为 PKT_SYSCMD 结构体进行处理。因此，syscmd 的任何成员都完全由攻击者控制。作者在（眨眼）对命令字符串进行 NUL 终止处理后，于第 514 行执行了该命令。命令执行后，输出会从临时文件中读取，并发送回发起数据包的源地址。
最终用户：请将固件更新至 3.0.0.4.376.3754 或更高版本。务必注意，路由器的“检查更新”功能可能无法正常工作。请手动检查当前运行的固件版本，如果版本较旧，请下载/安装新固件。
ASUS/Merlin：请移除该服务中的远程命令执行功能。即使有强身份验证保护，向整个本地网络广播密码也不是一件可取的事。如果确实需要命令执行功能，应通过 SSH 或类似的安全机制提供。
David Longenecker 建议使用脚本（JFFS），并结合 script_usbmount nvram 设置，在启动时终止 infosvr 进程。更多信息请查看他的博客文章。
Eric Sauvageau（@RMerl）建议通过防火墙屏蔽 9999 端口。更多信息请参见他在 Small Net Builder 论坛上的帖子。
另外，也可以在每次启动后终止该进程来禁用 infosvr 服务。为了额外的乐趣/讽刺效果，可以使用漏洞利用程序来执行此操作：
$ ./asus-cmd "killall -9 infosvr"
[...]
注意：你不会收到此命令的响应。同样，每次设备重启后都需要执行此操作。
在此问题最初披露之后，多个方面已在其代码库中修复了该问题。
2015/01/08 - Eric Sauvageau 在 asuswrt-merlin 代码库中修复了此问题。包含该修复的首个发行版为 376.49_5。他的修改可在此处、此处和此处查看。
2015/01/12 - ASUS 已为受影响设备发布了新的固件版本（3.0.0.4.376.3754），据报道该版本不存在此漏洞。
ASUS 通过确保在执行所提供命令之前将 ateCommand_flag nvram 变量设置为 1 来解决该问题。该变量在典型构建中不会被设置。
loc_404958:
la $v0, 0x400000
addiu $a0, $v0, (aAtecommand_fla - 0x400000) # "ateCommand_flag"
la $v0, 0x400000
addiu $a1, $v0, (g_ascONE - 0x400000) # "1"
la $v0, 0x400000
addiu $t9, $v0, (check_nvram - 0x400000)
jalr $t9 ; check_nvram
nop
lw $gp, 0x290+var_270($fp)
bnez $v0, lbl_execute_command
nop
sw $zero, 0x290+var_14($fp)
b lbl_return_zero
本公告所在的代码仓库包含针对此问题的可用漏洞利用程序。
$ ./asus-cmd "nvram show | grep -E '(firmver|buildno|extendno)'"
[*] sent command: nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from 10.0.0.2:37625
0c 15 0033 54ab7bc4 41:41:41:41:41:41
0031 nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from 10.0.0.1:9999
0c 16 0033 54ab7bc4 xx:xx:xx:xx:xx:xx
004e buildno=376
extendno_org=2524-g0013f52
extendno=2524-g0013f52
firmver=3.0.0.4
“ASUSWRT 3.0.0.4.376_1071 - LAN 后门命令执行”
（这促使我发布了此公告。他的漏洞利用程序也镜像在 others/ 目录中）
http://www.exploit-db.com/exploits/35688/
“安全：LAN 端安全漏洞 - 缓解措施”
http://forums.smallnetbuilder.com/showthread.php?t=21774
“有台华硕路由器？你网络上的某个人可能就能入侵它”
http://arstechnica.com/security/2015/01/got-an-asus-router-someone-on-your-network-can-probably-hack-it/
“ASUS 漏洞使本地网络中的攻击者能够控制你的无线路由器”
http://dnlongen.blogspot.com/2015/01/asus-bug-lets-those-on-your-local.html
“漏洞利用程序允许从本地网络入侵华硕路由器”
http://www.itworld.com/article/2867255/exploit-allows-asus-routers-to-be-hacked-from-local-network.html