Re: Rooting out false positives

[Javier Fernandez-Sanguino <jfernandez () germinus com>]

Omar Herrera wrote:
> This is, in my opinion, one of the things that should distinguish a good
> pentester. Unfortunately, this is not an exact science and customers hardly
> recognize it.

I agree wholehartedly here.

> My approach resembles a spiral (you could also use decision trees to
> implement it), is just a progressive method to refine the results and goes
> more or less like this:

There's a slight issue with your approach, in writing it seems ok, but 
when you are "out there" it turns out many people are using mixed 
equipment which can lead to different (TCP/IP) fingerprints, ttls, 
etc. due to the network side of things. The problem is, an IP address 
does not any longer identify an end host you can have all sorts of:

- NAT tricks, this includes network balancer tricks (aka Alteon and 
similar equipment, which will redirect different ports to different 
servers)

- Reverse proxies, in which the service banner and the identified OS 
(via fingerpringint) do not match for a given IP address. These might 
be as simple as a port redirector and as complex as an inline 
application level firewall. Nowadays, many firewalls are 
reimplementing these features but rebranding them (e.g. Check Point's 
Firewall-1 NG "Application Intelligence"). In these cases you might 
even have conflicting identifications, in some cases the answer is 
returned by the end server, in other's it's the firewall's answering 
that it blocked an attack attempt. Inline IPS or IDS with blocking 
will have a similar impact in the identification phase.

At one point in time I added to my TODO list an ACT_END plugin in 
Nessus that would review the vulnerabilities found and tell you: "this 
is an unpatch X operating system version Y". Turns out it will only 
work if you are scanning with full network visibility (i.e. no inline 
devices that might introduce false positives or false negatives) and 
in this cases it's rather trivial to tell what are you "seeing" in the 
other end.

As to how to flag false positives, here's my 2c (which is quite 
similar to what you already said)

- if the scanner provides information that couldn't have been obtained 
without exploiting the vulnerability (like an internal IP address, a 
file content, etc.) that would prove it's not a false positive.


- if the additional information is empty then you flag it as a 
possible false positive and try to approach the vulnerability 
directly, if you are not succesful (or exploitatition is not an 
option) then bring it up in the report ("there might be...") and 
discuss it with the people in charge of the system.

In the original sample (which is Nessus Plugin #10481: "(...)We  could 
collect the list of databases installed on the remote host"  I would 
certainly _not_ consider it a false positive if it provided the list 
of databases and would be suspicious if the database list where empty.

Regards

Javier