RE: Crashing services with NMAP and/or SuperScan ?

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

Donald,

Two items:

1. Foundstone released SS4, which I believe is what you
are referring to. It appeared to have the same text-file
driven port/prot match system, just a much more comprehensive
list of port/prots. I don't think it actually *does* anything
in terms of ident; someone from FS jump in here if I'm wrong.

2. Per below, I was referring to interrogating a stack for
specific responses to help identify the stack, and further
interrogating a protocol to identify what it is and what
functions it is offering. The discussion originated about
port scanning and OS ident causing failure. This activity
should normally be benign and present little risk.

Regarding vulnerability scanning; you are absolutely correct.
It should be common knowledge that any vulnerability scanner
has the ability to crash systems with an invasive check, and
for that matter, a "non-invasive" or 'safe' check, be it ISS/ISS,
Qualysguard, Retina, Nessus, Foundscan, or whatever. Some of
the safe checks that aren't very smart or the scan engine isn't
very smart mis-identify protocols or arbitrarily scan for any
vuln that matches a given open port.

So you get scenarios like: say you have say a Nessus BoF check
for the Cisco HTTP vuln that by default listens on tcp/2301. This
check generates X amount of garbage data (400 characters if I
remember) to pad the buffer before sending commands to execute.
The check does not verify the protocol (HTTP), banner grab for
product name, or anything intelligent like this.

So now Nessus sees tcp/2301 and sends this check to what happens
to be an IP-enabled terminal session bound to a VAX console, and
it interprets as control characters and bang, hard halt.

However if you always play safe you will also miss some of the
juicy stuff. Zero-day issues I've found before were the result
of a scanner breaking something and the vendor refusing to tell
me exactly what their 'unsmart' check was doing to the 'wrong'
product. So one has merely to fire up the sniffer and watch...

HtH

Arian Evans
Sr. Security Engineer
FishNet Security

KC Office:  816.421.6611
Direct: 816.701.2045
Toll Free:  888.732.9406
Fax:  816.474.0394

http://www.fishnetsecurity.com


> -----Original Message-----
> From: Donald Whitfield [mailto:don.whitfield () gmail com] 
> Sent: Friday, November 26, 2004 3:23 PM
> To: Evans, Arian
> Cc: pen-test () security-focus com
> Subject: Re: Crashing services with NMAP and/or SuperScan ?
>
> Also,
>
> The ability to disrupt service on a production network also exists by
> using the Nessus Scanner (unix version - with all plugins loaded). We
> were able to crash 3Com and Nortel Switches by performing Intrusive
> scans with most plugins loaded.
>
> Donald Whitfield
> Sr. Network Security Engineer
>
>
> On Fri, 26 Nov 2004 16:20:20 -0500, Donald Whitfield
> <don.whitfield () gmail com> wrote:
> > Actually, Foundstone has release a new version of SuperScan 
> just this
> > year. We played with it during the ultimate hacking 
> bootcamp and it's
> > pretty sweet. The scan results can be converted to various formats
> > just like Nessus Scan Results.
> >
> >
> >
> >
> > On Fri, 26 Nov 2004 09:46:24 -0600, Evans, Arian
> > <arian.evans () fishnetsecurity com> wrote:
> > > > > - one Oracle TNS Listener - however the admin said
> > > > "everything continued to
> > > > > function"
> > > > > - 2 or 3 Storageworks EVA Secure Path services.
> > > >
> > > > I would think that your problem is with the -O flag. A lot of
> > > > people have
> > > > reported similar behaviour with the O/S detection.
> > > >
> > > > > Fortunately the admins were not upset. They looked through
> > > > the services on
> > > > > the servers, looked which ones had gone "stopped" and set
> > > > them back to
> > > > > "started".
> > >
> > > In general point to watch on Oracle--
> > >
> > > Oracle listeners are extremely fragile to invasive interrogation.
> > > I have brought down Oracle listners repeatedly with a variety
> > > of port scanners that do OS detection. Wish I could remember
> > > the exact Oracle versions, at least as recent as 8 and 9i,
> > > and primarily running on *nix. (Linux, AIX, and OpenVMS; of
> > > course, with VMS's own native buggy and third-party IP stacks,
> > > just about any port/vuln scanning activities is liable to bring
> > > those things down.)
> > >
> > > Interestingly I have not seen this same behavior on Oracle on
> > > Windows. Anyone else?
> > >
> > > Arian Evans
> > > Sr. Security Engineer
> > > FishNet Security
> > >
> > > KC Office:  816.421.6611
> > > Direct: 816.701.2045
> > > Toll Free:  888.732.9406
> > > Fax:  816.474.0394
> > >
> > > http://www.fishnetsecurity.com
> > >
> > > The information transmitted in this e-mail is intended 
> only for the addressee and may contain confidential and/or 
> privileged material.
> > > Any interception, review, retransmission, dissemination, 
> or other use of, or taking of any action upon this 
> information by persons or entities
> > > other than the intended recipient is prohibited by law 
> and may subject them to criminal or civil liability. If you 
> received this communication
> > > in error, please contact us immediately at 816.421.6611, 
> and delete the communication from any computer or network system.
> > >