‘TCP Timestamp and Advanced Fingerprinting’
‘The information has been provided by Erwan Arzur .’
‘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
. . . . . . . . . . . . . . . . . . . . . .
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
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.
Can your Firewall block timestamps? Otherwise try seeing if your kernel has support for it: $ sysctl -a | grep tcp_timestamps‘