Brian Martin

Nessus contains a flaw in the Web Server that may lead to an unauthorized information disclosure. The issue is triggered when a remote attacker makes a request for the /feed method, which discloses the software's version resulting in a loss of confidentiality. While such information is relatively low risk, it is often useful in carrying out additional, more focused attacks.

On June 4, 2010, Adobe announced a new attack being exploited in the wild that targeted Adobe products, and word spread quickly. Adobe’s security bulletin (APSA10-01) provided few details, but confirmed that attackers were actively exploiting a vulnerability that affected their Flash Player, Adobe Reader and Acrobat.

Historically, vulnerability scanners have been signature based: looking for issues based on a static signature, behavior such as banner output or service response output to certain queries. If the scanner was not specifically directed to look for a given vulnerability, it would not find it. Many in the security industry still view most network vulnerability scanners in this light. The same people consider dedicated web application scanners as the only automated tools that can intelligently discover vulnerabilities not previously disclosed (i.e., “0-day”). This is simply not the case. Nessus’ focus is on enumerating known vulnerabilities, but it also leverages a mature web application scanner capable of finding unknown vulnerabilities. Nessus’ ten-year history and over 36,000 plugins give it a solid base for finding vulnerabilities. Despite many vulnerabilities being ‘old’ and thought to be patched, vendors and OEMs have a habit of re-using code over and over. What may have been an old vulnerability in light-weight web server could reappear years later in a device with an embedded web server running an administrator interface. While most plugins are signature based, Nessus has had the ability to find undiscovered vulnerabilities since 2001. Years before the first web application scanner was released, Nessus used a handful of plugins that could find generic overflows and format strings regardless of the service or if they were known to be vulnerable. While these tests are simple, they are very effective at ferreting out software that performs no sanity checking of user-supplied input.

Earlier this year, Michel Arboi wrote a blog post explaining how to use Nessus to call Nikto and incorporate the results into Nessus output. Most newcomers to Nessus have enabled the nikto.nasl wrapper only to find it produced no output.