Re: Nmap marking ports with invalid SYN+ACK TCP checksums as open?

[Daniel Miller <bonsaiviking () gmail com>]

On Mon, Jun 23, 2014 at 7:50 AM, Jacek Wielemborek <d33tah () gmail com> wrote:

> List,
>
> Yesterday I discovered that if Nmap receives a SYN+ACK during a
> SYN scanning that has an invalid TCP checksum, it will say that
> this port is open. This is different than how operating systems
> behave and exploiting it sounds like an easy way to confuse the
> scanner.
>
> Why is it implemented this way? bonsaiviking on IRC suggested it
> might be "that we'd rather not miss an open port just because of
> a bitflip error somewhere". Still, this might be an interesting
> piece of information that the host is responding with corrupt
> checksums, so maybe Nmap should at least print a warning message
> if this happens?
>
> Yours,
> Jacek Wielemborek
I am divided on this question: on the one hand, I don't see that checksum
validation would be a big benefit, since the likelihood of running into
this in the Real World is pretty small. On the other hand, it wouldn't
really add that much overhead, and it would be more correct. I guess I'd
just like to have some way of knowing that an invalid TCP checksum
happened, in the end.

Right now, if I scan a host with -sS and it is sending invalid checksums, I
can fall back to -sT and get the "real" answer. But if we consider a bad
checksum to be "not open", then the user has no way of knowing that a reply
of any kind was sent (short of --packet-trace).

If we do add checksum validation, I would not suggest adding a new option
to turn it on, but instead choosing a scan type that makes sense (-sS) and
integrating it there. At that point, we need a status for such a port
(Jacek suggests "open|filtered", which sounds fine), and a reason code
(likely have to add a new one).

Finally, I would say that we should not accept this new status on the basis
of a single reply packet, since that could simply be the result of a
bitflip error. Instead, we should probably retry a few times, just like a
normal TCP client would.

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