Add ASUS infosvr Auth Byass Scanner module

[bcoles]

This PR adds an ASUS infosvr Scanner module.

This module discovers ASUS infosvr servers vulnerable to CVE-2014-9583.

Verification

• Start msfconsole
• use auxiliary/scanner/misc/asus_infosvr
• set RHOSTS 255.255.255.255
• run

Example Output

msf auxiliary(asus_infosvr) > set rhosts 10.1.1.1/24 10.0.0.0/24 255.255.255.255
rhosts => 10.1.1.1/24 10.0.0.0/24 255.255.255.255
[*] Sending requests to 256 hosts...
[*] Sending requests to 256 hosts...
[*] Sending requests to 1 hosts...
[+] 10.1.1.1:9999 is VULNERABLE
[*] No infosvr services found.
[+] 10.1.1.1:9999 is VULNERABLE
[*] Scanned 513 of 513 hosts (100% complete)
[*] Auxiliary module execution completed

The output is silly (reports a host, then reports no hosts were found, then reports the same host again) due to the way batch scanning works. This is typical of all module which make use of the UDPScanner when specifying more than one host or host range in RHOSTS.

[bcoles]

I'm sure this will never end badly. 🙄

[bcoles]

I never reached this code path. Consider it future proofing against PacketFu. 🙄

[jhart-r7]

What is the reason for doing the capture here rather than via scanner_process?

[bcoles]

@jhart-r7 The infosvr service does not reply to the source IP address, it replies to the broadcast address 255.255.255.255

The scanner_process method does not parse broadcast traffic - see #9244

[bcoles]

There does not appear to be a flag for the UDPScanner library to enable parsing broadcast traffic. This implementation was the most clean and efficient way I could think of capturing and parsing the broadcast traffic.

To clarify, if scanner_process parsed broadcast traffic, the module would be much smaller and easier to read, as there would be no need to use the Msf::Exploit::Capture library, use open_pcap, use PacketFu, deal with threading, etc.

[bwatters-r7]

Possibly dumb question: do you have to have metasploit installed as root to run this because of the socket manipulation?

msf exploit(sshexec) > use auxiliary/scanner/misc/asus_infosvr 
msf auxiliary(asus_infosvr) > set rhosts 192.168.132.205
rhosts => 192.168.132.205
msf auxiliary(asus_infosvr) > run

[*] Sending requests to 1 hosts...
SIOCSIFFLAGS: Operation not permitted
[-] Auxiliary failed: RuntimeError ens33: You don't have permission to capture on that device (socket: Operation not permitted)
[-] Call stack:
[-]   /home/tmoose/rapid7/metasploit-framework/lib/msf/core/exploit/capture.rb:124:in `open_live'
[-]   /home/tmoose/rapid7/metasploit-framework/lib/msf/core/exploit/capture.rb:124:in `open_pcap'
[-]   /home/tmoose/rapid7/metasploit-framework/modules/auxiliary/scanner/misc/asus_infosvr.rb:68:in `scanner_prescan'
[-]   /home/tmoose/rapid7/metasploit-framework/lib/msf/core/auxiliary/udp_scanner.rb:85:in `run_batch'
[-]   /home/tmoose/rapid7/metasploit-framework/lib/msf/core/auxiliary/scanner.rb:215:in `block in run'
[-]   /home/tmoose/rapid7/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
[*] Auxiliary module execution completed

[busterb]

So, the pattern it seems for all Metasploit modules so far is to use raw sockets for capturing broadcast packets, as opposed to using a broadcast socket. I asked @bcoles why we can't use broadcast sockets, and it appears that there is no actual technical reason documented why not.

[bcoles]

Delayed pending fix for #9244

[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.

[bwatters-r7]

Is this still delayed? Was there any motion on the raw socket front?

[bcoles]

@bwatters-r7 no motion.

It may be as simple as using Socket::SOL_BROADCAST. Assuming there is a future need for this use case, I suspect the cleanest resolution would be to augment UDPScanner to allow sniffing broadcast traffic, as per #9244.