Re: Overview on Nessus web app vulnerability scan

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

Hello Guys,

I've been looking a Nessus's scripts a little bit closer. I've made a
list of some that have interesting and more generic functionalities
and that could be suitable to Nmap. Also, I've excluded
scripts/functions that are already supported (or that are planned to
be soon included, like web mirroring) by Nmap from the list below.

HTTP Cookies: http://nessus.org/plugins/index.php?view=single&id=39463
Display the cookies that were set by the server while crawling the website

Network Camera Detection:
http://nessus.org/plugins/index.php?view=single&id=33523
Detect that the page displayed by the server is an interface for a web camera

Session ID Prediction: http://nessus.org/plugins/index.php?view=single&id=31657
The Session ID is not randomly generated, and it is possible to
predict IDs for different sessions.

Test 404 Pages for paths:
http://nessus.org/plugins/index.php?view=single&id=11714
Checks if a 404 Error message is displayed with its path.

Test default web page: http://nessus.org/plugins/index.php?view=single&id=11422
Checks if the web server is not configured, checking if the first page
displayed is the server's default.

Web Server Traversal: http://nessus.org/plugins/index.php?view=single&id=10297
Tries to access files in the server that are in different directories
than the web server's.
This feature is already implemented (in a smaller scale) by http-passwd.nse

Retrieve internal IP using HTTP Headers:
http://nessus.org/plugins/index.php?view=single&id=10759
Checks if HTTP Headers are disclosing internal IP Addresses

Web Mirroring: http://nessus.org/plugins/index.php?view=single&id=10662
Makes a mirror of the web site and tries to identify any CGI

HTTP Protocol Version Detection:
http://nessus.org/plugins/index.php?view=single&id=10582
Detects which version of HTTP is supported

Test HTTP Dangerous Methods:
http://nessus.org/plugins/index.php?view=single&id=10498
Test if HTTP Server allows PUT and DELETE methods

Arbitrary File Access with ~nobody/:
http://nessus.org/plugins/index.php?view=single&id=10484
Test if it is possible to access arbitrary files on the server
appending ~nobody/ in the beginning of the requested url (this happens
due to server misconfiguration).

Too long POST command: http://nessus.org/plugins/index.php?view=single&id=10687
Tests if it is possible to run arbitrary code on the server sending a
too long argument to a POST command.

Apache Tomcat Default Error Page Version Detection:
http://nessus.org/plugins/index.php?view=single&id=39446
It is possible to discover Tomcat's version using its error page.

Thanks,
João

On Sun, Jul 26, 2009 at 7:34 AM, Rob
Nicholls<robert () everythingeverything co uk> wrote:
> Hi Joao,
>
> Here are some of my thoughts after reading your interesting ideas:
>
> You mentioned only scanning "common directories" to improve performance.
> Another (optional?) way to improve performance would be to check for case
> insensitive web servers (e.g. IIS) as we can do a single check for
> /phpmyadmin/ rather than /phpMyAdmin/ and /phpmyadmin/ and /PHPMyAdmin/.
> This might be less useful if someone spoofs the server header though.
>
> It may be useful to run the http-enum script before http-spider (or whatever
> it's going to be called), with a way of passing the information across
> (similar to how the smb-based scripts work?), but I suspect that's already
> planned.
>
> I would imagine Nessus' XSS detection involves sending a malicious request
> and checking if it can be seen within the response (I've not sniffed the
> traffic myself, yet). Other tools I've seen can use a unique attack (e.g.
> <script>alert(461327);</script>, where the random number changes between
> attacks) when submitting POST or GET requests in case the attack isn't
> immediately returned, but is seen a few pages later (e.g. a shopping cart
> might be vulnerable a page or two later on the confirmation page when
> everything is displayed again). That would require extra work (and a lot
> more memory?) to track the source URL and variable name against the unique
> number and then checking every page for our attacks (presumably using a
> regular expression to detect the attack and then compare the number to the
> list of numbers).
>
> I'm not sure we can avoid potentially changing the state of the web server,
> as we don't know for sure that GET requests won't permanently affect the
> output (they shouldn't, but you never know). Equally, most user input
> nowadays tends to be sent as a POST request (especially ASP.NET content,
> usually because the VIEWSTATE has to be returned), so avoiding POST requests
> would severely limit the effectiveness of a scanner. But it might be
> sensible to start off with a GET-based XSS scanner that only checks for
> reflected XSS.
>
> Talking of ASP.NET's VIEWSTATE, that might be another way to improve
> performance, by decoding the VIEWSTATE information so we know which fields
> cannot be manipulated (e.g. drop down lists), so we can focus on the ones we
> can play with (typically date fields and strings).
>
> Most of the automated web app tools I've used will struggle to detect/follow
> JavaScript based URLs, so it'd be great if we can get it (mostly) working.
>
> Rob

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