[REVS] TCP Timestamp and Advanced Fingerprinting

From: SecuriTeam (support_at_securiteam.com)
Date: 03/29/05

  • Next message: SecuriTeam: "[UNIX] Sun AnswerBook2 Arbitrary Script Injection and Cross Site Scripting" 
    To: list@securiteam.com
Date: 29 Mar 2005 19:04:22 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      TCP Timestamp and Advanced Fingerprinting
    ------------------------------------------------------------------------

    SUMMARY

    This network oriented advisory explains how to fingerprint network
    services on a remote host. After reading this paper you will be able to
    circumvent the illusion given by IP masquerading that network services are
    hosted by a single computer.

    DETAILS

    On March 11st 2001, Bret McDanel published an introduction on the feature
    of the netcraft.com website to offer it's visitors an overview about the
    current and average uptime of specific operating systems running on the
    machines that provide the base for popular websites.

    TCP timestamping (optional TCP field) is explained in RFC (Request For
    Comments) 1323 and is a method used notably in PAWS (Protection Against
    Wrapped Sequence Numbers).

    But we will just keep in mind the elements brought to us by McDanel: the
    TCP timestamping is not of a security concern, however the way operating
    systems manage their TCP timestamping is "interesting": it allows a remote
    client to guess, if he recognizes the operating system (OS
    fingerprinting), the time the machine is up.

    When you start up your BSD, by example, the operating system increments,
    as explained by McDanel, the timestamp value of one point each 500
    milliseconds. By grabbing the value of timestamp of such operating system
    you can guess for how long it is still running.

    The RFC does not give many indications on how timestamps should be managed
    inside operating systems, only that it should increase according to the
    fact that "it must be at least approximately proportional to real time".

    Here is the format of this optional TCP field:
        1 1 4 4
    +--------+-------------+-----------------------+--------------------------+
    |Kind=8 | size =10 | TS Value (TSval) |TS Echo Reply (TSecr)|
    +--------+-------------+-----------------------+--------------------------+

    There are a few limitations that appear in the prediction of the actual
    uptime.

    First the length of a timestamp value in a TCP packet is 4 bytes, so it
    will roll over when the value crosses the limit of 2^32. Additionally,
    some operating systems (Windows being the example from McDanel), may not
    instantly start to increase their timestamp once the system has been
    booted up.

    TCP timestamps values are inserted in many TCP packets (such as SYN,
    ACK...) but timestamp replies are mainly part of ACK packets. RFC 1323
    gives the following schema:

    TCP A TCP B

    <A,TSval=1,TSecr=120> ------>
    <---- <ACK(A),TSval=127,TSecr=1>

    <B,TSval=5,TSecr=127> ------>
    <---- <ACK(B),TSval=131,TSecr=5>

     . . . . . . . . . . . . . . . . . . . . .

    <C,TSval=65,TSecr=131> ------>
    <---- <ACK(C),TSval=191,TSecr=65>

    The TCP stacks of Linux kernels (2.4 and 2.6) natively set a timestamp
    value in their SYN packets, but Windows-based operating systems does not.

    The TCP stacks of Linux kernels (2.4 and 2.6, again...) natively set a
    timestamp value in SYN/ACK packets, but again Windows does not.

    So, now you should be able to understand that it is important to analyze
    how various TCP stacks react with setting their timestamps inside the
    packets if we want to take advantage of these differences.

    Breaking the masquerade:
    The first thing Clad Strife did was performing an experiment with a simple
    sniffer and common SYN packets sent from a Linux box. This test was
    intended to report if a specific operating system replies a timestamp
    value (TSval) in a SYN/ACK packet and if the incrementation is predictable
    (you may predict on two successive connections that next value in second
    connection will be higher than in first).

    +======================+=================+==============+===================+
    | Operating system | answers a TSval*| use TSval | predictible
    TSval |
    +======================+=================+==============+===================+
    | Linux 2.6/grsec | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | Linux 2.6 | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | OpenBSD 3.6 | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | FreeBSD 5.3 | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | NetBSD 2.0 | No | Yes | No
     |
    +----------------------+-----------------+--------------+-------------------+
    | Windows 2000/SP4 | No | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | Windows XP/SP2 | No | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | Windows 2003 | No | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | MacOS X | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | Solaris 9 | Yes | Yes | Yes
     |
    +----------------------+-----------------+--------------+-------------------+
    | OSF1 4.0 | No | No | -
     |
    +===========================================================================+
    *: in SYN/ACK packet

    It can be noted that some systems are less verbose than other during the
    three way handshake connection.

    The side note that the timestamp is predictable (or quite predictable at
    least) bears a subtle reason: if the timestamp were to be defined randomly
    or zeroed for each new connection, it would be quite impossible to compare
    it to existing data we already collected.

    So, what is this all about now ? First, the implementations of packets
    carrying timestamps and other packets not carrying timestamps in the
    different operating systems allows for a possible distinction of the
    operating systems that have generated those packets.

    Second, it would be possible to differentiate between machines where the
    packets are coming from by looking at and comparing separate timestamp
    values.

    And last but not least, looking at TTL values should also reveal the
    relative "distance" in hops to the machine providing the services you are
    looking at.

    That means, for example, that you may be able to detect whether a given
    web site runs on only one web server or multiple machines behind some kind
    of firewall or load balancer, sitting in a local LAN and being presented
    with only one global IP to the WAN.

    Another strong advantage of the proposed method is that you can enumerate
    the machines behind an IP masquerade, and, with timestamp analysis, link
    together the web services with the corresponding system. It is the method
    implemented in the proof-of-concept software I designed.

    $ ./masqb 10.42.42.42 21 22 80 443
    (...)
    Results for 10.42.42.42 :
    [+] System A listens the following ports : 21
    [+] System B listens the following ports : 22
    [+] System C listens the following ports : 80 443
    Game over.

    As Windows sends timestamp values in each established connections, only
    NetBSD and OSF1 are not covered by this problem.
    NetBSD 2.0 initializes timestamp at 0 in each new connection, OSF1 does
    nothing.

    If services are forwarded on both a Linux system and a NetBSD, you should
    be able to easily detect it.

    If services are forwarded from a set of homogeneous NetBSD or OSF1
    systems, then you will hardly obtain any valuable results.

    Finishing this advisory, I can conclude that this technique applies to the
    magnitude of systems available on the public Internet.

    The only thing you need is at least two open ports with services accepting
    and serving incoming connections (one port for load balancing detection).

    It has already been successfully used for retrieving information about
    network physical infrastructures and network services behind firewalls and
    various forms of routers.

    Solution:
    Can your Firewall block timestamps? Otherwise try seeing if your kernel
    has support for it: $ sysctl -a | grep tcp_timestamps

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:erwan@lse.epita.fr> Erwan
    Arzur .

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[UNIX] Sun AnswerBook2 Arbitrary Script Injection and Cross Site Scripting"

    Relevant Pages