[tcpm] Re: Security concerns with relative timestamp exposure through TCP ISNs

[Aaron Rainbolt <[e-mail]>]

On Sat, 2 Nov 2024 23:37:06 -0700
Yoshifumi Nishida <[e-mail]> wrote:

> Hi Aaron,
> 
> Thanks for bringing a very interesting topic to the WG.
> I have a naive question for this although I miss something as I'm not
> a security expert at all.
> I am guessing you'll need to collect a certain amount of ISN samples
> for this, which means you'll need to open many connections.

True, it does require opening a large number of connections over a long
period of time.

> However, if you do so, it may look an anomaly behavior from server
> sides and could be detectable.

Theoretically yes, however it should be noted that this technique only
requires that one be able to establish a TCP connection to collect the
ISNs. If a blocking mechanism allowed a connection to be
established, but then immediately disconnected the connection after
observing the source IP address, it would be too late. I have not yet
researched at what point existing firewall capabilities in Linux reject
a connection, so I can't say for sure whether this is a concern or not.

Also worthy of note, because ISNs are sent both directions when a TCP
connection is established, the server may actually be the attacker,
rather than the client. For instance, a malicious web server could
serve a JavaScript page to a client that repeatedly connects and
disconnects from the attacking server, thus allowing the server to
collect ISNs from the client. These could then be used to monitor the
client's activity via clock skew measurements.

> Do you have any thoughts on this?
> 
> Also, is there any good way to mitigate the risks you've mentioned?

I had mentioned some potential ways in which the protocol could be
modified to mitigate risks in the initial email. As for mitigations
that are both spec-compliant and don't require spec modifications, one
way that would be spec-compliant would be to limit the number of times
in a row a new incarnation of a connection can be created while a
previous incarnation is still in the TIME-WAIT state. For instance,
only allow five "rapid reconnects" in a row, then force all
incarnations to have their TIME-WAIT states expire. Of course, this
would probably introduce painfully long connection delays in many use
cases, so I don't really think this is a good option. IMO modifying the
spec to make ISN generation not require a clock would be better. The
counter-based solution described in the second bullet point at the
bottom of my first email is the method I personally think would work
best, but it may have issues I'm not aware of.

Thanks for taking a look at this!
Aaron

