Re: Identifying Kernel 2.4.x based Linux machines using UDP

[Charles-Edouard Ruault <cruault () 724 com>]

Hi,

now that you're bringing the subject on the table, i'll follow up with a 
small bug i've discovered yesterday ...
On Linux you can "customize" the default ttl that will be used in all 
the IP packets that the box will be sending ( using 
/proc/sys/net/ipv4/ip_default_ttl )
. One of the main reasons to do that , as it has been said in many 
articles, is to make your machine  a little bit more difficult to 
fingerprint.
However, while playing with this feature, i've discovered that the 
current kernel ( 2.4.18 ) and probably earlier versions, don't use this 
default value when generating the following packets :

- ICMP reply ( of any kind )
- TCP RST .

Therefore, changing the ip_default_ttl on a standard kernel might do the 
opposite of what you're trying to achieve : make it much easier for an 
attacker to fingerprint your os....

I've written a small patch ( against kernel 2.4.18 ) that fixes this 
behaviour. I'm attaching it to this email ( i've also posted in on the 
linux-kernel mailing list ).
comments are welcome.


Ofir Arkin wrote:

> Subject: Identifying Kernel 2.4.x based Linux machines using UDP
>
> Author: Ofir Arkin (ofir () atstake com)
>
>
> Linux Kernel 2.4.x has a bug with the UDP implementation which allows 
> both active and passive fingerprinting of Linux machines based on the 
> 2.4.x Kernel.
>
> The following is a simple nslookup query initiated from my Kernel 
> 2.4.10 based Linux machine:
>
> 03/16-11:49:41.531642 192.168.1.200:1024 -> x.x.x.x:53 UDP TTL:64 
> TOS:0x0 ID:0 IpLen:20 DgmLen:63 DF
> Len: 43
> BC 0D 01 00 00 01 00 00 00 00 00 00 03 77 77 77  .............www
> 03 63 6E 6E 03 63 6F 6D 05 6C 6F 63 61 6C 00 00  .cnn.com.local..
> 01 00 01                                         ...
>
> The IP Identification field value with the UDP datagram is zero (0). 
> The value will be constant and will not be changed for future UDP 
> datagrams I will be sending.
>
> The problem is not only with generating UDP datagrams, but also with 
> answering UDP queries. With the following example I have sent a UDP 
> datagram to the ECHO service on a Linux 2.4.18 based machine:
>
> 03/16-12:13:17.388211 192.168.1.200:1775 -> y.y.y.y:7
> UDP TTL:64 TOS:0x0 ID:28256 IpLen:20 DgmLen:28
> Len: 8
>
> 03/16-12:13:17.547636 y.y.y.y:7 -> 192.168.1.200:1775
> UDP TTL:50 TOS:0x0 ID:0 IpLen:20 DgmLen:28 DF
> Len: 8
>
> The IP identification field value with the answer is zero (0). It will 
> also be constant and will not changed if we further query the target.
>
> The biggest problem is the ability to use legitimate applications, 
> such as DNS queries with nslookup, and by sending and receiving one 
> packet only to have the ability to fingerprint the 2.4.x Kernel branch.
>
> The 2.2.x kernel branch seems not to be affected according to my tests.
>
> Combined with another fingerprinting method using ICMP this time 
> (http://www.sys-security.com/archive/bugtraq/ofirarkin2001-03.txt), we 
> are able to fingerprint the 2.4.x kernel branch and divide it into two 
> groups - 2.4.0-2.4.4 kernels, and the 2.4.5-2.4.18 kernels.


--
Charles-Edouard Ruault

Attachment: default_ttl.patch.gz
Description: