Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: what determines if a plug-in is created |
|---|---|
| Date: | Wed, 22 Aug 2007 14:05:44 -0400 |
On 08/22/07 11:00, jfvanmeter@comcast.net wrote: Hi John,
is the creation of a plugin based on how widely the software is deployed?
At Tenable, some of the considerations that go into deciding whether to write a Nessus plugin include: - Is it for a vulnerability that's already been announced? We don't do 0-days. - If it's for a vulnerability, is that vulnerability valid? The number of bogus claims that make it onto the various mailing lists or even vulnerability databases is amazing! - If it's for a vulnerability, how critical is that vulnerability? We're much more likely to do a plugin for one that provides for unauthenticated remote code execution with root / SYSTEM privileges than another that simply causes an installation path to be displayed in an error message. We also tend to skip checks for XSS issues unless they're persistent or in major applications. - How popular is the affected hardware / software with respect to the Nessus user base? This is definitely a big factor in deciding whether to write a plugin for the vast majority of web-related issues but less so for critical vulnerabilities. - Has a fix or work-around been announced for the vulnerability? This is more of concern with products from major vendors such as Microsoft / Cisco. - How quickly, efficiently, and reliably will the plugin run? We tend to avoid checks that need to send large amounts of traffic or take a long time to complete. - How would a plugin impact the target? We sometimes pass on checks for vulnerabilities that require crashing an important service because we feel few people are likely to run the check. - Will the plugin require credentials? While scans can be configured with some credentials, we try to avoid plugins that would require yet another set to function. - Can we exploit the vulnerability in a plugin or do we need to do a banner check? Banner checks of open-source products are prone to false-positives so we tend to avoid them, except for widely-deployed software like Apache and sendmail. Also, we generate a number of plugins for local checks automatically from published vendor advisories. As new advisories are released, new plugins will be released shortly afterwards. Finally, realize that anyone can write plugins, even pen-testers who might discover that we missed something and want to contribute back to the community. :-) George -- theall@tenablesecurity.com _______________________________________________ Nessus mailing list Nessus@list.nessus.org http://mail.nessus.org/mailman/listinfo/nessus
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: what determines if a plug-in is created, F. Riphagen |
|---|---|
| Next by Date: | Plugin ID 16193 - Antivirus Check, Holstein, Robert - BLS CTR |
| Previous by Thread: | Re: what determines if a plug-in is created, F. Riphagen |
| Next by Thread: | Plugin ID 16193 - Antivirus Check, Holstein, Robert - BLS CTR |
| Indexes: | [Date] [Thread] [Top] [All Lists] |