From: Samuel Cure (scure@redbulltech.com)
Date: Fri May 31 2002 - 16:26:21 EDT
The VNA seems like a fair solution. If the vendor is delaying release for a
roll up service pack of some sort to consolidate efforts and minimize the
cost/complexity of releasing individual patches, their loss. I've had the
pleasure in the past of working with X vendors who would demand we wait for
a fix before releasing an advisory and yet they sit on it for months. This
is unacceptable. Perhaps the VNAs will heighten vendor's response and
shorten the release cycle.
I agree with the point about the Typhoon UELA being ineffective in
prohibiting reverse engineering scans for exploit code. This will definitely
occur, but the lack of exploit information in the VNA and the latency
between VNA and Typhoon updates, will at least buy the Vendor some time to
release the patch before Hacker X derives the exploit from Typhoon.
I would also like to further emphasize the point of proprietary IDS
signatures detecting unpatched vulns. Although I believe this to be a good
solution, some sort of data correlation is needed between IDS and
vulnerability assessment to determine whether or not we are actually
vulnerable to an attack flagged by IDS. This would require check inclusion
in Typhoon for a complete security assessment.
-Sam
-----Original Message-----
From: Jon Bull [mailto:jon.bull@knowledgelinks.com]
Sent: Thursday, May 30, 2002 6:44 PM
To: Ballowe, Charles; pen-test@securityfocus.com
Subject: Fw: Scanners and unpublished vulnerabilities - Full Disclosure
Here's the current timeline I see for the VNA:
NGSS discovers an exploit.
The vendor is notified.
NGSS releases their general notification.
Typhoon is updated.
People who can use workarounds do, others cannot and their system remains
vulnerable.
HackerX reverse engineers the Typhoon scan, now he has the exploit.
Vendor issues patch.
Section 2 of the Typhoon UELA prohibits reverse engineering. I would assume
that this apply's to tracing traffic generated by Typhoon during it's scans,
but we know that won't stop some people. It hasn't in the past. As
hellNbak pointed out Charles, scans based on Version or Patch level are
prone to false positives.
Let me defend the IDS idea:
Workarounds are just that. They are not solutions and they may not always
be applicable to an environment.
The IDS would be an NGSS bit of software. Every week you get an update file
from NGSS. This file would contain a list of new exploits in VNA format.
It would also contain signatures for the IDS software in a proprietary
format that would not surrender the exploitation method to the end user.
In this case you would have the workarounds to secure your systems if
possible, and a way to monitor for attacks whould the workarounds prove
impossible to implement.
In the current implmentation of the VNA/Typhoon you have the workarounds to
secure your systems if possible, and no way to monitor for the exploit
otherwise.
The VNA sounds like an excellent idea. I disagree with check inclusion in
Typhoon before the vendor patch for the reasons stated above.
Jon
>
>
>
>
> ----- Original Message -----
> From: "Ballowe, Charles" <CBallowe@usg.com>
> To: "'Jon Bull'" <jon.bull@knowledgelinks.com>;
<pen-test@securityfocus.com>
> Sent: Thursday, May 30, 2002 5:27 PM
> Subject: RE: Scanners and unpublished vulnerabilities - Full Disclosure
>
>
> > An IDS is only really effective when you know the potential risk
> > of a successful attack. Once something is triggering an IDS, it's
> > already hitting my systems. If I haven't been alerted to the nature
> > of that particular risk, my IDS can't be properly set up to respond,
> > and depending on the nature of the attack, it may be too late anyway.
> >
> > If my IDS gives me an alert indicating an attempt to exploit a certain
> > vulnerability and searches for more information on that vulnerability
> > yield nothing, I'm going to start to wonder. If my IDS is coupled with
> > a packet capture mechanism, I'll still have the raw data that
> > triggered the alert. The only difference is whether I had the data
> > before it was in the wild or not.
> >
> > Then there's the fact that IDS is a reactive technology and a scanner
> > is proactive. Many companies treat security breaches in a reactive
manner.
> > This isn't the best approach and some are finally learning the lesson.
> > Both are needed, but it's better to know before rather than after.
> >
> > Something else to keep in mind -- a security scanner need not actively
> > exploit a vulnerability to identify it's presence. Host based scanners
> > can simply check software versions/patch applications and compare to
> > known vulnerabilities/fixes in order to trip an alert. Network based
> > scanners can use network version banners to do the same thing.
> >
> > -Charles Ballowe
> >
> >
> >
> > > -----Original Message-----
> > > From: Jon Bull [mailto:jon.bull@knowledgelinks.com]
> > > Sent: Wednesday, May 29, 2002 9:07 PM
> > > To: David Litchfield; Alfred Huger; pen-test@securityfocus.com
> > > Subject: Re: Scanners and unpublished vulnerabilities - Full
> > > Disclosure
> > >
> > >
> > > Suggestion - Instead of making a scanner to test for a
> > > vulnerability that a
> > > Typhoon user may not be able to prevent, why not create IDS
> > > software to
> > > detect the exploit? To me this seems a more defensive,
> > > responsible, and
> > > effective role.
> > >
> >
>
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:21 EDT