> --
> Yoshi
> 
> On Wed, Oct 30, 2024 at 5:20 AM Aaron Rainbolt <[e-mail]>
> wrote:
> 
> > Greetings, and thanks for your time.
> >
> > I am a developer contributing to the Kicksecure and Whonix
> > projects. As part of my work, I did some research into potential
> > security issues related to how TCP Initial Sequence Numbers (ISNs)
> > are generated according to RFC9293. This is a report of my
> > findings, potential concerns, and ways in which these concerns may
> > be able to be alleviated. I've copied the lead Kicksecure developer
> > on this email.
> >
> > According to RFC9293 section 3.4.1, TCP ISNs must be generated as
> > follows:
> >  
> > > TCP initial sequence numbers are generated from a number sequence
> > > that monotonically increases until it wraps, known loosely as a
> > > "clock". This clock is a 32-bit counter that typically increments
> > > at least once every roughly 4 microseconds, although it is neither
> > > assumed to be realtime nor precise, and need not persist across
> > > reboots. The clock component is intended to ensure that with a
> > > Maximum Segment Lifetime (MSL), generated ISNs will be unique
> > > since it cycles approximately every 4.55 hours, which is much
> > > longer than the MSL. Please note that for modern networks that
> > > support high data rates where the connection might start and
> > > quickly advance sequence numbers to overlap within the MSL, it is
> > > recommended to implement the Timestamp Option as mentioned later
> > > in Section 3.4.3.
> > >
> > > A TCP implementation MUST use the above type of "clock" for
> > > clock-driven selection of initial sequence numbers (MUST-8), and
> > > SHOULD generate its initial sequence numbers with the expression:
> > >
> > > ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
> > >
> > > where M is the 4 microsecond timer, and F() is a pseudorandom
> > > function (PRF) of the connection's identifying parameters
> > > ("localip, localport, remoteip, remoteport") and a secret key
> > > ("secretkey") (SHLD-1). F() MUST NOT be computable from the
> > > outside (MUST-9), or an attacker could still guess at sequence
> > > numbers from the ISN used for some other connection. The PRF
> > > could be implemented as a cryptographic hash of the concatenation
> > > of the TCP connection parameters and some secret data.  
> >
> > The algorithm described here provides good reliability without
> > making it easy for an attacker to guess TCP ISNs. However, it
> > exposes a relative timestamp to both sides of the connection, data
> > which may seem non-sensitive but which is likely exploitable in
> > attacks.
> >
> > Relative timestamp data can, among other things, be used to
> > determine the relative temperature and system load of a remote
> > machine based on clock skew measurements. This is described in
> > Steven J. Murdoch's "Hot or Not: Revealing Hidden Services by their
> > Clock Skew".[1] The referenced paper describes several methods in
> > which this capability can be used to an attacker's advantage - the
> > primary issue covered is the ability to de-anonymize Tor hidden
> > services, however other issues that are covered include geolocation
> > and data transmission via a covert channel. The paper relies on TCP
> > timestamps, however as TCP ISNs are sent both ways by both peers in
> > a connection and can be easily obtained by opening and closing a
> > new connection, I believe they are a suitable alternative for TCP
> > timestamps. TCP ISNs are particularly useful in this context as TCP
> > timestamps can be disabled, but TCP ISNs cannot.
> >
> > The most obvious way I can think to exploit this is to use it to
> > distinguish computationally intensive operations from
> > computationally cheap operations, even if both take the same
> > approximate amount of time. For instance, an authentication system
> > for a server may run a computationally intenstive constant-time
> > password hashing algorithm if a provided username is present on the
> > system, but simply sleep for the duration of time needed to run
> > that algorithm if a provided username does not exist on the system.
> > In theory, this would be immune to timing attacks while reducing
> > resource consumption, however in practice the ability to extract
> > relative timestamps via TCP ISNs could be used to subvert this by
> > analyzing the remote system's clock skew. The skew would be
> > noticeably different for intensive operations than for cheap
> > operations, which could then be used to determine if the username
> > in question existed on the remote system. Obviously, a single login
> > attempt would probably not be enough to change the clock skew of
> > the victim system enough to matter, so the attacker would likely
> > have to make many login requests in parallel over a relatively long
> > period of time to achieve the desired effect. The "hot or not"
> > paper mentions that the capacity of the covert channel offered by
> > the attack is approximately 2 to 8 bits per hour, meaning that an
> > attacker could use this technique to enumerate usernames at a speed
> > of about 2 to 8 users per hour (possibly higher due to the clock
> > speed used for ISN generation) assuming the remote server was not
> > put under heavy load by another influence.[2]
> >
> > Another way this flaw could be used is for low-speed, hidden data
> > transfer. A "sender" machine can run any arbitrary TCP server (even
> > one that does not send or receive any visible data), while the
> > "receiver" machine can run a simple TCP client that connects to the
> > sender using a particular localip/localport/remoteip/remoteport
> > combo repeatedly. The receiver need only record the sender's ISN
> > from each connection and record it, then it can close the
> > connection. The sender can now transmit data (albeit very slowly
> > and inefficiently) to the receiver by modulating its system load.
> > The receiver will be able to observe the system load patterns based
> > on clock skew, and extract a binary sequence from that pattern
> > corresponding to the modulated system load of the sender. In this
> > way a machine could transfer sensitive data to another machine
> > without having to send visible data through the TCP connection.
> > Again, the speed of the transfer would only be about 2 to 8 bits
> > per hour, so this would mostly be useful for exfiltrating things
> > such as encryption keys from an already compromised server.
> >
> > Note that I have not actually tested the feasibility of these
> > attacks yet, however they seem like they would work in theory. I
> > believe I have the necessary equipment to test these in practice,
> > and can try this if it would be helpful.
> >
> > Ultimately, to mitigate this attack method, it is necessary to avoid
> > embedding any recognizable clock (relative or otherwise) in TCP
> > transmissions. However, this poses a challenge, as the monotonic
> > nature of TCP ISN generation is very useful for avoiding confusion
> > between old and new incarnations of a TCP connection. There are a
> > couple possible solutions I can think of that may help here:
> >
> > * RFC6528 mentions that "[s]imple random selection of the TCP ISNs
> >   would mitigate those attacks that require an attacker to guess
> > valid sequence numbers." This would naturally make it unsafe to
> > quickly start a new connection after one was just closed however as
> > the new ISN has a significant chance of being too close to an
> > already-used sequence number to be handled properly (you end up
> > with data from old and new connections potentially getting mixed
> > up). However, this problem would likely vanish if TCP sequence
> > numbers used a significantly larger number of bits than currently.
> > With 256-bit sequence numbers, the chances of arbitrarily
> > generating an ISN in the same 32-bit neighborhood as another
> > sequence number is 2**224, which would make collisions very
> > unlikely. Even if a machine established a new connection to a
> > remote machine 1000 times a second for 1000 years, the chances of
> > even a single sequence number "close call" would only be about 1 in
> > 8.55 × 10**62 (in reality it would be a bit less than that if there
> > were multiple packets circulating in the network at any given time,
> > but this would be of any practical worry as far as I can tell).
> > This would incur an additional 28 bytes of overhead per packet,
> > however.
> > * The fact that the ISN generation algorithm necessarily involves a
> >   secret key means that the first ISN used for any particular
> >   connection upon device reboot will be effectively equivalent to a
> >   random 32-bit value. With this in mind, the 64ns clock could be
> >   replaced with a simple counter, which would increment by one for
> >   every packet sent in a connection that used a particular
> >   localip/localport/remoteip/remoteport combo. This counter would
> > not be reset after a connection was disconnected, so that in the
> > event of rapid reconnections, the new ISNs would still increase
> > monotonically. In the event of a reboot, the counter will reset,
> > but so will the secret key, so the first ISN generated for each
> > connection will appear entirely randomized, just like it is with
> > the current specification. To my awareness, a counter-based scheme
> > such as this wouldn't be usable for malicious purposes beyond what
> > is already possible, as both sides of a TCP connection can simply
> > count packets if they want a counter value. Depending on the
> > implementation however, it may be possible for some counter values
> > to be skipped, which could potentially expose network issues or be
> > used as a covert channel. This would also consume additional memory
> > between reboots, a problem which could be rectified by occasionally
> > resetting the secret key and freeing the memory used by all
> > counters.
> >
> > Worthy of note, there already exists a Linux kernel module,
> > tirdad[3], which replaces the TCP ISN generation routines in the
> > Linux kernel with random number generators. The author of tirdad
> > has their own article on the rationale behind this.[4] At least on
> > the relatively slow connection I had when I tested it, and with the
> > very lightweight workload I used for testing (web browsing), this
> > didn't seem to cause any serious issues over short periods of time.
> > It is almost certainly not suitable for all TCP use cases, but it
> > did seem to be "close enough" for brief basic desktop use.
> >
> > Thank you for taking the time to read this, and I hope this is
> > helpful.
> >
> > Sincerely,
> > Aaron
> >
> > References:
> > [1] https://murdoch.is/papers/ccs06hotornot.pdf
> > [2] The "hot or not" paper mentions the possibility of using TCP
> > sequence numbers for attacks, but then states that "as the
> > cryptographic function is re-keyed every 5 minutes, maintaining long
> > term clock skew figures is non-trivial." I have not been able to
> > find this rekeying happening for ISN generation in the Linux source
> > code (looking at the tip of the master branch at the time of this
> > writing), and when doing testing on Debian 12 with a kernel patched
> > to print ISNs to the kernel log as they were generated, I did not
> > see any resetting happening, thus I believe this is a problem with
> > Linux's implementation at the very least. Even if an implementation
> > did do rekeying for ISN generation, I believe this is still a spec
> > issue as the spec does not mandate occasional rotation of the key
> > used in the ISN generation algorithm.
> > [3] https://github.com/0xsirus/tirdad/
> > [4]
> > https://bitguard.wordpress.com/2019/09/03/an-analysis-of-tcp-secure-sn-generation-in-linux-and-its-privacy-issues/
> > _______________________________________________
> > tcpm mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >