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.bullat_private] Sent: Thursday, May 30, 2002 6:44 PM To: Ballowe, Charles; pen-testat_private 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" <CBalloweat_private> > To: "'Jon Bull'" <jon.bullat_private>; <pen-testat_private> > 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.bullat_private] > > > Sent: Wednesday, May 29, 2002 9:07 PM > > > To: David Litchfield; Alfred Huger; pen-testat_private > > > 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 2b30 : Fri May 31 2002 - 11:27:07 PDT