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.
