Explores fingerprinting techniques via ICMP time and netmask responses across various operating systems.
`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