8165508 2002-03-19 11:12 +0000 /65 rader/ Ofir Arkin <ofir@stake.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-19 21:46 av Brevbäraren
Extern mottagare: bugtraq <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <21485>
Ärende: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: Ofir Arkin <ofir@stake.com>
To: bugtraq <bugtraq@securityfocus.com>
Message-ID: <3C971D24.4070505@stake.com>
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.
--
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email:
ofir@stake.com
(8165508) /Ofir Arkin <ofir@stake.com>/---(Ombruten)
Kommentar i text 8172052 av Crist J. Clark <crist.clark@attbi.com>
Kommentar i text 8172066 av Crist J. Clark <crist.clark@attbi.com>
Kommentar i text 8172679 av Charles-Edouard Ruault <cruault@724.com>
8172052 2002-03-19 17:44 -0800 /47 rader/ Crist J. Clark <crist.clark@attbi.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-21 00:16 av Brevbäraren
Extern mottagare: Ofir Arkin <ofir@stake.com>
Extern kopiemottagare: bugtraq <bugtraq@securityfocus.com>
Externa svar till: cjclark@alum.mit.edu
Mottagare: Bugtraq (import) <21504>
Kommentar till text 8165508 av Ofir Arkin <ofir@stake.com>
Ärende: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: "Crist J. Clark" <crist.clark@attbi.com>
To: Ofir Arkin <ofir@stake.com>
Cc: bugtraq <bugtraq@securityfocus.com>
Message-ID: <20020319174419.D67739@blossom.cjclark.org>
On Tue, Mar 19, 2002 at 11:12:36AM +0000, 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.
This is a feature, not a bug. (IIRC, I am not a Linux developer and do
not follow the Linux IP stack development.)
> 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
^ ^^
Note that the "Do not Fragment" bit is set. The sole purpose of the IP
ID field is to assist in the reassembly of fragmented datagrams. If
the packet cannot be fragmented, the IP ID field is useless. The Linux
IP stack designers have chosen to use a zero IP ID field when the
DF bit is set.
I am not a Linux IP developer, but I can think of several arguments to
do this. If you are really concerned with IP ID randomness (and
strangely enough, some people are), algorthims which produce "good"
random numbers tend to be computationally expensive. Why waste the
computations on the IP ID when it will never be used in DF packets?
Right now, Linux kernels are one of the few to do this, so it is a way
to fingerprint. But most everyone on this list knows fingerprinting is
usually very easy anyway and is not vulnerability per sae. Also
consider that other IP implementations may change to this behavior in
the future as it does make some sense.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
(8172052) /Crist J. Clark <crist.clark@attbi.com>/--
8172066 2002-03-19 17:51 -0800 /20 rader/ Crist J. Clark <crist.clark@attbi.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-21 00:21 av Brevbäraren
Extern mottagare: Ofir Arkin <ofir@stake.com>
Extern kopiemottagare: bugtraq <bugtraq@securityfocus.com>
Externa svar till: cjclark@alum.mit.edu
Mottagare: Bugtraq (import) <21505>
Kommentar till text 8165508 av Ofir Arkin <ofir@stake.com>
Ärende: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: "Crist J. Clark" <crist.clark@attbi.com>
To: Ofir Arkin <ofir@stake.com>
Cc: bugtraq <bugtraq@securityfocus.com>
Message-ID: <20020319175117.E67739@blossom.cjclark.org>
Yuck. Following up to my own post.
I realize I wasn't clear on what "good" random numbers mean in IP ID
fields. To most people concerned about security, it means "not
incrementing." The problem with incrementing IP IDs of course being
the ability to do spoofed port scans on a quiescent server. Not using
incrementing IP IDs, using random ones when you need to and constant
(the 0 ones you observed) ones when DF is set, prevents these kinds of
scans.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
(8172066) /Crist J. Clark <crist.clark@attbi.com>/--
8172679 2002-03-19 11:09 -0800 /92 rader/ Charles-Edouard Ruault <cruault@724.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-21 08:16 av Brevbäraren
Extern mottagare: Ofir Arkin <ofir@stake.com>
Extern kopiemottagare: bugtraq <bugtraq@securityfocus.com>
Externa svar till: ce@ruault.com
Mottagare: Bugtraq (import) <21514>
Kommentar till text 8165508 av Ofir Arkin <ofir@stake.com>
Ärende: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: Charles-Edouard Ruault <cruault@724.com>
To: Ofir Arkin <ofir@stake.com>
Cc: bugtraq <bugtraq@securityfocus.com>
Message-ID: <3C978CD1.8020100@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
(8172679) /Charles-Edouard Ruault <cruault@724.com>/(Ombruten)
Bilaga (application/x-gzip) i text 8172680
8172680 2002-03-19 11:09 -0800 /4 rader/ Charles-Edouard Ruault <cruault@724.com>
Bilagans filnamn: "default_ttl.patch.gz"
Importerad: 2002-03-21 08:16 av Brevbäraren
Extern mottagare: Ofir Arkin <ofir@stake.com>
Extern kopiemottagare: bugtraq <bugtraq@securityfocus.com>
Externa svar till: ce@ruault.com
Mottagare: Bugtraq (import) <21515>
Bilaga (text/plain) till text 8172679
Ärende: Bilaga (default_ttl.patch.gz) till: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
P<default_ttl.patch mOÛ0Ç_'â$¤©&iÒPJ»EeQYúhxmÇ!VS;³ DA|÷Ùi%V
¦ioâËùît÷¿]×
²æÙgDù´~|·µ==Y Î` ôFQFöz¡í8ÎÇiG)á(¼ EÃ}ÊdnпìÀ1Ç& ^a:[ÓûåÝô*u Þ,ÿ̺I·èön ä>]]_[g¾
ocl<+"P¦@î$V¢5ÊI5BJUcÛ±Á?3%xu&²-Ñ9
.`ÌV H]Q"=0e¯¤@ ÑGÆAY¥ëý5âAð,ÇTrÜÎØ?ÌýóA÷¢ÑjSx£æ
Sö·mÊóLeqÚÕäÔ Ü¸q-¸¢¬à^V ªEöð
äæÁYéѺtcíÒÃ~®*þ±@`åY @kì L¡ÜX($6æ×Jû÷óyë)à¨w£áNHWv
¯¶û'N
×È!ÕëÔ{êQZ0:FÁà «A¤¥vÚ¯ü2\59¯ûz´{el´ý 3m÷_èjÙ* Þ@Ü$?Â0Öl cWc7D ;ÑôZÚ´¸Y¢ùtù#ÁP÷Ô>ÞEؾ s °ÉÄ£ÇåOzÁøàÀ²Ùò¢Älfoð¢#h°W.`ÓÝ)øÁ¼Ë)¹éÇÿíå¨]yç¸Z×0Ù
/º;mÒ Ry@YKn Z§Wé}uR\¯µ&RGü,UÐ~
(8172680) /Charles-Edouard Ruault <cruault@724.com>/
8172268 2002-03-21 10:57 +1100 /63 rader/ Fletcher, Stephen J <stephen.fletcher@eds.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-21 01:49 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21510>
Ärende: RE: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: "Fletcher, Stephen J" <stephen.fletcher@eds.com>
To: bugtraq@securityfocus.com
Message-ID: <533761B50551D511A6D200508B6F542807728760@AUSYM200>
I believe this was implemented with the ZeroCopy patch. Setting the
sequence number was removed where not needed to speed things up,
which was the main function of the ZeroCopy patch. The patch was
included in the main tree somewhere around 2.4.8.
Regards
Stephen
-----Original Message-----
From: Crist J. Clark [mailto:crist.clark@attbi.com]
Sent: Wednesday, 20 March 2002 12:44 PM
To: Ofir Arkin
Cc: bugtraq
Subject: Re: Identifying Kernel 2.4.x based Linux machines using UDP
On Tue, Mar 19, 2002 at 11:12:36AM +0000, 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.
This is a feature, not a bug. (IIRC, I am not a Linux developer and do
not follow the Linux IP stack development.)
> 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
^ ^^
Note that the "Do not Fragment" bit is set. The sole purpose of the IP
ID field is to assist in the reassembly of fragmented datagrams. If
the packet cannot be fragmented, the IP ID field is useless. The Linux
IP stack designers have chosen to use a zero IP ID field when the
DF bit is set.
I am not a Linux IP developer, but I can think of several arguments to
do this. If you are really concerned with IP ID randomness (and
strangely enough, some people are), algorthims which produce "good"
random numbers tend to be computationally expensive. Why waste the
computations on the IP ID when it will never be used in DF packets?
Right now, Linux kernels are one of the few to do this, so it is a way
to fingerprint. But most everyone on this list knows fingerprinting is
usually very easy anyway and is not vulnerability per sae. Also
consider that other IP implementations may change to this behavior in
the future as it does make some sense.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
(8172268) /Fletcher, Stephen J <stephen.fletcher@eds.com>/(Ombruten)
8196605 2002-03-23 01:43 -0800 /67 rader/ Fyodor <fyodor@insecure.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-26 00:52 av Brevbäraren
Extern mottagare: bugtraq <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <21576>
Kommentar till text 8165508 av Ofir Arkin <ofir@stake.com>
Ärende: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
From: Fyodor <fyodor@insecure.org>
To: bugtraq <bugtraq@securityfocus.com>
Message-ID: <20020323094302.GA25603@core.lnxnet.net>
On Tue, Mar 19, 2002, Ofir Arkin (ofir@stake.com) wrote:
>
> 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.
Actually, as Crist Clark noted, this is a feature with both security
and efficiency benefits. It also isn't specific to UDP -- you'll find
similar TCP behavior. Nor is it exclusive to Linux 2.4 kernels --
Some (all?) Cisco IOS 12.0 - 12.3 devices and various Linksys
broadband routers do this.
I agree that that this is useful for remote OS detection. In fact,
the Nmap Security Scanner has been using this OS detection technique
for more than a year (since 2.54BETA20). You can grab a copy at
http://www.insecure.org/nmap/ .
> 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.
Last year I added a feature to Nmap which automates this IPID
classification. Give the Nmap arguments "-v -O" against the host
above and it should say "IPID Sequence Generation: All zeros". Other
IPID classes Nmap understands include "incremental" (most machines),
"duplicated IPID" (mostly stupid devices like printers), "Broken
little-endian incremental" (Windows), "Randomized" (OpenBSD), and
"Random positive increments". The XML output will provide the actual
ID numbers in case you want to do your own analysis.
A more recent IPID-related Nmap feature is the Idlescan (-sI). This
clever method (discovered by Antirez) allows for a truly blind TCP
port scan -- no packets are sent to the target from your real IP
address. Instead, a unique side-channel attack exploits predictable
IPID sequences on a chosen "zombie" host to glean information about
open ports on the target network. IDS systems will report the scan as
coming from the zombie. Besides being extraordinarily stealthy (due
to its blind nature), this scan type permits mapping out IP-based
trust relationships between machines.
Please excuse my blatant Nmap promoting, but IPID analysis is one of
my favorite reconnaissance techniques. The methods are subtle, but
can provide a wealth of information to potential attackers.
Fortunately, recent versions of Linux, Solaris, and OpenBSD (among
others) address most of the issues. Lets hope that other vendors
follow their lead.
Cheers,
Fyodor
PS: While I'm plugging Nmap, I should mention that 2.54BETA31 was just
released. It supports ICMP netmask/timestamp "ping" requests, custom
TCP scan flags support, and other new features.
http://www.insecure.org/nmap/ .
(8196605) /Fyodor <fyodor@insecure.org>/------------
Bilaga (application/pgp-signature) i text 8196606
8196606 2002-03-23 01:43 -0800 /12 rader/ Fyodor <fyodor@insecure.org>
Importerad: 2002-03-26 00:52 av Brevbäraren
Extern mottagare: bugtraq <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <21577>
Bilaga (text/plain) till text 8196605
Ärende: Bilaga till: Re: Identifying Kernel 2.4.x based Linux machines using UDP
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iQCVAwUBPJxOJc4dPqJTWH2VAQH2dQQAuirnvUHG8kbPlbeUQM4669vM1d2EKRPf
/L2q6fECEoSjUCt4wtip123/OvsqUsqScutMtfOMTnEd+9dxoXtQ9gDeM9U6SKMS
2d6MUK9LjweE3Gr6gQfz9mclrhg0cSZNtmH/d8dtbc6GVUcJ7HEHbEIZXgMIJ0Ds
2pLQnHbFiB0=
=PNaA
-----END PGP SIGNATURE-----
(8196606) /Fyodor <fyodor@insecure.org>/------------