[16173] in bugtraq
Re: Identifying SUN Solaris Machines using ICMP Address Mask
daemon@ATHENA.MIT.EDU (Jason Axley)
Thu Aug 10 14:47:25 2000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Message-ID: <Pine.SOL.4.02.10008091524540.16471-100000@nofud.nwest.attws.com>
Date: Wed, 9 Aug 2000 15:26:15 -0700
Reply-To: Jason Axley <jason.axley@ATTWS.COM>
From: Jason Axley <jason.axley@ATTWS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Content-Transfer-Encoding: 8bit
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
