ICMP Information Request (Type 15) and Reply (Type 16)

--- 172.18.2.149 sing statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

The snort trace:

05/14/01-12:21:35.301542 172.18.2.201 -> 172.18.2.149 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST

5A 05 00 00 02 02 26 46 00 00 00 00 00 00 00 00 Z...&F...

05/1

ICMP TTL:128 TOS:0x0 ID:10964 IpLen:20 DgmLen:40 4/01-12:21:35.301542 172.18.2.149 -> 172.18.2.201 Type:14 Code:0 TIMESTAMP REPLY

5A 05 00 00 02 02 26 46 7C 9E 38 02 7C 9E 38 02 Z...&F|.8.|.8.

Most of the operating systems have implemented the ICMP Timestamp request and reply mechanism. When I have sent an ICMP Timestamp request to a Windows NT 4 SP6a based machine, I got no reply. Again, this is not an abnormal behavior from the Microsoft Windows NT machine, just an implementation choice as RFC 1122 states.

Countermeasure: Block ICMP Time Stamp Requests coming from the Internet on the border Router and/or Firewall. If possible configure your host(s) to ignore ICMP Timestamp requests.

3.4.2 ICMP Information Request (Type 15) and Reply (Type 16)

The ICMP Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations at boot time, to allow them to discover their network address.

The sender fills in the request with the Destination IP address in the IP Header set to zero (meaning this network). The request may be sent with both Source IP Address and Destination IP

43

25 Sing, written by Alfredo Andreas Omella, can be found at www.sourceforge.net/projects/sing.

Address set to zero. The sender initializes the identifier and the sequence number, both used to match the replies with the requests, and sends out the request. The ICMP header code field is zero.

If the request was issued with a non-zero Source IP Address the reply would only contain the network address in the Source IP Address of the reply. If the request had both the Source IP Address and the Destination IP Address set to zero, the reply will contain the network address in both the source and destination fields of the IP header.

From the description above one can understand that the ICMP Information request and reply mechanism was intended to be used locally.

The RARP, BOOTP & DHCP protocols provide better mechanisms for hosts to discover its own IP address.

Checksum Sequence Number Identifier

Code = 0 Type

0 4 8 16 31

Figure 16: ICMP Information Request & Reply message format

The Information Request & Reply mechanism is now obsolete as stated in RFC 1122, and RFC 1812²⁶. A router should not originate or respond to these messages; A host should not implement these messages.

Demands on one hand and reality on the other.

RFC 792 specifies that the Destination IP address should be set to zero, this mean that hosts that do not reside on the same network cannot send these ICMP query type.

But what would happen if we would send an ICMP Information Request with the Destination IP address set to a specific IP address of a host out in the void?

The next example illustrates that some operating systems would answer these queries even if not issued from the same network. The ICMP Information Request queries we are sending are not really RFC compliant because of the difference in the Destination IP address.

Those operating systems that answer our queries work in contrast to the RFC guidelines as well.

We would see in the next example why.

In the next example I have sent an ICMP Information Request, using the sing utility, to an IBM AIX machine:

[root@aik icmp]# ./sing -info host_address²⁷

SINGing to host_address (ip_address): 8 data bytes

26 RFC 1812: Requirements for IP Version 4 Routers, http://www.ietf.org/rfc/rfc1812.txt . As the RFC states this

mechanism is now obsolete - A router should not originate or respond to these messages; A host should not implement these messages.

27

8 bytes from ip_address: icmp_seq=0 ttl=238 Info Reply 8 bytes from ip_address: icmp_seq=1 ttl=238 Info Reply 8 bytes from ip_address: icmp_seq=2 ttl=238 Info Reply 8 bytes from ip_address: icmp_seq=3 ttl=238 Info Reply --- host_address sing statistics ---

5 packets transmitted, 4 packets received, 20% packet loss

The tcpdump trace:

19:56:37.943679 ppp0 > x.x.x.x > y.y.y.y: icmp: information request 4500 001c 3372 0000 ff01 18a7 xxxx xxxx yyyy yyyy 0f00 bee3 321c 0000

19:56:38.461427 ppp0 < y.y.y.y > x.x.x.x: icmp: information reply 4500 001c 661b 0000 ee01 f6fd yyyy yyyy xxxx xxxx 1000 bde3 321c 0000

Lets do a quick analysis of the trace.

The ICMP Information request:

Value Field Additional Information

4 4-Bit Version IP Version 4

5 4-Bit Header Length 4 x DWORD = 20 Bytes

00 8-Bit TOS TOS=0

00 1c 16-Bit Total Length 33 72 16-Bit Identification

00 00 3-Bit Flags + 13-bit Fragment Offset

ff 8-Bit TTL TTL=255

01 8-Bit Protocol 1=ICMP

18 a7 16-Bit Header Checksum

8b 5c d0 15 32-bit Source IP Address 139.92.208.21 xx xx xx xx 32-Bit Destination IP Address

0f 8-Bit Type Type=15

00 8-Bit Code Code=0

be e3 16-Bit Checksum 32 1c 16-Bit Identifier

00 00 16-Bit Sequence Number

The ICMP Information Reply:

Value Field Additional Information

4 4-Bit Version IP Version 4

5 4-Bit Header Length 4 x DWORD = 20 Bytes

00 8-Bit TOS TOS=0

00 1c 16-Bit Total Length 66 1b 16-Bit Identification

00 00 3-Bit Flags + 13-bit Fragment Offset

ee 8-Bit TTL TTL=238

01 8-Bit Protocol 1=ICMP

F6 fd 16-Bit Header Checksum 45

Value Field Additional Information xx xx xx xx 32-bit Source IP Address

8b 5c d0 15 32-Bit Destination IP Address 139.92.208.21

10 8-Bit Type Type=16

00 8-Bit Code Code=0

bd e3 16-Bit Checksum 32 1c 16-Bit Identifier

00 00 16-Bit Sequence Number

Instead of having the network address in the Source IP Address we are getting the IP address of the host.

Does the reply compliant with RFC 792 regarding this issue? Basically yes, because the RFC does not specify an accurate behavior.

The RFC states: “To form a information reply message, the source and destination addresses are simply reversed, the type code changes to 16, and the checksum recomputed”.

This means that if the ICMP Information Request is coming from outside (Destination is not zero) of the network in question, the network address would not be revealed. But still a host could be revealed if he answers the request.

The request is not compliant with the RFC in my opinion because it does not fulfill its job – getting the network address.

Countermeasure: Block ICMP Information Requests coming from the Internet on the border Router and/or Firewall.