Indeed, a couple of truly fascinating consequences result from our ability to map out the dynamics of a sequence number generator in a particular system and from the fact that most implementations exhibit certain more or less unique phase-space patterns. The most obvious trick is the application of ISN probing to old-school system fingerprinting.
By observing a couple of sequence numbers acquired from a remote system (for example, when a party attempts to establish several connections to a server) you can attempt to find an attractor to which this data fits best, by comparing the observed sample against a library of known attractors. (The numbers don’t need to be predictable using the attack technique described; the attractor for a system need only be distinct.)
When compared with traditional, passive fingerprinting, this method usually provides us with less detailed insight into the system’s configuration, but it is also nearly foolproof. To thwart the technique, you would have to modify the way sequence numbers are generated, but it is usually impossible to significantly tweak ISN-generation settings from the user space, and a modification of the kernel without degrading security usually requires a good dose of knowledge and skill (not to mention, access to the sources).
But, is that all? Of course not!
Pictures and theory aside, it would be good to see how an ISN sampling works in the real world and how can it help to assess the configuration of a remote system or identify its instances. Fortunately for me, there is a program worth mentioning.
After reading my TCP/IP ISN analysis paper, Toni Vandepoel wrote a great tool called ISNProber. ISNProber uses sequence number analysis to differentiate among several instances of the same system, based on the observation that two distinct systems are likely to be at different locations in the attractor.
At its most trivial, ISNProber can tell that two systems are hiding behind a shared address, based on the appearance of observed ISNs. For the sake of simplicity, let’s assume that system Y uses an increase-by-one ISN-generator design. We approach an IP address of a website www.example.com and want to determine how many systems there are. We first identify www.example.com as system Y, establish several subsequent connections, and then observe ISNs as follows: 10, 11, 534, 13, 540, 19.
It should be obvious that the lower numbers form a sequence originating from a computer that either handled less traffic or has a lower uptime (10, 11, 13, 19), whereas the higher numbers correspond to the other system. Hence, two computers are “co-serving” the same public IP, perhaps behind a load balancer. Furthermore, by varying sampling intervals, we can carefully examine the type of load balancer, its request distribution policy, and the traffic it receives.
This approach can not only differentiate systems hiding behind a common address, but also track users of system Y as they hop from one IP to another, for as long as they do not reboot their machine (and hence reset the ISN counter). For systems that offer ISN-generation schemes more sophisticated than the one in our example, the distinction can be more difficult, but it is certainly possible, as long as the ISNs are not purely random on all 32 bits. (If they are, collision-related concerns arise.)
The approach used here simply requires that a dose of predictability be present in the ISN-generation algorithm. As such, TCP/IP initial sequence analysis seems to be a promising alternative or addition to traditional passive fingerprinting—and can, quite regrettably, serve as a useful tool for privacy invasion and user tracking, too.