RE: VDS FAQ - request for feedback

["David J. Meltzer" <djm () intrusec com>]

The one point I think worth noting in this thread is that it seems like
the ssh server detection and the slammer detection are two different
categories.  

In the SSH case, if I understand your signature correctly, you are
detecting the existence of an actual vulnerability passively, in the
absence of attempts to exploit it, while watching regular users connect
via SSH to the server.  This would be precisely what I would call
passive vulnerability detection.  

Contrasting, if I understand your signature correctly (as elaborated by
Mike Barkett's post), in the SQL Slammer case you have a signature that
is generic enough in nature that it can catch most/all ways the
vulnerability could be exploited.  At least in my evolving dictionary,
this is really not vulnerability detection, since you are detecting
someone making the exploitation attempt and not detecting the existence
of the underlying vulnerability in the absence of an attempt to exploit
it, and I don't think from what's been said that you can detect whether
the vulnerability existed or did not exist after the exploit was made.
I'd put this in the category of a well-written IDS signature but not
really "VDS".


-Dave

-----Original Message-----
From: David W. Goodrum [mailto:dgoodrum () nfr com] 
Sent: Wednesday, January 29, 2003 5:52 PM
To: David J. Meltzer
Cc: focus-ids () securityfocus com
Subject: Re: VDS FAQ - request for feedback


It's interesting that you talk about commercial vendors eventually doing

this type of detection. NFR already focuses a lot of it's current 
signatures on what you are terming as "VDS".  For example,  our SSH 
package watches for vulnerable versions of SSH.  We have a number of 
other packages that perform similar activity.  By watching for 
vulnerabilities (vs exploits), we detected the MS SQL slammer worm over 
the weekend, without updating any signatures.

I've included a sample SSH vulnerability alert below:

Alert Message:      ssh server on 10.0.1.7 vulnerable to
                     OpenSSH integer overflow
Source IP:          10.0.1.205
Destination IP:     10.0.1.7
Reason:             ssh server OpenSSH_3.1p1 vulnerable to
                     OpenSSH integer overflow

TECHNICAL INFORMATION
If ChallengeResponseAuthentication is enabled on an OpenSSH server, it 
will attempt to authenticate a user by sending a challenge and expecting

a response. Due to an error in logic, a client can send a larger number 
of responses than the server expects, resulting in an integer overflow. 
Furthermore, an attacker can use this bug to cause the server to execute

arbitrary code. Since this exchange happens before authentication, any 
remote client can exploit this bug. This bug is only exploitable in 
OpenSSH servers with versions 2.9.9 through 3.3 (inclusive).

OpenSSH servers with versions 2.3.1 through 3.3 (inclusive) are also 
vulnerable to the same bug in the PAMAuthenticationViaKbdInt code.

Privilege separation, which was introduced in OpenSSH 3.2, allows 
authentication code to be executed as an unprivileged user. Prior to 
this feature, authentication was executed as root. Privilege separation 
is enabled by default in OpenSSH 3.3 and prior releases. The severity of

this vulnerability is largely based on which user executes
authentication.

REFERENCES
OpenSSH Remote Challenge Vulnerability
http://www.openssh.org/txt/iss.adv
OpenSSH Security Advisory http://www.openssh.org/txt/preauth.adv
sshd_config manpage
http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config
ScanSSH
http://www.monkey.org/~provos/scanssh/




David J. Meltzer wrote:
> For anyone not too overwhelmed with chasing the worm this week...
>
> I have been working on a Vulnerability Detection System (VDS) FAQ, as 
> I've found myself and other people talking more about this area 
> recently and there does not seem to be a good centralized resource for

> people interested in this as there is with IDS.
>
> I have posted a 'alpha' version of this FAQ at 
> http://www.intrusec.com/vds
>
> It still needs some work before its ready for primetime but I want to 
> get it out to people who are interested in this topic so I can get 
> early feedback and make it more comprehensive before I start 
> recommending it to others as a resource.  If you are interested or 
> working on things in this area and have general or specific feedback, 
> I would love to hear from you.
>
> -Dave
>
> -------------------
> David J. Meltzer    
> djm () intrusec com    
> CTO, Intrusec, Inc.


-- 
David W. Goodrum
Senior Systems Engineer
NFR Security
Mobile: 703.731.3765
Office: 240.747.3425