Nytro Posted April 19, 2014 Report Posted April 19, 2014 How can attacker use ICMP for reconnaissance?By: KoonYaw Tan 1. Introduction RFC 792 spelt out the goals and specifications of the Internet Control Message Protocol (ICMP). Basically, it is used as a means to send error messages for non-transient error conditions and to provide a way to query the network in order to determine the general characteristic of the network. The Internet Protocol (IP) is not designed to be absolutely reliable. The purpose of the ICMP messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. ICMP uses the basic support of IP as if it were a higher level protocol. However, ICMP is actually an integral part of IP and must be implemented by every IP module. ICMP suppose to be a relatively simple protocol, but it can be altered to act as a conduit for evil purpose. It is therefore important to understand how this protocol can be used for malicious purposes. This assignment examines how ICMP can be used in a non-convention way, putting itself as a potential threat. We will concentrate on the use of ICMP in a non-convention way rather than the normal use of ICMP. 2. Understanding ICMPConventionally, ICMP is provided as a means to send error messages for non-transient error conditions and to provide a way to query the network. ICMP is used for two types of operations: Reporting non-transient error conditions (ICMP Error Messages). Query the network with request and reply (ICMP Query Messages). Unlike TCP and UDP, ICMP has no port numbers. ICMP uses type and code to differentiate the services in the protocol. Also in ICMP, there is no client-server concept. When an ICMP error message is delivered, the receiving host might respond internally but might not communicate back to the informer. Services and ports do not have to be activated or listening. ICMP can be broadcast to many hosts because there is no sense of an exclusion connection. RFC 792 defined special conditions for the ICMP messages: No ICMP error messages are sent in response to ICMP error messages to avoid infinite repetition. For fragmented IP datagrams, ICMP messages are only sent for errors on fragmented zero (the first fragment). ICMP error messages are never sent in response to a datagram that is destined to a broadcast or a multicast address. ICMP error messages are never sent in response to a datagram sent as a link layer broadcast. ICMP error messages are never sent in response to a datagram whose source address does not represents a unique host (the source address cannot be zero, a loopback address, a broadcast address or a multicast address). ICMP error messages are never sent in response to an IGMP message of any kind. When an ICMP message of unknown type is received, it must be silently discarded. Routers will almost always generate ICMP messages but when it comes to a destination host, the number of ICMP messages generated is implementation dependent. The ICMP has many messages that are identified by a “type” field. For each “type” field, there may also be a “code” field which acts as a sub-type. For example, echo reply has a type of 0 and code of 0 while echo request has a type of 0 and code of 8. The list of ICMP types and codes is available at: target="_blank">http://www.iana.org/assignments/icmp-parameters 3. Normal use of ICMPThe Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems. Other RFCs have defined other functionalities for the ICMP: RFC 896 – Source Quench. RFC 950 – Address Mask Extensions. RFC 1191 – Path MTU Discovery. RFC 1256 – Router Discovery. RFC 1349 –Type of Service in the Internet Protocol Suite. 4. Use of ICMP – In a Non-Convention WayPing traffic is ubiquitous to almost every TCP/IP based network and sub-network. It has a standard packet format recognized by every IP-speaking router and is used universally for network management, testing, and measurement. As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through. ICMP can be altered to act as conduit for evil purposes. Some of the ways that ICMP can be used for purposes other than the intended ones are: Reconnaissance Denial of Service Covert Channel 4.1 ReconnaissanceReconnaissance is the first stage in the information gathering process to discover live hosts and some other essence information as part of most planned attack. ICMP messages are broadly categorized into two kinds: [TABLE=width: 90%, align: center][TR][TD=class: h5invert, colspan: 2, align: center]ICMP Messages[/TD][/TR][TR][TD=class: h3invert, width: 50%, align: center]ICMP Query Messages[/TD][TD=class: h3invert, width: 50%, align: center]ICMP Error Messages[/TD][/TR][TR][TD] Echo Request and Echo Reply Time Stamp Request and Reply Information Request and Reply Address Mask Request and Reply[/TD][TD] Destination Unreachable Source Quench Redirect Time Exceeded Parameter Problem[/TD][/TR][/TABLE]By manipulating these ICMP messages, we are able to gather substantial information in the process of information gathering: Host Detection Network Topology ACL Detection Packet Filter Detection OS Fingerprinting 4.1.1 Host Detection and Network TopologyBy using ICMP message, it allows one to identify hosts that are reachable, in particular from the Internet. Traceroute attempts to map network devices and hosts on a route to a certain destination host. Intelligence use of it will allow one to map the topology of a network. 4.1.2 Access Control List (ACL) DetectionICMP Error Messages may help to determine the kind ACL of the filtering device is being used and allow one to choose the tactics accordingly. The idea is to manipulate the total length of the IP Header Field. A crafted packet with total length in the IP Header Filed claiming to be bigger than really what it is. When this packet reaches the host, it will try to grab the data from the area, which is not there. The host will thus issue an ICMP Parameter Problem back to the querying IP address. If there is a packet filtering device present and we probe a targeted network with all possible combination of protocols and services, it will allow us to determine the access control list of the filtering device (which host is allowed to received what type of traffic). The crafted packet can use ICMP, TCP or UDP as the underlying protocols. 4.1.3 Protocol/Port ScanICMP Error Messages (Protocol/Port Unreachable) are the common ways to determine what type of protocols/ports the host is running. Nmap 2.54 beta 1 has integrated the Protocol Scan. It sends raw IP packets without any further protocol header (no payload) to each specified protocol on the target machine. If an ICMP Protocol Unreachable error message is received, the protocol is not in used. 4.1.4 OS FingerprintingUsing ICMP for OS Fingerprinting requires less traffic initiation from the malicious person machine to the target host. The idea is “Which operating system answer what kind of ICMP Query messages”. This is possible because different OS implement differently. Some do not compliant strictly to RFC, while RFC may also optional. Fingerprinting of OS can be achieved via the following: Using ICMP Query Messages Using ICMP Error Messages The ICMP Echo Request/Reply pair was intended to determine whether a host is alive or not. Negative response will either mean it is not alive or ICMP Echo traffic is filtered by a packet filtering device. 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 ICMP Time Stamp Request/Reply pair allows a host to query another for the current time. This allows a sender to determine the amount of latency that a particular network is experiencing. Most operation systems implemented the ICMP Time Stamp Request/Reply. The ICMP Address Mask Request/Reply pair was intended for diskless systems to obtain its subnet mask in use on the local network at bootstrap time. It is also used when a host wants to know the address mask of an interface. RFC 1122 states that the Address Mask is optional. At times, the ICMP Error Messages revealed substantial information about the host or network. For example, receiving a Protocol Unreachable will reveal that the host is alive and that particular protocol queried is not supported. By manipulating certain field in the query, we can generate several ICMP Error Messages. In [1], the author has done a comprehensive research on the use of ICMP in OS fingerprinting. Based on the nature of the different implementation of OS, substantiate information can be gathered using different techniques in manipulating the ICMP messages and observe the response of the target host. The techniques are listed below: Response on ICMP Query Messages Types on a targeted host Response on ICMP Query Messages Types on a broadcast address IP TTL value on the ICMP Messages (Request and Reply) Response on ICMP Query Messages with Code Field ? 0 Response on the ICMP Query Messages with Precedence Bits value ? 0 Response on the ICMP Query Messages with TOS value ? 0 Response on the ICMP Query Messages with TOS unused bit = 1 Response on the ICMP Query Messages with Reserved Bit Flag = 1 Response on the ICMP Query Messages with DF set ICMP Error Message echoing integrity with ICMP Port Unreachable Error Message A detailed tabulation can be obtained in [1]. We extracted some results and conduct some fingerprint on the following operating systems: Solaris Linux Windows Family (Win 98/NT/2000) 4.1.4.1 Fingerprinting HPUX 10.20, Solaris and Linux Figure 1 shows an example the technique of fingerprinting HPUX 10.20, Solaris and Linux operating systems. Using SING tool [9], we run through the process of fingerprinting: ICMP Time Stamp Request targeted at broadcast address: We first generated an ICMP Time Stamp Request to the whole segment x.x.x.255. # sing -tstamp x.x.x.255SINGing to x.x.x.255 (x.x.x.255): 20 data bytes20 bytes from x.x.x.64: seq=0 ttl=255 TOS=0 diff=8836420 bytes from x.x.x.215: seq=0 ttl=255 TOS=0 diff=0 (DUP!)20 bytes from x.x.x.1: seq=0 ttl=255 TOS=0 diff=51332009 (DUP!)20 bytes from x.x.x.2: seq=0 ttl=255 TOS=0 diff=55541589 (DUP!)20 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 diff=-127012 (DUP!)Note that x.x.x.1 and x.x.x.2 is the network switch devices which we will not discussed here. Also x.x.x.215 is the IP address of the machine running sing and hping2 tools. x.x.x.64 and x.x.x.239 response to the ICMP Time Stamp Request targeted at broadcast address x.x.x.255. Note that their responded TTL is 255, which is a typically response TTL from Unix system. These two machines could then be Sun Solaris, Linux or HPUX 10.20. The Snort trace: 07/26-09:33:46.281306 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x36x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40Type:13 Code:0 TIMESTAMP REQUEST23 31 00 00 00 55 D9 A9 00 00 00 00 00 00 00 00 #1...U..........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-09:33:46.281488 0:50:BA:C0:61:99 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40x.x.x.64 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:55 IpLen:20 DgmLen:40Type:14 Code:0 TIMESTAMP REPLY23 31 00 00 00 55 D9 A9 00 57 32 D5 00 57 32 D5 #1...U...W2..W2.=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-09:33:46.282107 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38831 IpLen:20 DgmLen:40 DFType:14 Code:0 TIMESTAMP REPLY23 31 00 00 00 55 D9 A9 00 53 E9 85 00 53 E9 85 #1...U...S...S..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Information Request targeted at broadcast address We then generated an ICMP Information Request to the same segment x.x.x.255. # sing -info x.x.x.255SINGing to x.x.x.255 (x.x.x.255): 8 data bytes--- x.x.x.255 sing statistic ---200 packets transmitted, 0 packets received, 100% packet lossNo machine response to this request. We can conclude that x.x.x.64 and x.x.x.239 is either Sun Solaris or Linux machine. The Snort trace: 07/26-09:43:56.721478 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2Ax.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28Type:15 Code:0 INFO REQUEST49 31 00 00I1..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-09:43:57.713811 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2Ax.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28Type:15 Code:0 INFO REQUEST49 31 01 00I1..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Address Mask Request targeted at single host Lastly, we generated an ICMP Address Mask Request to the two specific IP addresses, x.x.x.64 and x.x.x.239: # sing -mask x.x.x.64SINGing to x.x.x.64 (x.x.x.64): 12 data bytes--- x.x.x.64 sing statistics ---10 packets transmitted, 0 packets received, 100% packet lossx.x.x.64 did not response. We can therefore conclude that x.x.x.64 is a Linux machine. The Snort trace: 07/26-09:49:06.544282 0:80:C7:C0:E2:DB -> 0:50:BA:C0:61:99 type:0x800 len:0x2Ex.x.x.215 -> x.x.x.64 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32Type:17 Code:0 ADDRESS REQUEST5F 31 00 00 00 00 00 00_1......=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+Address Mask Request to x.x.x.239: # sing -mask x.x.x.239SINGing to x.x.x.239 (x.x.x.239): 12 data bytes12 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=1 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=2 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=3 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=4 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=5 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=6 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=7 DF! ttl=255 TOS=0 mask=255.255.255.012 bytes from x.x.x.239: seq=8 DF! ttl=255 TOS=0 mask=255.255.255.0--- x.x.x.239 sing statistics ---9 packets transmitted, 9 packets received, 0% packet lossx.x.x.239 response to Address Mask Request. It is therefore running Sun Solaris. The Snort trace: 07/26-09:48:52.177080 0:80:C7:C0:E2:DB -> 8:0:20:FD:AE:90 type:0x800 len:0x2Ex.x.x.215 -> x.x.x.239 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32Type:17 Code:0 ADDRESS REQUEST5E 31 00 00 00 00 00 00^1......=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-09:48:52.177292 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38853 IpLen:20 DgmLen:32 DFType:18 Code:0 ADDRESS REPLY5E 31 00 00 FF FF FF 00^1......=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+4.1.4.2 Fingerprinting Windows Family (95/98/ME/NT/20000)Figure 2 shows an example of fingerprinting the Windows Family. We run through the process of fingerprinting using NMAP [11], HPING2 [10] and SING [9]. Windows Family typically response ICMP Echo Reply with a TTL value of 128. The first thing will then to determine the live host with ICMP ECHO Reply of TTL = 128. By using nmap, three IP addresses are identify with TTL ~ 128: Machine 1: x.x.x.41Machine 2: x.x.x.183Machine 3: x.x.x.69Using the above methodology, for machine 1 (x.x.x.41), we have: ICMP Echo Request with Code Field ? 0 We first send a ICMP Echo Request with Code Field ? 0 (Value = 77) # hping2 -1 -c 1 -K 77 x.x.x.41HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29120 rtt=1.8 ms It responded with Code field = 0. Therefore, it belongs to Windows Family. Snort trace: 07/26-16:23:28.745427 x.x.x.215 -> x.x.x.41ICMP TTL:64 TOS:0x0 ID:46193 IpLen:20 DgmLen:28Type:8 Code:77 ID:61445 Seq:0 ECHO=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:23:28.746064 x.x.x.41 -> x.x.x.215ICMP TTL:128 TOS:0x0 ID:29120 IpLen:20 DgmLen:28Type:0 Code:0 ID:61445 Seq:0 ECHO REPLY=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Time Stamp Request We next send an ICMP Time Stamp Request. # sing -tstamp -c 1 x.x.x.41SINGing to x.x.x.41 (x.x.x.41): 20 data bytes20 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 diff=1650412099* It also responded. It can then be Windows 98, ME or 2000. Snort trace: 07/26-16:23:46.368947 x.x.x.215 -> x.x.x.41ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40Type:13 Code:0 TIMESTAMP REQUESTF1 05 00 00 01 CD 37 C0 00 00 00 00 00 00 00 00 ......7.........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:23:46.369418 x.x.x.41 -> x.x.x.215ICMP TTL:128 TOS:0x0 ID:29376 IpLen:20 DgmLen:40Type:14 Code:0 TIMESTAMP REPLYF1 05 00 00 01 CD 37 C0 E4 2C 82 03 E4 2C 82 03 ......7..,...,..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Echo Request with TOS Unused Bit = 1 We next send an ICMP Echo Request with TOS Unused Bit = 1. # hping2 -1 -o 1 -c 1 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29632 rtt=0.8msIt replied with the same TOS value. As Windows 2000 will reply with a TOS value of 0, we can conclude that this machine can be either Windows 98 or ME. Snort trace: 07/26-16:24:04.098715 x.x.x.215 -> x.x.x.41ICMP TTL:64 TOS:0x1 ID:4907 IpLen:20 DgmLen:28Type:8 Code:0 ID:61957 Seq:0 ECHO=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:24:04.099161 x.x.x.41 -> x.x.x.215ICMP TTL:128 TOS:0x1 ID:29632 IpLen:20 DgmLen:28Type:0 Code:0 ID:61957 Seq:0 ECHO REPLY=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+Address Mask Request Finally, we check the response when requesting the address mask. # sing -mask -c 1 x.x.x.41SINGing to x.x.x.41 (x.x.x.41): 12 data bytes12 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 mask=255.255.255.0It responded. So we can conclude this machine is Windows 98. Snort trace: 07/26-16:24:32.851707 x.x.x.215 -> x.x.x.41ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32Type:17 Code:0 ADDRESS REQUESTF3 05 00 00 00 00 00 00........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:24:32.852143 x.x.x.41 -> x.x.x.215ICMP TTL:128 TOS:0x0 ID:30400 IpLen:20 DgmLen:32Type:18 Code:0 ADDRESS REPLYF3 05 00 00 FF FF FF 00........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+For machine 2 (x.x.x.183): ICMP Echo Request with Code Field ? 0 When an ICMP Echo Request with Code Field = 77 is send to this machine, it responded with Code Field = 0, suggesting that it belongs to the Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.183HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7030 rtt=17.8 msSnort trace: 07/26-16:07:06.186426 x.x.x.10 -> x.x.x.183ICMP TTL:64 TOS:0x0 ID:37429 IpLen:20 DgmLen:28Type:8 Code:77 ID:56325 Seq:0 ECHO=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:07:06.203810 x.x.x.183 -> x.x.x.10ICMP TTL:119 TOS:0x0 ID:7030 IpLen:20 DgmLen:28Type:0 Code:0 ID:56325 Seq:0 ECHO REPLY=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Time Stamp Request It also responded to ICMP Time Stamp Request, suggesting that it can be Windows 98, ME or 2000. # sing -tstamp -c 1 x.x.x.183SINGing to x.x.x.183 (x.x.x.183): 20 data bytes20 bytes from x.x.x.183: seq=0 ttl=119 TOS=0 diff=1247439485*Snort trace: 07/26-16:07:29.668839 x.x.x.10 -> x.x.x.183ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40Type:13 Code:0 TIMESTAMP REQUESTDD 05 00 00 01 BE 50 84 00 00 00 00 00 00 00 00 ......P.........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:07:29.683450 x.x.x.183 -> x.x.x.10ICMP TTL:119 TOS:0x0 ID:7032 IpLen:20 DgmLen:40Type:14 Code:0 TIMESTAMP REPLYDD 05 00 00 01 BE 50 84 CC 18 BB 01 CC 18 BB 01 ......P.........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Echo Request with TOS Unused Bit = 1 When it received an ICMP Echo Request with TOS Unused Bit = 1, it responded with TOS Unused Bit = 0. Therefore, we concluded that it is a Windows 2000 machine. # hping2 -1 -o 1 -c 1 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7060 rtt=187.4 msSnort trace: 07/26-16:08:06.142181 x.x.x.10 -> x.x.x.183ICMP TTL:64 TOS:0x1 ID:56666 IpLen:20 DgmLen:28Type:8 Code:0 ID:56837 Seq:0 ECHO=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:08:06.329204 x.x.x.183 -> x.x.x.10ICMP TTL:119 TOS:0x0 ID:7060 IpLen:20 DgmLen:28Type:0 Code:0 ID:56837 Seq:0 ECHO REPLY=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Finally for machine 3 (x.x.x.69): ICMP Echo Request with Code Field ? 0 It responded to an ICMP Echo Request with Code Field ? 0, confirming that it belongs to Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.69HPING x.x.x.69 (eth0 x.x.x.69): icmp mode set, 28 headers + 0 data bytes50 bytes from x.x.x.69: icmp_seq=0 ttl=128 id=58126 rtt=2.2 msSnort trace: 07/26-16:37:25.892705 x.x.x.215 -> x.x.x.69ICMP TTL:64 TOS:0x0 ID:11485 IpLen:20 DgmLen:28Type:8 Code:77 ID:64005 Seq:0 ECHO=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+07/26-16:37:25.893486 x.x.x.69 -> x.x.x.215ICMP TTL:128 TOS:0x0 ID:58126 IpLen:20 DgmLen:28Type:0 Code:0 ID:64005 Seq:0 ECHO REPLY=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ICMP Time Stamp Request When ICMP Time Stamp Request is sent to it, this time, it did not respond. Using the methodology, we concluded that it can be either a Windows 95 or Windows NT. # sing -tstamp x.x.x.69SINGing to x.x.x.69 (x.x.x.69): 20 data bytes--- x.x.x.69 sing statistic ---86 packets transmitted, 0 packets received, 100% packet lossSnort trace: 07/26-16:37:46.867499 x.x.x.215 -> x.x.x.69ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40Type:13 Code:0 TIMESTAMP REQUESTFB 05 00 00 01 DA 0A F3 00 00 00 00 00 00 00 00 ................=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+We thus see that intelligence use of ICMP Messages could reveal substantial information about a host. 4.2 Denial of Service (DoS)Using ICMP as a means to cause DoS is not new. CERT/CC has issued an advisory on Denial of Service via Ping in 1996 (CA-1996-26). Ping of Death is one of the common uses of ICMP to cause a machine to crash. Here we mentioned some other well-known DoS using ICMP as a means. 4.2.1 Smurf DoSThe infamous Smurf attack preys on ICMP’s capability to send traffic to the broadcast address. Many hosts can listen and response to a single ICMP echo request sent to a broadcast address. This capability is used to execute a DoS attack. The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses. In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages. When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is subjected to network congestion that could potentially make the network unusable. More detailed description of Smurf attack can be found in [5]. 4.2.2 Tribe Flood Network (TFN)The Tribe Flood Network (TFN) attack is another DoS attack that uses ICMP for communication. TFN is made up of client and daemon programs, which implement a distributed network denial of service tool capable of waging ICMP flood, SYN flood, UDP flood, and Smurf style attacks. The attacker(s) control one or more clients, each of which can control many daemons. The daemons are all instructed to coordinate a packet-based attack against one or more victim systems by the client. Communication from the TFN client to daemons is accomplished via ICMP Echo Reply packets. Each "command" to the daemons is sent in the form of a 16-bit binary number in the ID field of an ICMP Echo Reply packet (The sequence number is a constant 0x0000, which would make it look like the response to the initial packet sent out by the "ping" command). This is to prevent the kernel on the daemon system from replying with an ICMP Echo Reply packet. The daemon then responds (if need be) to the client(s), also using an ICMP Echo Reply packet. The payload differs with TFN, as it is used for sending command arguments and replies. Some network monitoring tools do not show the data portion of ICMP packets, or do not parse all of the various ICMP type-specific fields, so it may be difficult to actually monitor the communication between client and daemon. A detailed analysis of TFN can be found in [6]. 4.2.3 WinFreezeWinFreeze is a DoS attack against Windows. A small exploit code that can cause a Windows 9x/NT box on the local LAN to freeze completely. The program initiates ICMP/Redirect-host messages storm that appears to come from a router (by using the router's IP). The Windows machine will receive redirect host messages causing it to change its own routing table. This will make it get stuck, or operate very slowly until a reboot is done. 4.3 Covert Channel Many firewalls and networks consider ping traffic to be benign and will allow it to pass through. Use of ping traffic can open up covert channels through the networks in which it is allowed. 4.3.1 LokiThe concept of the Loki is simple: arbitrary information tunneling in the data portion of ICMP Echo Request and ICMP Echo Reply packets. Loki exploits the covert channel that exists inside of ICMP Echo traffic. ICMP Echo packets have the option to include a data section. This data section is used when the record route option is specified, or, the more common case, (usually the default) to store timing information to determine round-trip times. Although the payload is often timing information, there is no check by any device as to the content of the data. So, as it turns out, this amount of data can also be arbitrary in content as well. Therein lies the covert channel. Most network devices do not filter the contents of ICMP Echo traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP Echo traffic. If a host is compromised and a Loki server is installed, it can response to traffic send to it by a Loki client. Because the programs use ICMP Echo Reply packets for communication, it will be very difficult (if not impossible) to block it without breaking most Internet programs that rely on ICMP. With a proper implementation, the channel can go completely undetected for the duration of its existence. Detection can be difficult. If you know what to look for, you may find that the channel is being used on your system. However, knowing when to look, where to look, and the mere fact that you should be looking all have to be in place. A surplus of ICMP Echo Reply packets with a garbled payload can be ready indication the channel is in use. More information on the Loki project can be obtained in [7]. 5. Filtering ICMP Traffic and the Challenge for the IDSNetwork devices requires ICMP Messages for communications. ICMP is a protocol that is supposed to be used to alert hosts of problem conditions or exchange messages. However, using it in a malicious manner allows one to dig out host information and network topology. To use a Network Intrusion Detection System to actively monitor the network for malicious ICMP traffic is laborious. Given this, appropriate filtering of ICMP traffic should be done to minimize the potential threat. It is therefore important to understanding how operating systems response to ICMP Messages. This will allow us to determine what type of ICMP Messages should only be allow in and out of the network. With appropriate configuration of the packet filtering device to block unnecessary ICMP Messages, potential threats resulting from ICMP Messages can be reduced. This, however, should be done wisely and selectively. For example, incoming “ICMP Error Message, Fragmentation Needed but Don’t Fragment Set”, will be necessary to inform the internal host on such errors and to adjust the datagrams accordingly. Even with proper filtering of ICMP traffic, NIDS should still be deployed to monitor the kind of ICMP activities. The challenge of the NIDS will be have accurate signatures to detect malicious ICMP traffic. Host-based IDS is another option. Nevertheless, it still needs “inputs” to monitor the traffic accurately. Ultimately, human will be required to perform the final analysis of the IDS detects to determine whether detects are legitimate or hostile. References:[1] Ofir Arkin, ICMP Usage in Scanning – The Complete Know How, ??????????? [2] Stephen Northcutt and Judy Novak, Network Intrusion Detection [3] ICMP Parameters Internet Control Message Protocol (ICMP) Parameters [4] RFC 792 Internet Control Message Protocol http://www.ietf.org/rfc/rfc0792.txt [5] Craig Huegen, The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects, http://www.pentics.net/denial-of-service/white-papers/smurf.cgi [6] David Dittrich, The “Tribe Flood Network” Distributed Denial of Service Attack Tool, http://staff.washington.edu/dittrich/misc/tfn.analysis [7] Loki Project, http://www.phrack.org/show.php?p=49&a=6 [8] RFC 1122 Requirements for Internet Hosts – Communication Layers, http://www.ietf.org/rfc/rfc1122.txt [9] SING utility, SING | Free System Administration software downloads at SourceForge.net [10] HPING2 utility, hping2 | Free Home & Education software downloads at SourceForge.net [11] NMAP, Nmap - Free Security Scanner For Network Exploration & Security Audits.Sursa: https://www.sans.org/security-resources/idfaq/icmp_misuse.php Quote
