Overview on Nessus web app vulnerability scan

[Joao Correa <joao () livewire com br>]

Hello everyone,

I've been using the new Nessus web application vulnerability scanner
capabilities. Nessus's developers have recently posted an article at
[1] about some new related features. Here follows some impressions and
some ideas I had while running such tests.

If someone have new ideas from this report, it would be great to share
and help the development of the http support in NSE.

Nessus supports different web vulnerability detection features since
some older versions. Amongst new and old features, some are:

SQL Injection and XSS detection, Remote File Inclusion, HTTP Header
Injection, Directory Traversal, Remote File Inclusion, Command
Execution, Web Server directory enumeration, E-mail address retrieval,
XSS Detection, HTTP Trace, robots.tx retrieval and Nikto integration.

Some of these resources are already supported by Nmap. Scripts
sql-injection.nse, http-enum.nse (written by Rob Nicholls and that was
recently integrated to nmap), http-trace.nse and robots.txt.nse
already perform a few functionalities available in Nessus. Anyway,
there is room for some improvements. While our http-enum.nse script
performs 40 common directory checks, Nessus checks for almost 700.
http-enum.nse could use a bigger list, but, while this can help the
discovery of web applications, it will also increase the execution
time of the script. Also, not only filtering the directories to scan,
but also organizing them in lists of common/rare directories could
provide good scanning customization (if you need performance, you only
scan the common directories).

Functions like e-mail address retrieval and XSS detection are not yet
available in Nmap. E-mail address retrieval is a feature already
planned to be added right before the completion of the spidering
infra-structure. An important thing that this feature will provide is
the ability to dynamically create user lists, what can improve the
efficience of brute force attacks.

I've made a small and not very precise comparison of running the
existent http scripts of Nmap and Nessus against a server with some
flaws. I've disabled all the unrelated plugins of Nessus and
configured it to a web driven scan. Of course that Nessus's scan took
a much longer time to run.

Both tools detected the same SQL Injections. Nessus failed to detect
some Remote File Inclusion bugs from Moth[2]. Nessus was able to find
/etc/passwd using directory traversal in a localhost application.

I could notice that Nessus's XSS detection is working fine, having
detected different XSSs on the server. One good thing to discuss is
that all the XSS detected were not persistent. As we are speaking
about a tool, we should think twice before adding persistent XSS
detection. Using such feature could change drastically the state of
the server. We should also consider that every user will be capable of
notice that the flaw exists, unless that the admin removes the
injected XSS code.

Sniffing the test, I could check that Nessus wasn't able to follow
some urls that were inside javascripts. I believe that such ability is
very likely and that it worths having a script for detecting all the
urls that are inside javascripts. This features could not only help
the spidering process, but also allow javascript calls mapping,
providing useful information while pen-testing Ajax applications.

I could also verify that Nessus was not using any special HTTP 1.1
resource, such as keep-alive or pipelining, to perform its HTTP
requests. I believe that this made the scan last much longer. We are
planed to soon add some features for connections using keep alive and
pipelining to http.lua, certain that such feature will allow much
faster scans.

Another interesting feature is that it is also possible to run Nikto
inside a nessus scan. Nikto is probably the most reliable and
well-known web application vulnerability scanner. For using this
feature, it is required that the user downloads and place Nikto inside
the Nessus's root directory.

An interesting resource that was used by Nessus's developers while
writing the web application checks was Moth [2]. Moth is a VMware
image with several vulnerable web applications. I've compared both
tools running scannings against the same virtual machine running Moth.

[1] - http://blog.tenablesecurity.com/2009/06/enhanced-web-application-attacks-added-to-nessus.html
[2] - http://www.bonsai-sec.com/en/research/moth.php

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org