Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

RE: VDS FAQ - request for feedback

From: David J. Meltzer <djm(at)intrusec.com>
Date: Fri Jan 31 2003 - 11:43:30 EST


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
Do you need help?X

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

Do you need more help?X

> people interested in this as there is with IDS.

-- 
David W. Goodrum
Senior Systems Engineer
NFR Security
Mobile: 703.731.3765
Office: 240.747.3425
Received on Fri Jan 31 12:38:07 2003

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:08 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library