From: Javier Fernandez-Sanguino (jfernandez@germinus.com)
Date: Tue Jul 19 2005 - 06:04:31 EDT
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
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:36 EDT