Message-ID: <20100702105430.GA22198@bundy.vistech.net>
Date: Fri, 2 Jul 2010 06:54:30 -0400
From: "Champ Clark III [Softwink]" <champ@...twink.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Should nmap cause a DoS on cisco routers?

On Fri, Jul 02, 2010 at 09:45:20AM +0000, Florian Weimer wrote:
> > On Jul 1, 2010, at 11:12 PM, Florian Weimer wrote:
> >> And it's certainly a bug worth fixing. 
> >
> > I doubt it's a 'bug' which can be 'fixed', just the same as sending
> > enough legitimate HTTP requests to a Web server to bring it to its
> > knees isn't a 'bug' which can be 'fixed', but rather a DoS which
> > must be mitigated via a variety of mechanisms.
> 
> I was referring to single-packet (or single-request) crashers.
> Reputable vendors still ship devices that have those bugs in 2010.
> 
> Chances are that Shang Tsung's nmap run triggered one of those.  As I
> wrote, it happened before.  The nmap command line posted further
> uptrhead does not actually cause a high pps flood.  Such level of SNMP
> scanning is quite common in enterprise networks because some printer
> drivers use it to locate printers, so your network devices are better
> prepared to handle that.

	One environment that I've noticed this is 'acceptable',  in the
eyes of the network management,  is VoIP installations.   I've done
assessments in several large scale,  production level VoIP installations
and in many cases,  you'll run into the same potential DoS when using
tools like nmap.   I've noticed that even if the orginazation has a 
very capable security staff,  in many cases,  they don't get to touch
the VoIP network due to it's 'magical' properties (IMHO).   I won't
even go into the obvious lack of security practices (no IDS/IPS,  very
out of date systems, etc) in such networks due to the 'magic' of these
networks.  

	It sometimes seems that no matter how lightly you try to 
tread,  you'll find these things.   Be it due to the lack of security within
the network or a actual vendor problem.

	I've seen this across the board.  Cisco,  Avaya (Nortel)
installations down to out-of-date Asterisk based installations.  
	
	In one case,  we found a potential DoS condition with a vendors
product.  Getting the vendor to look into it was no problem.  Getting 
the _client_ to work with the vendor on addressing the issue was a 
complete pain!  The response from the client was,  'just don't run 
any scanners (nmap included) within the network'.   Yes,  put that 
in the /etc/motd so that attackers know not to do that :)

	Somehow,  I don't find that acceptable. 

	Again,  it's a environment that's 'magical' and not well
understood so once it's 'working',  don't touch anything!

> And even if you applied control plane protection, you still need to
> monitor those devices from your management network.  The brittleness
> described in this thread makes this an extremely risky endeavor: one
> typo in your Perl script, and your network is gone, even if the
> monitoring station never had the credentials for enable access.
> Those bugs might not be security-relevant, but they can be very
> annyoing nevertheless.
	
	Couldn't agree with you more.  _When_ and _if_ they apply
control plane protection.  I don't know what the rest of the lists 
experience is with VoIP networks,  but in many cases they seem to
be stuck in the way-back-machine in reguards to network security. 
Not always,  but a heck of a lot.  Accidental 'DoS' conditions seem
to pop-up a lot in these environments,  IMHO.  

-- 
        Champ Clark III | Softwink, Inc | 800-538-9357 x 101
                     http://www.softwink.com

GPG Key ID: 58A2A58F
Key fingerprint = 7734 2A1C 007D 581E BDF7  6AD5 0F1F 655F 58A2 A58F
If it wasn't for C, we'd be using BASI, PASAL and OBOL.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists