Date: Mon, 28 Dec 1998 16:16:40 -0700 From: David G. Andersen To: BUGTRAQ@netspace.org 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: danderse@cs.utah.edu me: angio@pobox.com 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 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"