NMAP and Uptime Guessing

Discuss and suggest new grsecurity features

NMAP and Uptime Guessing

Postby Kagato » Wed Jun 25, 2003 9:26 pm

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
Kagato
 
Posts: 1
Joined: Wed Jun 25, 2003 9:18 pm

Re: NMAP and Uptime Guessing

Postby perlionex » Thu Sep 25, 2003 10:23 pm

echo 1 > /proc/sys/net/ipv4/tcp_timestamps
perlionex
 
Posts: 13
Joined: Thu Sep 25, 2003 10:22 pm

Re: NMAP and Uptime Guessing

Postby hightower » Fri Sep 26, 2003 5:27 pm

perlionex wrote: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
hightower
 
Posts: 49
Joined: Wed Mar 06, 2002 11:36 am

tcp_timestamps

Postby perlionex » Fri Sep 26, 2003 8:14 pm

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.
perlionex
 
Posts: 13
Joined: Thu Sep 25, 2003 10:22 pm

randomly reset to random value?

Postby gman » Mon Sep 29, 2003 4:12 am

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"?
gman
 
Posts: 1
Joined: Mon Sep 29, 2003 2:56 am

Postby spender » Mon Sep 29, 2003 1:38 pm

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
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

tcp_timestamps patches

Postby perlionex » Tue Sep 30, 2003 2:05 am

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.
perlionex
 
Posts: 13
Joined: Thu Sep 25, 2003 10:22 pm

Postby ErroR|51 » Sat Jan 10, 2004 6:36 pm

That would be, indeed, a nice hack.
Can't understand why they are refusing to do such a patch, though.
ErroR|51
 
Posts: 2
Joined: Wed Jan 07, 2004 7:11 pm

Re: NMAP and Uptime Guessing

Postby Dust_Blaster » Mon May 05, 2014 6:23 pm

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?
Dust_Blaster
 
Posts: 1
Joined: Mon May 05, 2014 5:53 pm

Re: NMAP and Uptime Guessing

Postby spender » Thu May 08, 2014 9:52 pm

Hi,

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

Feel free to give it a try.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: NMAP and Uptime Guessing

Postby fred » Fri May 09, 2014 3:59 pm

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
fred
 
Posts: 3
Joined: Fri May 09, 2014 3:35 pm

Re:

Postby mikeeusa2 » Sat May 10, 2014 1:44 pm

ErroR|51 wrote: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.
mikeeusa2
 
Posts: 60
Joined: Thu May 15, 2008 1:54 am

Re: NMAP and Uptime Guessing

Postby spender » Sat May 10, 2014 1:50 pm

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

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: NMAP and Uptime Guessing

Postby fred » Mon May 12, 2014 3:56 pm

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 :D

[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
 
Posts: 3
Joined: Fri May 09, 2014 3:35 pm

Re: NMAP and Uptime Guessing

Postby fred » Fri Aug 07, 2015 11:07 am

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;

fred
 
Posts: 3
Joined: Fri May 09, 2014 3:35 pm

Next

Return to grsecurity development

cron