Re: Should nmap cause a DoS on cisco routers?

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 30 Jun 2010 07:03:32 -0400
Shang Tsung <stsung () mail com> wrote:

> Hello,
>
> Some days ago, I had the task to discover the SNMP version that our 
> servers and networking devices use. So I run nmap using the following 
> command:
>
> nmap -sU -sV -p 161-162 -iL target_file.txt
>
> This command was supposed to use UDP to probe ports 161 and 162,
> which are used for SNMP and SNMP Trap respectively, and return the
> SNMP version.
>
> This "innocent" command caused most networking devices to crash and 
> reboot, causing a Denial of Service attack and bringing down the 
> network.
>
> Now my question is.. Should this had happened? Can nmap bring the
> whole network down from one single machine?
>
> Is this a configuration error of the networking devices?
>
> This is scary...
>
> Shang Tsung


Hi Shang,

Obviously the anwser is no, Nmap shouldn't cause a DoS.  From the
command above it's clear though the the Nmap is not at fault and that
this is a Cisco IOS issue.

To summarize your command for others reading this response:

> nmap -sU -sV -p 161-162 -iL target_file.txt

* -sU  Makes the scan send UDP packets only

* -sV  Turns of service fingerprinting (sends a probe, waits for a
  response)

* -p 161-162 only scans two ports (SNMP and SNMP Trap)

* -iL  Scans all of the IPs and ranges listed in your text file


Almost certainly what is causing the crash is not the port scan itself
but the service versioning scan.  One of the probes is most likely
taking out the SNMP service and the router with it.

The way -sV works is that the probes listed in your nmap-service-probes
file (usually in /usr/share/nmap) are sent one after another roughly in
the order of likelihood of eliciting a response.

For port 161 the likely probe order is "SNMPv1public" and then
"SNMPv3GetRequest" which will probably get a response back that should
match "Cisco SNMP service".

For port 162, unless your router sends something back, Nmap will most
likely try all of the default UDP probes without success.

You can watch this activity in detail if you add:

* -d2 to turn of very verbose debugging

* --version-trace to turn on debugging of version probes and responses


Unless you want to spend some time troubleshooting your router, I'd
suggest making sure you're up at the latest version of IOS.

Otherwise, if you want to figure out exactly what probe Nmap is sending
to cause the problem, you should first try scanning just port 161 to
see if the issue still happens.  My money is on all of the probes sent
to port 162 rather than 161 causing the issue.

To figure out which probe it causing it, you can edit your
nmap-service-probes file and change the rarity of the UDP probes to 9.
If the issue is caused on port 161 you'll also need to change the two
SNMP probes "ports" directive to a different port.  Probes with high
rarity are still run if the port being probed is listed in the "ports"
list.

By changing half the probes to a rarity of 9 and the other half to 1
you should be able to binary-search your way to the exact probe causing
the issue.

If you do spend time troubleshooting, please report your results to the
nmap-dev () insecure org mailing list.  We'd love to hear what you find.

Regards,

Brandon  (an occasional Nmap developer)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwrp3oACgkQqaGPzAsl94JoNgCffKu5TteR/S2w0EMSYXKTAs3h
rF8An1GFQdbJNH3WAVleIeDxreOOf4QA
=wni/
-----END PGP SIGNATURE-----