Re: ACK is being sent with a sequence of 0 every time.

[David Fifield <david () bamsoftware com>]

On Wed, Jun 13, 2012 at 03:35:50PM -0400, James Rogers wrote:
> As I was working on the spurious port closed bug I noticed something
> strange: we don't set a sequence number in the ACK packets we send.
>
> SENT (0.5123s) TCP 10.0.1.103:46853 > 74.207.254.18:80 A ttl=44
> id=49043 iplen=40  >>>>>  seq=0  <<<< win=1024
>
> as you can see the seq=0.
>
> According to what I think I am reading ACK packets are supposed to
> have a sequence number set too.   It is a big red flag to always be
> sending the same seq number in the same kind of packet.
>
> In "scan_engine.cc" [Modified] line 3372 of 6239
>
> if (pspec->pd.tcp.flags & TH_ACK)
>     ack = seq32_encode(USI, tryno, pingseq);
> else
>     seq = seq32_encode(USI, tryno, pingseq);
>
> So the ack packet will not set a sequence number.   When I tried this:
>
> if (pspec->pd.tcp.flags & TH_ACK)
>     ack = seq32_encode(USI, tryno, pingseq);
>
> seq = seq32_encode(USI, tryno, pingseq);
>
> it worked in adding a seq to the ACK segment, but the send to 443 and
> to 80 then had the same seq number, which would just be confusing.
>
> Would like input on how to proceed here.  Of if this is even a bug.

There is a good reason for this. You probably saw the comment
immediately above the code you quoted:

    /* Normally we encode the tryno and pingseq in the SEQ field, because that
       comes back (possibly incremented) in the ACK field of responses. But if
       our probe has the ACK flag set, the response reflects our own ACK number
       instead. */

This goes along with another long comment in tcp_probe_match:

    /* We are looking to recover the tryno and pingseq of the probe, which are
       encoded in the ACK field for probes with the ACK flag set and in the SEQ
       field for all other probes. According to RFC 793, section 3.9, under
       "SEGMENT ARRIVES", it's supposed to work like this: If our probe had ACK
       set, our ACK number is reflected in the response's SEQ field. If our
       probe had SYN or FIN set (and not ACK), then our SEQ is one less than the
       returned ACK value because SYN and FIN consume a sequence number (section
       3.3). Otherwise, our SEQ is the returned ACK.

       However, nmap-os-db shows that these assumptions can't be relied on, so
       we try all three possibilities for each probe. */

See also the long log message for r15986, where this change was introduced.

So the encoded tryno and pingseq definitely need to go in the ack field
for packets with the ACK flag set. I don't know if seq has to be 0 or
not. If not, we can just set it with get_random_u32.

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