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 (ofiratstake.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

• application/x-gzip attachment: default_ttl.patch.gz

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]