ASUS Router infosvr UDP Broadcast root Command Execution
Switch branches/tags
Nothing to show
Clone or download
jduck Merge pull request #19 from Frodox/frodox-makefile
Add simple Makefile and fix few gcc warnings
Latest commit 8785388 Mar 16, 2015

ASUS Router infosvr UDP Broadcast root Command Execution

Several models of ASUS's routers include a service called infosvr that listens on UDP broadcast port 9999 on the LAN or WLAN interface. It's used by one of ASUS's tools to ease router configuration by automatically locating routers on the local subnet. This service runs with root privileges and contains an unauthenticated command execution vulnerability. The source code for this service, as well as the rest of the router, is available from ASUS's Support Site.


The CVE assigned to this issue is CVE-2014-9583 (alas, not CVE-2014-10000 after all :-/).

Affected Versions

Currently, all known firmware versions for applicable routers (RT-AC66U, RT-N66U, etc.) are assumed vulnerable. Testing was performed against

The following routers/firmware versions are confirmed vulnerable:

Router Firmware Version Verified By
RT-N66U Friedrich Postelstorfer
RT-AC87U David Longenecker
RT-N56U @argilo
RT-AC68U @Arie
DSL-N55U @S2-
DSL-AC68U @magJ, @gitFurious
RT-AC66R @asgh
RT-AC66R @facerolling
RT-AC55U @pellaeon
RT-N12HP_B1 @vittee
RT-N16 @xorrbit

Additionally, routers running firmware based on the community-backed asuswrt-merlin are vulnerable prior to version 376.49_5.

Routers using firmware revisions released on or after January 12th, 2015 should not be affected. The following table tracks reports of non-affected routers/firmwares.

Router Firmware Version Verified By
RT-AC66R @asgh
RT-N12HP_B1 @vittee

Technical Details

Consider the following excerpt from the ASUSWRT-Merlin project, which is an enhanced fork of ASUS's code. You can view the file in it's entirety (recommended for extra lulz) here.

   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      {

The processPacket function is called after receiving a packet of INFO_PDU_LENGTH (512) bytes. The specific vulnerable code path is main->processReq->processPacket. The service then casts the packet to a structure and checks that the ServiceID and PacketType fields match expected values.

The following block contains what is believed to be the root cause of this vulnerability.

   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;       
   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                  }
   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          }

The block starts off by excluding a couple of OpCode values, which presumably do not require authentication by design. Then, it calls the memcpy and suspiciously checks the return value against zero. This is highly indicative that the author intended to use memcmp instead. That said, even if this check was implemented properly, knowing the device's MAC address is hardly sufficient authentication.

The following block is commented out, but shows that the author at some point experimented with checking a password. Albeit, in this case, the password was hardcoded as "admin".

Moving on, the following switch statement dispatches processing based on the supplied 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);

If an attacker specifies the OpCode value of NET_CMD_ID_MANU_CMD, the preceding block processes the packet by casting it to a PKT_SYSCMD structure. As such, any members of syscmd are fully controlled by the attacker. Before taking care (wink) to NUL terminate the command string, the author executes the command on line 514. Following executing the command, the output is read from the temporary file and sent back to the source address of the initiating packet.


End Users: Update firmare to revision or newer. It's important to note that the router's "Check for Update" functionality may not work properly. Manually check the version of the firmware you're running and, if older, download/install the new firmware.

ASUS/Merlin: Remove the remote command execution functionality from this service. Even if it were guarded with strong authentication, broadcasting a password to the entire local network isn't really something to be desired. If command execution is truly desired it should be provided via SSH or similar secure mechanism.


David Longenecker recommends using a script (JFFS) in combination with the script_usbmount nvram setting to kill the infosvr process on boot. For more information check out his blog post.

Eric Sauvageau (@RMerl) recommends firewalling port 9999 off. For more information see his post on the Small Net Builder forum.

Alternatively, disable the infosvr service by killing the process after each boot. For extra fun/irony, use the exploit to do this:

$ ./asus-cmd "killall -9 infosvr"

NOTE: you won't get response to this command. Again, this will need to be done each time the device restarts.

Fixes Released

After the initial disclosure if this issue, several parties addressed the issue with their code bases.

2015/01/08 - Eric Sauvageau fixed this issue in the asuswrt-merlin code base. The first release incorporating the fix is 376.49_5. His changes can be reviewed here, here, and here. 2015/01/12 - ASUS has released new firmware revisions for affected devices ( that is reportedly not vulnerable.

ASUS addressed the problem by ensuring the ateCommand_flag nvram variable is set to 1 prior to executing the supplied command. This variable is not set in typical builds.

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
lw      $gp, 0x290+var_270($fp)
bnez    $v0, lbl_execute_command
sw      $zero, 0x290+var_14($fp)
b       lbl_return_zero


The repository in which this advisory resides contains a working exploit for this issue.

Example exploit output:

$ ./asus-cmd "nvram show | grep -E '(firmver|buildno|extendno)'"
[*] sent command: nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from
    0c 15 0033 54ab7bc4 41:41:41:41:41:41
    0031 nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from
    0c 16 0033 54ab7bc4 xx:xx:xx:xx:xx:xx
    004e buildno=376

Other Links

"ASUSWRT - LAN Backdoor Command Execution"
(this triggered my publishing. his exploit is also mirrored in the others/ directory)

"SECURITY: LAN-side security hole - mitigation"

"Got an Asus router? Someone on your network can probably hack it"

"ASUS bug lets those on your local network own your wireless router"

"Exploit allows Asus routers to be hacked from local network"

"Asus Wireless Routers Can Be Exploited By Anyone Inside the Network"

"Most Asus routers affected by hijack bug; exploit posted"

"Root Command Execution Flaw Haunts ASUS Routers"