Lucene search

K

os-fingerprinting.txt

๐Ÿ—“๏ธย 17 Aug 1999ย 00:00:00Reported byย Packet StormTypeย 
packetstorm
ย packetstorm
๐Ÿ”—ย packetstormsecurity.com๐Ÿ‘ย 27ย Views

Explores fingerprinting techniques via ICMP time and netmask responses across various operating systems.

Show more
Code
`Date: Mon, 28 Dec 1998 16:16:40 -0700  
From: David G. Andersen <[email protected]>  
To: [email protected]  
Subject: A few more fingerprinting techniques - time and netmask  
  
The release of nmap reminded me about some work I did a while ago for  
yet-more-information-gathering-programs, and I thought it might be  
interesting from the perspective of fingerprinting. Various systems  
handle ICMP queries in improper ways for time and netmask requests.  
I discussed some of these in a bulletin I didn't bother publically  
announcing (http://www.angio.net/consult/secadv/AA-1997-09-02.address-mask)  
and they're somewhat relevant here.  
  
(They're also kind of fun for figuring out if places are firewalled,  
if links are point to point, if they run time synchronization, etc.)  
  
System ICMP Time ICMP Mask  
  
Windows no yes  
FreeBSD yes no  
Linux 1.x yes yes  
Linux 2.x yes no  
SunOS yes yes  
Solaris yes yes  
HPUX yes yes  
Older IRIX yes yes  
Newer IRIX yes no  
MacOS - MacTCP ? no  
MacOS - TCP/IP ? yes?  
Apple Internet Server yes  
  
On some operating systems, these aren't the best ways for  
fingerprinting, because they are configurable - FreeBSD and Solaris  
allow you to control the behavior, for instance, and I'm sure other  
systems may as well.  
  
I asked CERT to send some of the information on to vendors last year  
(since responding to ICMP Mask requests when you're not a router is a  
violation of the host requirements RFC), but it's not really a high  
priority issue. ;-)  
  
Demonstration programs for these (I've only tested them on FreeBSD)  
can be found at:  
  
http://www.angio.net/security/icmptime.c  
http://www.angio.net/security/icmpmask.c  
  
Sample output:  
  
torrey# ./icmptime www.yahoo.com www.freebsd.org www.netbsd.org www.openbsd.org  
www.yahoo.com : Mon Dec 28 16:13:06 1998  
www.freebsd.org : Mon Dec 28 16:13:14 1998  
www.netbsd.org : Mon Dec 28 16:13:05 1998  
www.openbsd.org : Mon Dec 28 16:13:10 1998  
  
(real time was 16:13:06)  
  
torrey# ./icmpmask www.cisco.com www.bay.com www.nytimes.com  
www.cisco.com : 0xFFFFFFE0  
www.bay.com : 0xFFFFFFE0  
www.nytimes.com : 0xFFFFFF00  
  
-Dave  
  
--  
work: [email protected] me: [email protected]  
University of Utah http://www.angio.net/  
Computer Science - Flux Research Group  
  
  
--------------------------------------------------------------------------------  
  
  
----------------------------------------------  
Security Bulletin  
September 3, 1997  
  
Information gathering vulnerability in  
several host/router platforms.  
----------------------------------------------  
  
DESCRIPTION  
  
Many host platforms respond to icmp address mask requests (ICMP_MASKREQ,   
type 17), even when they should not respond to those requests. This permits  
an attacker to learn toplogical information about an internal network, and  
may permit an attacker to infer host OS information or behavior from the  
target network. Most hosts should not respond to queries of this type  
unless specifically configured to do so. However, this behavior appears  
to be the default behavior in a number of systems.  
  
Hosts which respond to icmp address mask requests without having been  
specifically configured to do so are in violation of RFC1122, the host  
requirements RFC, which states that:  
  
A system MUST NOT send an Address Mask Reply unless it is an   
authoritative agent for address masks. An authoritative agent  
may be a host or a gateway, but it MUST be explicitly configured  
as an address mask agent. ... (RFC 1122, section 3.2.2.9)  
  
  
IMPACT  
  
Outside machines may be able to gain knowledge about the internal   
network toplogy and machine types via an ICMP packet. This knowledge  
could prove useful for attackers attempting to launch a denial-of-service  
attack (the subnet mask can be used to determine the broadcast address  
for a network without trial and error, leading to a number of recently  
popular ICMP and UDP denial of service attacks), or for attackers  
attempting to determine where the trust relationships in a network  
lie.  
  
This is a relatively low-security concern for most sites, but the  
behavior exhibited by many platforms is aberrent and should be  
corrected. Sites which block ICMP_ECHO ("ping") requests should  
also block icmp address mask requests, since they may be used for  
much the same purposes as ping packets.  
  
AFFECTS  
  
A large number of systems are affected by this vulnerability.  
This list is not complete.  
  
Systems tested include:  
  
System Vulnerable User correctable? Patch?  
(as shipped)  
  
Operating Systems  
------------------  
  
FreeBSD-Current no net.inet.icmp.maskrepl  
FreeBSD-2.2.x no "  
FreeBSD-2.1.x no "  
Linux 1.x yes "  
Linux 2.x no  
SunOS yes  
Solaris 2.5.1 yes /dev/ip  
ip_respond_to_address_mask  
HPUX 9.05 yes  
HPUX 9.03 yes  
IRIX 5.3 yes  
Microsoft NT 4.0 yes  
Microsoft Windows 95 yes  
Mac - MacTCP no  
Mac - TCP/IP yes?  
Apple Internet Server yes  
  
  
REMEDY  
  
Block ICMP address mask requests at your router. This can be done  
on any router which allows icmp type filtering. On routers from  
Cisco systems, it can be blocked by inserting a rule such as:  
  
access-list 130 deny icmp any any mask-request  
<rest of packet filter goes here>  
  
  
SEE ALSO  
  
Braden, R. T., ed. RFC 1122, "Requirements for Internet Hosts --  
Communication Layers"  
  
Mogul, J. and Postel, J., RFC 950, "Internet Standard Subnetting  
Procedure" (appendix I.)  
  
Baker, F., ed. RFC1812, "Requirements for IP Version 4 Routers"  
`

Transform Your Security Services

Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contactย us for a demo andย discover the difference comprehensive, actionable intelligence can make in your security strategy.

Book a live demo
17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4
27
.json
Report