Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: ACK is being sent with a sequence of 0 every time.
From: James Rogers <jamesmrogers () gmail com>
Date: Wed, 13 Jun 2012 15:58:28 -0400

Thanks for the other comment location and the revision log number.  I
will read that.

I'll try  get_random_u32() there to see what effect that has.

On Wed, Jun 13, 2012 at 3:47 PM, David Fifield <david () bamsoftware com> wrote:
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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]