[24825] in bugtraq

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Fyodor)
Mon Mar 25 18:50:29 2002

Date: Sat, 23 Mar 2002 01:43:02 -0800
From: Fyodor <fyodor@insecure.org>
To: bugtraq <bugtraq@securityfocus.com>
Message-ID: <20020323094302.GA25603@core.lnxnet.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
In-Reply-To: <3C971D24.4070505@stake.com>

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2002, Ofir Arkin (ofir@stake.com) wrote:
>=20
> Linux Kernel 2.4.x has a bug with the UDP implementation which allows=20
> both active and passive fingerprinting of Linux machines based on the=20
> 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=20
> 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                                         ...
>=20
> The IP Identification field value with the UDP datagram is zero (0). The=
=20
> value will be constant and will not be changed for future UDP datagrams=
=20
> 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/ .

--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline

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

--6TrnltStXW4iwmi0--

home help back first fref pref prev next nref lref last post