Bugtraq mailing list archives
Re: Identifying SUN Solaris Machines using ICMP Address Mask Requests with a little twist (fwd)
From: Jason Axley <jason.axley () ATTWS COM>
Date: Wed, 9 Aug 2000 15:26:15 -0700
I saw that someone else had posted similar settings to BUGTRAQ, so mine
seems to have been rejected in lieu of that one. However, it wasn't
pointed out that these settings _will not_ prevent the problem of unicast
mask requests.
-Jason
--
AT&T Wireless Services
IT Security
UNIX Security Operations Specialist
---------- Forwarded message ----------
Date: Mon, 7 Aug 2000 11:47:48 -0700 (PDT)
From: Jason Axley <jason.axley () attws com>
To: Ofir Arkin <ofir () ITCON-LTD COM>
Cc: BUGTRAQ () SECURITYFOCUS COM
Subject: Re: [BUGTRAQ] Identifying SUN Solaris Machines using ICMP Address
Mask Requests with a little twist
It's a good idea to set:
/usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
/usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp 0
/usr/sbin/ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
/usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0
at every boot to disable some of these avenues, but Solaris only
provides the facility to disable response to address mask requests to
the _broadcast_ address. It happily responds to unicast requests, as
shown by SING below. You'll notice above that there is a facility to
disable timestamp requests for both broadcast and unicast, but no parallel
option for address mask requests. ndd /dev/ip \? does not show any other
options that could help here (on 2.6).
-Jason
On Sat, 5 Aug 2000, Ofir Arkin wrote:
Date: Sat, 5 Aug 2000 20:54:43 +0200 From: Ofir Arkin <ofir () ITCON-LTD COM> To: BUGTRAQ () SECURITYFOCUS COM Subject: [BUGTRAQ] Identifying SUN Solaris Machines using ICMP Address
Mask Requests with a little twist
Subject: Identifying SUN Solaris Machines Using ICMP Address Mask Requests with a little twist. Authors: Ofir Arkin [ofir () itcon-ltd com] Alfredo Andrés Omella [aandres () mfom es] Description: It appears that only some of the operating systems would answer an ICMP Address Mask Request. Those operating systems include: ULTRIX OpenVMS, Windows 95/98/98 SE/ME, NT below SP 4, and SUN Solaris machines. How can we distinguish between those who answer the request? This is a regular Address Mask Request sent by SING (http://sourceforge.net/projects/sing), written by Alfredo Andrés Omella, to a SUN Solaris 2.7 machine: [root@aik icmp]# ./sing -mask IP_Address SINGing to IP_Address (IP_Address): 12 data bytes 12 bytes from IP_Address: icmp_seq=0 ttl=236 mask=255.255.255.0 12 bytes from IP_Address: icmp_seq=1 ttl=236 mask=255.255.255.0 12 bytes from IP_Address: icmp_seq=2 ttl=236 mask=255.255.255.0 12 bytes from IP_Address: icmp_seq=3 ttl=236 mask=255.255.255.0 12 bytes from IP_Address: icmp_seq=4 ttl=236 mask=255.255.255.0 --- IP_Address sing statistics --- 5 packets transmitted, 5 packets received, 0% packet loss All operating systems that would answer with ICMP Address Mask Reply would reply with the Address Mask of the network they reside on. What would happen if we would introduce a little twist? Lets say we would send those queries fragmented? In the next example, I have sent ICMP Address Mask Request to the same SUN Solaris 2.7 box, this time fragmented to pieces of 8 bytes of IP data. As we can see the answer I got was unusual (the -c 2 option used with SING enables it to send two ICMP Address Mask request datagrams only): [root@aik icmp]# ./sing -mask -c 2 -F 8 IP_Address SINGing to IP_Address (IP_Address): 12 data bytes 12 bytes from IP_Address: icmp_seq=0 ttl=241 mask=0.0.0.0 12 bytes from IP_Address: icmp_seq=1 ttl=241 mask=0.0.0.0 --- IP_Address sing statistics --- 2 packets transmitted, 2 packets received, 0% packet loss [root@aik icmp]# The tcpdump trace: 20:02:48.441174 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address: icmp: address mask request (frag 13170:8@0+) 4500 001c 3372 2000 ff01 50ab 8b5c d015 xxxx xxxx 1100 aee3 401c 0000 20:02:48.442858 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address: (frag 13170:4@8) 4500 0018 3372 0001 ff01 70ae 8b5c d015 xxxx xxxx 0000 0000 20:02:49.111427 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net: icmp: address mask is 0x00000000 (DF) 4500 0020 3618 4000 f101 3c01 xxxx xxxx 8b5c d015 1200 ade3 401c 0000 0000 0000 20:02:49.441492 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address: icmp: address mask request (frag 13170:8@0+) 4500 001c 3372 2000 ff01 50ab 8b5c d015 xxxx xxxx 1100 ade3 401c 0100 20:02:49.442951 ppp0 > slip139-92-208-21.tel.il.prserv.net > Host_Address: (frag 13170:4@8) 4500 0018 3372 0001 ff01 70ae 8b5c d015 xxxx xxxx 0000 0000 20:02:50.011433 ppp0 < Host_Address > slip139-92-208-21.tel.il.prserv.net: icmp: address mask is 0x00000000 (DF) 4500 0020 3619 4000 f101 3c00 xxxx xxxx 8b5c d015 1200 ace3 401c 0100 0000 0000 The same SUN Solaris box now replies with a 0.0.0.0 as the Address Mask for the Network it resides on. What would happen with the other operating systems? They all would respond with the same/real Address Mask Reply. Here we got a distinction between SUN Solaris machines and the other operating systems that would answer those queries. Important notice: When I have tested this method I have encountered some problems replicating the results with different ISPs. As it seems from analyzing the information I got, certain ISPs would block fragmented ICMP datagrams. This behavior would not enable this method to succeed. Operating Systems tested: LINUX Kernel 2.4t2; LINUX Kernel 2.2.14; FreeBSD 4.0, 3.4; OpenBSD 2.7 & 2.6; Solaris 2.5.1, 2.6, 2.7 & 2.8; HP-UX 10.20; AIX 4.1; ULTRIX; Microsoft Windows 95 / 98 / 98SE / ME / NT 4 SP3, SP4, SP6a WRST & SERVER / 2000 Professional & Server. Ofir Arkin Senior Security Consultant ITcon, Israel. Personal Web page: http://www.sys-security.com
-- AT&T Wireless Services IT Security UNIX Security Operations Specialist
Current thread:
- Re: Identifying SUN Solaris Machines using ICMP Address Mask Requests with a little twist (fwd) Jason Axley (Aug 10)