COMMAND

    kernel (ICMP)

SYSTEMS AFFECTED

    Many, if not all

PROBLEM

    Ofir  Arkin  found  following.    Some  operating  systems,   when
    receiving an ICMP Query message with the DF bit set, would set the
    DF bit  with their  replies as  well.   Sometimes it  would be  in
    contrast with their regular  behavior, which would be  not setting
    the DF Bit in  their replies for a  regular query that comes  with
    the DF bit not set.

    A. DF Bit Echoing with the ICMP Echo request
    ============================================
    The snort trace below illustrates  an ICMP Echo request sent  from
    a Linux box, using nemesis, to a Sun Solaris 2.7 machine:

        [root@aik /root]# nemesis-icmp -i 8 x.x.x.x
        08/10-15:24:21.625260 10.0.0.105 -> x.x.x.x
        ICMP TTL:64 TOS:0x0 ID:13670 DF
        ID:62979   Seq:0  ECHO
        
        08/10-15:24:22.623507 10.0.0.105 -> x.x.x.x
        ICMP TTL:64 TOS:0x0 ID:43567 DF
        ID:62979   Seq:256  ECHO
        
        08/10-15:24:23.318173 x.x.x.x -> 10.0.0.105
        ICMP TTL:239 TOS:0x0 ID:221  DF
        ID:62979   Seq:0  ECHO REPLY
        08 8C 02 85 1C 2A 7F 32 AB 14 6C 79 F5 2E 53 84  .....*.2..ly..S.
        AF 15                                            ..
        
        08/10-15:24:23.555488 x.x.x.x -> 10.0.0.105
        ICMP TTL:239 TOS:0x0 ID:222  DF
        ID:62979   Seq:256  ECHO REPLY
        BE 13 02 8F 90 8F 15 93 94 93 04 97 98 97 16 9B  ................
        9C 9B                                            ..

    Most of the operating systems  checked did the same thing.  In the
    reply they produced, the DF bit was set.  Which operating  systems
    are  the  exceptional  and  do  not  echo  back the DF bit?  Linux
    Kernel  2.2.x,  Linux  Kernel  2.4  with the various test kernels,
    Ultrix v4.2 and 4.5, and Novell Netware.

    How can we distinguish  between those operating systems?   Frankly
    it is quite simple.  Since LINUX and Ultrix are using a TTL  field
    value of 255 in their ICMP Query replies, and Novell Netware  uses
    128, it is easy to distinguish between those groups.

    B. DF Bit Echoing with the ICMP Address Mask request
    ====================================================
    With ICMP Address Mask requests we have a different story.   Among
    the operating systems  that Ofir checked  that answer for  an ICMP
    Address Mask request Sun Solaris  & OpenVMS echo back the  DF bit.
    Microsoft Windows 98, Microsoft Windows  98 SE, and Ultrix do  not
    echo back the DF bit.

    Again  it  is  very  simple  to  distinguish between the Microsoft
    Windows 98  family and  between the  Ultrix machines.   Since  the
    Microsoft Windows 98 family is using 128 as their TTL field  value
    in  their  ICMP  query  replies  and  Ultrix  uses  255,  we   can
    distinguish between those operating systems.

    We  have  here  a  simple  method to distinguish between Microsoft
    Windows  98  /  98  SE,  and  Ultrix  machines  to the rest of the
    operating systems world.

    Another interesting  piece of  information is  that the  Microsoft
    Windows 98 family  changed its behavior  from DF echoing  with the
    ICMP  Echo  request  to  not  echoing  with  the ICMP Address Mask
    request.   This  inconsistency  is  a  factor  with  all Microsoft
    operating systems  (Echoing with  ICMP Echo  request, not  echoing
    with the other types of ICMP query).

    C. DF Bit Echoing with the ICMP Timestamp request
    =================================================
    Since a lot more operating  systems answer for an ICMP  Timsestamp
    request than  with the  ICMP Address  Mask request,  we have a bit
    more difficulty in identifing those.

    Linux with Kernel 2.2.x, Linux with Kernel 2.4, Ultrix,  Microsoft
    Windows 98/98SE/ME,  and the  Microsoft Windows  2000 Family would
    not echo back the DF bit with ICMP Timestamp replies they  produce
    for ICMP Timestamp request that sets their DF bit.

    Here we can only  distinguish between certain groups  of operating
    systems; again  it would  be according  to their  TTL field  value
    with their replies.

    Linux would use 255 as its TTL field value for the ICMP  Timestamp
    reply; Ultrix would use the  same value.  The Microsoft  family of
    operating systems that would answer  for this kind of query  would
    use 128 as their TTL value.

    Again we have Linux and Ultrix  on the one hand and the  Microsoft
    Family on the other hand.  How can we further distinguish  between
    those?

    D. Using all of the Information in order to identify maximum of operating systems
    =================================================================================
    We can group Linux and Ultrix with the ICMP Echo requests.  We can
    do the same with Microsoft Windows  98 / 98 SE & Ultrix  using the
    ICMP Address Mask requests.   This would allow us to  pinpoint the
    Linux boxes from the  first stage.  So  when we would go  into the
    third stage we would know which operating systems are Linux based,
    which are Microsoft Windows 98 / 98 SE based, and which are Ultrix
    based.  This would leave us with Microsoft Windows ME and with the
    Microsoft Windows 2000 family machines.

    E. Why this would work (for the skeptical)
    ==========================================
    All those skeptical would say  that if they receive an  ICMP Query
    request with the DF bit set than it should be clear that something
    is  wrong  and  someone  is  probably  trying to scan them.  Think
    again.  What would happen if  a Solaris box would query your  box?
    Than  the  same  behavior  would  be  produced  since Sun Solaris,
    OpenBSD  and  HPUX  all  set  their  DF bit with the requests they
    produce.

    This is  an ICMP  Echo request  sent from  a Solaris  2.6 box to a
    Linux box.  We can see that the DF bit is set with the request and
    not set with the  reply.  But again  if some one would  mimic this
    behavior with a tool used on a Linux box to query the world, which
    is 100% mimicking Solaris  than we would never  know if this is  a
    legit request or an attempt for scanning / fingerprinting.

        Initializing Network Interface...
        Decoding raw data on interface ppp0
        
        -*> Snort! <*-
        Version 1.6
        By Martin Roesch (roesch@clark.net, www.clark.net/~roesch)
        08/10-23:32:52.201612 y.y.y.y -> 139.92.207.58
        ICMP TTL:239 TOS:0x0 ID:48656  DF
        ID:2080   Seq:0  ECHO
        39 93 10 A3 00 03 F0 E5 08 09 0A 0B 0C 0D 0E 0F  9...............
        10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................
        20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./
        30 31 32 33 34 35 36 37                          01234567
        
        08/10-23:32:52.201649 139.92.207.58 -> y.y.y.y
        ICMP TTL:255 TOS:0x0 ID:349
        ID:2080   Seq:0  ECHO REPLY
        39 93 10 A3 00 03 F0 E5 08 09 0A 0B 0C 0D 0E 0F  9...............
        10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................
        20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./
        30 31 32 33 34 35 36 37                          01234567

    Operating systems  that Ofir  checked are:  Linux Kernel  2.4 test
    2,4,5,6; Linux  Kernel 2.2.x;  FreeBSD 4.0,  3.4; OpenBSD 2.7,2.6;
    NetBSD  1.4.1,1.4.2;  BSDI  BSD/OS  4.0,3.1;  Solaris 2.6,2.7,2.8;
    HP-UX  11.0;  Compaq  Tru64  5.0;  Aix 4.1,3.2; Irix 6.5.3, 6.5.8;
    Ultrix 4.2  – 4.5;  OpenVMS v7.1-2;  Novel Netware  5.1 SP1,  5.0,
    3.12;  Microsoft  Windows  98/98SE/ME,  Microsoft  Windows NT WRKS
    SP6a,  Microsoft  Windows  NT  Server  SP4, Microsoft Windows 2000
    Family.

SOLUTION

    Nothing yet.