Re: "tcpwrapped" false positives

[Daniel Miller <bonsaiviking () gmail com>]

On Fri, Jan 2, 2015 at 3:37 PM, <nnposter () users sourceforge net> wrote:

> I am regularly observing incorrect "tcpwrapped" results where the
> targeted service is simply killing the null probe connection before
> nmap itself does. (Most recently I have noticed it on ArubaOS
> Management WebUI, which is HTTPS-based and it terminates the connection
> after 5 seconds.)
A service is marked as tcpwrapped if the connection is terminated at any
time during the NULL probe. The relevant code contains a TODO item:

     if (probe->isNullProbe() && readstrlen == 0) {
      // TODO:  Perhaps should do further verification before making this
assumption
      end_svcprobe(nsp, PROBESTATE_FINISHED_TCPWRAPPED, SG, svc, nsi);

The same TODO happens a bit further down, triggered by various paths that
all mean "remote host hung up." At this point (end_svcprobe), we stop
sending service probes: the port is declared tcpwrapped, and there's no
going back (except for NSE!)

Looking for a solution, I came across an old post [1] that pinpoints
> the relevant nmap code and proposes an enhancement but the attached
> patch seems to be based on incorrect understanding of the nmap data
> structures.
>
> [1] http://seclists.org/nmap-dev/2013/q3/574
>
> The patch below follows the same enhancement logic (a service is
> considered "tcpwrapped" only if the connection is closed quickly)
> but the implementation is different than the original patch. In
> a nut shell:
>
> 1. Defines TCPWRAPPED_TIMEOUT=2000. Connections closed after this
> timeout expires are not considered "tcpwrapped".
>
> 2. Implements new method ServiceNFO::probe_timemsused(), which
> returns how long the probe connection lasted. The method is a logical
> complement of existing sibling probe_timemsleft(). This old method
> has been reimplemented as well to avoid code duplication.
>
> 3. Adds check probe_timemsused() < TCPWRAPPED_TIMEOUT in two locations.
I think this is a problem that ought to be addressed, but I'm not sure this
is a complete solution. Here are some of my thoughts:

First, having a compiled-in time limit like that is not ideal. A similar
concept is the "totalwaitms" config item in nmap-service-probes, so if we
end up going with a time-based approach, that would be a better way to do
it.

Second, I'm not sure that 2 seconds is an appropriate time. Here's how a
tcpwrappers rejection works, and why it's not an instant rejection:
1. We open a TCP connection to the host. I'm not certain of whether the
handshake time counts toward the time left for the probe, but I think it
does, since Nsock is asynchronous.
2. The host checks our address against its black- and white-lists. This
oftentimes requires a reverse DNS lookup, and may even include an ident
lookup. This is the primary source of delay.
3. The host resets the connection: half a round-trip for the RST packet to
reach us.

If the TCP handshake time is counted against us, that's a minimum of 2 RTTs
plus processing time, and likely slower than that for a reverse DNS lookup
on our scanner.

Lastly, we'd have to consider how this change might affect the services
that NSE scripts currently trigger on based on the "tcpwrapped" status. As
far as I remember, this is only JDWP, but I don't know (precisely because
of the existing behavior) whether any JDWP implementations respond to any
of our subsequent probes. This is likely to be a net-positive change,
though, because if they *do* respond to our probes, we'd save executing
these scripts on every service that shuts down the connection quickly.

Dan

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/