NMAP and Uptime Guessing

[Kagato]

As some have noted, the TCP Timestamps option allows people with knowledge of the Linux TCP stack to accurately estimate the uptime of a machine.

While the timestamps can be disabled, they perform a valuable function (they can be used to determine round-trip-time which is fairly vital to preventing wastefully retransmitting data). See RFC 1323.

Currently, a number of OSs (Linux included, I believe) start this counter out at zero and then count up in a predictable fashion. It is therefore possible to determine uptime if you can identify the OS.

Nothing more than randomizing the initial value would be necessary to prevent this data from slipping. Since this information can be useful in selecting machine to attack (prioritize on machines that haven't rebooted in a while and thus may have more holes), it is probably a good idea to close this before anyone decides to exploit it.

Can we do this?

Jayson

[perlionex]

echo 1 > /proc/sys/net/ipv4/tcp_timestamps

[hightower]

echo 1 > /proc/sys/net/ipv4/tcp_timestamps

you completely missed the point Kagato was asking. If it's 1, you can determine the uptime, if it's 0 it's not RFC 1323. He asked for randomization of tcp_timestamps so neither it violates RFC 1323 nor you can determine the uptime.

ciao, Marc

[perlionex]

Oops. =)

A kernel patch shouldn't be too difficult, right?

Note that if you only randomise the timestamp at boot-up, an attacker could still monitor your machine for timestamp changes over time to know when you went up. It'll be a lot harder for a script kiddie, of course.

[gman]

What about randomly resetting it to a random value? For example, once every 24 - 240 hours, reset to random value.

How can you change the value without confusing connected clients? Disable timestamps for n minutes, then reset/re-enable to random value?

How to prevent "monitor your machine for timestamp changes over time to know when you went up"?

[spender]

The way to "fool" people is to instead of using the jiffies value for the timestamp, use 0 as the initial timestamp for the connection. This doesn't break RFC and does what you want. However, I've looked at doing this a few times in Linux, and though my knowledge of that area of the code is minimal at best, it looked like jiffies were too ingrained into the code to be able to make a trivial change to use this new timestamping method.

-Brad

[perlionex]

Around early 2001, when this issue first broke on Bugtraq and the NMap development list, there were some calls for the various *nix kernels to do exactly that. However, ony a patch for OpenBSD 2.7/2.8 was ever released (see URL below), and by and far the various kernel hackers (including Linux) refused to develop similar patches.

http://packetstorm.widexs.nl/UNIX/patches/rfc1323.patch

I'm not sure why this hasn't been done for Linux. It's a small issue, to be sure, but there's no reason why you have to tell someone scanning you how long your computer's been up. And as mentioned earlier, disabling tcp_timestamps, while solving the immediate issue, does go against rfc 1323.

[ErroR|51]

That would be, indeed, a nice hack.
Can't understand why they are refusing to do such a patch, though.

[Dust_Blaster]

Hello
I'm sorry that I am updating topic after so much years passed by but I am curious about current situation with tcp timestamp in operating systems/networking stacks and I think it is a good place to ask. Is still OpenBSD the only system that randomizes value of timestamp at the beggining of tcp connection(or setting constant value such as 0)? Does grsecurity changes the behaviour of Linux network stack in regard to timestamps?

[spender]

Hi,

I just wrote the following patch:
https://grsecurity.net/~spender/random_timestamp.diff

Feel free to give it a try.

-Brad

[fred]

i tried to compile with that patch:

Code: Select all

CC [M]  net/xfrm/xfrm_ipcomp.o
  Building modules, stage 2.
  MODPOST 2113 modules
ERROR: "random_timestamp_base" [net/netfilter/nf_synproxy_core.ko] undefined!
ERROR: "random_timestamp_base" [net/ipv4/tcp_westwood.ko] undefined!
ERROR: "random_timestamp_base" [net/ipv4/tcp_lp.ko] undefined!
ERROR: "random_timestamp_base" [net/ipv4/tcp_htcp.ko] undefined!
ERROR: "random_timestamp_base" [net/ipv4/tcp_bic.ko] undefined!
ERROR: "random_timestamp_base" [net/dccp/dccp.ko] undefined!
WARNING: modpost: Found 12592 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-3.14.3'
make: *** [debian/stamp/build/kernel] Error 2

[mikeeusa2]

That would be, indeed, a nice hack.
Can't understand why they are refusing to do such a patch, though.

Because they think they are superior or they are bought and payed for.
They don't care about your security concerns, besides what do you have to worry about, if you are violating the US/Western moral law code you deserve to be thrown in prison forever. Every knee must bend to the religion of democracy, freedom, and ... well GIRLS NOT BRIDES, GIRLS NOT BRIDES, FERT, EMPOWERMENT (and yea 5 or 6 million men in prison in the USA, being raped by homosexuals and getting aids!).

Think how bad the men in afghanistan have it: they are blown to bits in their houses while the mighty moral force of these United States of America liberate their land so that girls will never be married to a man again (allowed in their muslim religion, also allowed in the old testament, and vedic religions, so on and so on... but not allowed in the USA religion/belief system (US Code)... and the USA is the god of this world so we all must obey obey obey)

Why is systemd being rammed down our throats? Because some people are bought and payed for.
Give someone a million dollars and they'll do whatever you want, because money is the only good thing in western life. The natural pleasures are all outlawed and the men who find them are persecuted.

Don't worry if you're in line, you're in the club then. Be happy about the bugridden garbage being dumped on us: it could be worse: it could be bombs from drones like other people who disobey the USA belief system suffer under.

[spender]

The patch has been updated to fix module compilation (didn't export the added variable).

-Brad

[fred]

Now the Kernel compiled - i rebooted and:

Code: Select all

Uptime guess: 57.002 days (since Sun Mar 16 20:51:00 2014)

Thank you

[edit]

I scanned some more times - now:

Code: Select all

Uptime guess: 57.466 days (since Sun Mar 16 09:51:39 2014)

Time seems to pass very fast.

[fred]

i cannot patch the 3.14.49 anymore - until 3.14.48 it worked fine

Code: Select all

grsecurity/grsec_init.c.rej:

--- grsecurity/grsec_init.c
+++ grsecurity/grsec_init.c
@@ -7,6 +7,11 @@
 #include <linux/percpu.h>
 #include <linux/module.h>

+#ifdef CONFIG_GRKERNSEC_RANDOM_TIMESTAMPS
+__u32 random_timestamp_base __latent_entropy;
+EXPORT_SYMBOL_GPL(random_timestamp_base);
+#endif
+
 int grsec_enable_ptrace_readexec;
 int grsec_enable_setxid;
 int grsec_enable_symlinkown;