Advices request for new fingerprints

[赵雷 <zhaolei () gmail com>]

Hi there,

    I am now working on creating next generation of OS detection, one
of Nmap-Soc projects. We want to find more fingerprints to add into
nmap, thus let nmap provide more granular and accurate results. In the
past few days, Fyodor and I made an investigation on the RFCs, other
OS detecting tools and suggestions from Michal Zalewski (p0f's author)
and found something worth to add. The draft list of these fingerprints
is below.

    We want to hear your advices. If there are any other fingerprints
worth to add, if you think some on the list is not worth to add, or if
you have any opinion on any fingerprints on the list, please let us
know. Any advices from you would be appreciated.

Best Regards,
Zhao Lei


List of fingerprints:

 1) Initial TTL
 2) IPid Field pattern (two more patterns)
 3) TCP SACK Option
 4) Results in different combinations/orderings of options probe
 5) TCP Window Scale Option *value*
 6) ECN Support
 7) Data payload in RST+ packet
 8) Invalid Second timestamp value
 9) Invalid ACK flag, ACK value and SEQ value in RST replies
 10) URG pointer value when URG flag not set
 11) "Unused" field not zero

And also I am now testing 2 other fingerprints to check whether they
are worth to add (I hope I'll get a good result in tomorrow morning):
 - IP options
 - ICMP echo reply

1) Initial TTL

# Description: Time To Live field in IP head. Different OS uses
  different TTL when creating a IP packet.

2) IPid Field pattern

# Description: IP identification field is a bit used to make packets
  unique for fragment reassembly. Different OS use it in different
  way. In addition to the patterns that nmap already checks (you can
  check them at the "IPID sampling" paragraph of Fyodor's article:
  http://www.insecure.org/nmap/nmap-fingerprinting-article.html),
  there exist two other patterns according to some articles:

   o "Some versions of Solaris use separate counters for each <source,
     destination, protocol> triple." (from "A Technique for Counting
     NATted Hosts")
 
   o "Linux - The host sets the IPID to zero on SYNACK segments, and
     then uses a per-connection incremental IPID for data packets with
     a randomized start." (from "syscan")

3) TCP SACK Option

# Description: There are many current OSes that implement TCP
  Selective Acknowledgment Options (RFC2018, RFC2883). It's a nugget
  in the gold mine. Whether the option is set or not and its position
  in the all options in the reply packet give much information about
  the OS.

4) Results in different combinations/orderings of options probe

# Description: Use different combinations/orderings of options for
  each of the probes. Destination hosts may expose differences based
  on how they pack responses to different option combinations.

5) Window Scale Option *value*

# Description: Nmap already uses this option, but doesn't check its
  value. Since initial WSCALE value is also OS related, we will check
  its value too.

6) ECN Support

# Description: RFC3168 (The Addition of Explicit Congestion
  Notification (ECN) to IP) defines a mechanism to let the routers
  have another way (other than drop packets) to notify endpoints about
  the congestion in the network. To use ECN, transport protocol
  implementions of endpoints must first exchange information about
  their willingness to use ECN. For TCP (the only transport protocol
  this rfc addresses), this is done in TCP connection setup phase
  using two bits in TCP header. The rfc gives a new definition of
  bytes 13 and 14 of the TCP Header:

    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  |               |               | C | E | U | A | P | R | S | F |
  | Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
  |               |               | R | E | G | K | H | T | N | N |
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   CWR: Congestion Window Reduced
   ECE: ECN-Echo

  The ECN-setup process for TCP is as following:

   o A (sender) sends an ECN-setup SYN packet (ECE and CWR flags set)
     to B (receiver);

   o B sends an ECN-setup SYN-ACK packet (only the ECE flag set but
     the CWR flag not set) to A.

  According to the RFC, "there exists at least one faulty TCP
  implementation in which TCP receivers set the Reserved field of the
  TCP header in ACK packets (and hence the SYN-ACK) simply to reflect
  the Reserved field of the TCP header in the received data packet",
  and "There exist some middleboxes (firewalls, load balancers, or
  intrusion detection systems) in the Internet that either drop a TCP
  SYN packet configured to negotiate ECN, or respond with a RST".
  Furthermore, since ECN has remained for a long period (nearly 3
  years) in Experimental status (RFC2481), some OSes support the
  specification in RFC2481. One of the differences between the two RFC
  is that the ECN-setup SYN in RFC2481 only needs to set the ECE
  flag. And this causes differences too.

  There are about 7 possible responses to our two ECN-setup SYN
  packets (only ECE set, both ECE and CWR set) to an open port. And
  the difference is what we can use in OS detection.

7) Data payload in RST+ packet

# Description: "Data past headers on RST/RST+ACK packets is a very
  valuable source of OS information, particularly for Solaris, MacOS,
  HP/UX. Those systems reply with a textual description of the reason
  RST+ACK is being sent in the payload of the packet." (p0f)

  We will check the payload we get from RST+ packet: if there is
  payload, the detail of the payload.

8) Invalid Second timestamp value

# Description: Check if the second timestamp (the reply one) is set to
  zero correctly in various responses. "The RFC specifies when the
  second timestamp should be zero and when not, and most people get
  confused about it."

9) Invalid ACK flag, ACK value and SEQ value in RST replies

# Description: " The RFC says there are two types of RST responses
  acceptable:

   Plain RST in response to packets with no ACK flag. SEQ set to the
   ACK number from the original packet, ACK value unspecified. This
   is a valid "connection refused" response. The ACK field is zeroed
   on some systems (like Linux), is not one some others.

   RST+ACK in response to packets with ACK flag. SEQ must be zero,
   ACK set to the SEQ number of the original packet plus its
   size. This is the usual "unexpected traffic" response.

  Both can be triggered on machines with no open ports. A number of
  systems, including Windows, FreeBSD and Linux, tends to reply with
  invalid combinations in certain conditions (some even reply with
  RST+ACK to packets with ACK set). "

  Nmap now check flag and ACK value in TCP RST+ packet, but doesn't
  check SEQ. Since "There is a total of 10 possible combinations of
  ACK flag, ACK value and SEQ value", it is worthwhile to include this
  one.

10) URG pointer value when URG flag not set

# Description: Check if URG pointer is not zero when URG flag is not
  set. "Certain boxes, particularly some firewalls, have it set to a
  fixed value such as 0xcccc (URG), whereas other machines tend to
  leak memory there (Windows, for example, see my recent BUGTRAQ
  post)." 

11) "Unused" field not zero

# Description: Check if any "unused" field. There are two kind of
  packets in nmap have "unused" field: the "unused" field in ICMP type
  3 (we get this when send a UDP packet to a closed port) and the
  "Reserved" field in TCP.


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev