Netmask-based ICMP Echo Request Smurf Broadcast Scanning with Crafted ICMP Payloads using SendIP

Jeff Holland

7/20/01

 

This paper will address the specific reconnaissance technique coined “Netmask-based ICMP Echo Request Smurf Host and Broadcast Scan with Crafted ICMP Payloads” using the tool SendIP.


Reconnaissance Technique:


Name: Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads

Variants: Broadcast scans to IP addresses with a fourth octet of 0 or 255 are a generalization of this attack. This attack may also be launched without crafting the ICMP payload.

Operating System: Any OS that responds to ICMP echo requests sent to a broadcast address.

Protocols/Services: IP, ICMP, IP Subnetting, and IP Broadcasting

Description: This reconnaissance technique attempts to map a variably subnetted network's broadcast addresses for later possible use in Smurf attack. What is unique to this attack is that the ICMP payload has been crafted to contain only the broadcast IP addresses. A packet is also sent to the network address of the subnets that are being mapped since BSD-based stacks treat the network address as a broadcast address.


Exploit Details:

 

Name: SendIP (Version 1.5)

Variants: Broadscan, SING, Hping, Hping2, and Nmap are just a few of the tools that can also perform Smurf broadcast scanning.

Operating System: The exploit code was tested using Mandrake Linux 7.1. However, it should run on all Linux and UNIX systems.

Protocols/Services: ICMP

Description: According to the author, Mike Ricketts, "SendIP has a large number of command line options to specify the content of every header of a RIP, TCP, UDP, ICMP or raw IPv4 and IPv6 packet. It also allows any data to be added to the packet. Checksums can be calculated automatically, but if you wish to send out wrong checksums, that is supported too." [1].


Protocol Description: 


IP - Internet Protocol

 

IP is the transport mechanism for all TCP, UDP, IGMP, and ICMP messages. That is, TCP, UDP, IGMP, and ICMP messages are encapsulated in packets called IP datagrams that begin with a 20-byte standard header. If any IP options are present, the IP header may be as large as 60 bytes. Also, note that IP is a connectionless, unreliable protocol that relies on best effort service instead of stateful awareness of successive IP datagrams.

The IP header is shown in Figure 3 below:

 

 

The 4-bit version field refers to the version of IP. The current and most used version is version 4, referred to as IPv4. The 4-bit header length is the number of 32 bit words in the IP header, including any IP options. The 8-bit type of service, or TOS, field is composed of three separate parts: the top 3-bits is a precedence value that is not currently used in current versions of IP, a 4-bit TOS value, and an unused bit that must be set to 0. The 4-bit TOS value is set to 0 when normal service is implied, and is what is most often seen in IP datagrams today. The total length is the total length of the IP datagram in bytes. To derive the length of the data portion of the IP datagram, subtract the header length field from the total length field.

 

The 16-bit identification number is used to uniquely identify each datagram that is sent, and typically increments by one for each packet sent. The 3-bit flags field is used to identify if the packet is fragmented and there are more fragments to follow, or to tell IP not to fragment the datagram. The 13-bit fragment offset is used to repackage the packet stream at the destination host by keeping track of how far the fragment is located in creation order from the original datagram. The 8-bit time-to-live (TTL) value sets an upper bound on the number of hops, or routers, through which the datagram may travel before its lifetime expires. The TTL decrements by one for each hop it makes, and is initialized by the sending hosts' operating system.

 

The 8-bit protocol field is used to identify the protocol that is encapsulated in the IP datagram. The 16-bit checksum field only addresses the IP header, not the IP data payload. The checksum is used to identify datagrams that were corrupted in transit. If so, the packets are discarded. The 32-bit source and destination address fields store the IP address of the sending and receiving hosts. The IP options field is rarely used, but does support options such as strict and loose source routing and security restrictions. Finally, IP encapsulates the data payload, such as an ICMP echo request message.

 

ICMP - Internet Control Message Protocol


ICMP is an integral part of the IP layer that acts like a higher level protocol such as TCP or UDP, and was designed for use as a network diagnostic tool. ICMP messages are sent in some of the following situations [1]:

 

1.      When a datagram cannot reach its destination.

 

2.      When the gateway does not have the buffering capacity to forward a datagram.

 

3.      When the gateway can direct the host to send traffic on a shorter network route.

 

ICMP messages are sent inside a IP datagram using the standard IP header. Figure 4 is a diagram of a 20-byte IP datagram without options and an ICMP message:

 

           

ICMP echo request and echo replies are used to test if a host is reachable across a network. Historically, an echo request message is sent, and if the destination host is reachable, an echo reply message is returned. However, with the widespread use of protocol aware firewalls and router ACL's, this is no longer true. A host may refuse an ICMP echo request, but will accept a telnet connection to port 25 (SMTP) [3].

 

Figure 5, shown below, depicts the standard ICMP echo or echo reply message format [2]:

           

 

The first 8 bits of the ICMP echo and echo reply message is the type field, which defines the format of the remaining message. A type value of zero indicates the ICMP message is an echo reply, and an eight indicates an echo request. The next eight bit field is the code field, and is zero for both echo requests and replies. This field has numerous values in other ICMP types, such as type 3 (destination unreachable messages). The remaining 16 bits of the first four bytes is the checksum field. According to RFC 792, "The checksum is the 16-bit one's complement of the one's complement sum of the ICMP message starting with the ICMP type" [2].

 

The 16 bit identifier and sequence number fields are used to identify echos and replies when the code field is zero. Note that these fields may be set to zero. The identifier field is set to the PID (process ID) of the sending process in UNIX versions of Ping. The sequence number field is set to zero and increments by one for each ICMP echo request packet that is sent. The ICMP message payload is included next in the datagram, if it exists. Also, note that the payload data (as well as the identifier and sequence number) must be returned in the echo reply message. This requirement is what makes the "Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads" reconnaissance technique unique.

 

IP Subnetting

 

IP subnetting is used to partition a network into smaller sub-networks, or subnets. This is done by bit-masking the network IP address with a subnet mask. The subnet mask consists of a netid, subnetid and hostid portion. The first portion of the subnet mask determines the size of the netid and subnetid, and the remainder is the hostid. For example, the mask 255.255.255.224 has 24-bit netid, a 3-bit subnetid (the first 3 bits of the last octet), and a 5-bit hostid.

 

For example, the class C network 192.168.1.0 can be partitioned into two subnets using the subnet mask 255.255.255.128. By doing so, two new networks are created; 192.168.1.0/255.255.255.128 and 192.168.1.128/255.255.255.128. Note that each subnet will have a network address, a broadcast address, and a number of host addresses. Using our variably subnetted network example above, we get the following:


Subnet 1:  192.168.1.0/255.255.255.128

Hosts:  192.168.1.1 - 192.168.1.126

Broadcast Address:  192.168.1.127

 

Subnet 2:  192.168.1.128/255.255.255.128

Hosts:  192.168.1.129 - 192.168.1.254

Broadcast Address: 192.168.1.255


Finally, note that subnet masks may be expressed using an abbreviated notation known as CIDR (Classless Inter-Domain Routing). This notation is derived by adding up the number of 1’s in the subnet mask’s bitmask notation. For example, consider the network 192.168.1.0/255.255.255.128. The subnet mask 255.255.255.128 has a bitwise representation of 11111111 11111111 11111111 10000000. This string has twenty-five consecutive 1’s, so the network and subnet mask can be expressed using the notation 192.168.1.0/25.

 

IP Broadcasting

 

Broadcasting is used to distribute a single datagram to every host on the network or subnet. To accomplish this, a broadcast address exists such that when a packet is received at this address, it is forwarded to every host on that subnet or network depending on which type of broadcast was sent. There are four different types of IP broadcast addresses [3]:

 

Limited Broadcast Address:

 

The address 255.255.255.255 is known as the limited broadcast address. This address is never forwarded by routers, and appears only on the local wire.

 

All Subnets Directed Broadcast Address:

 

This broadcast relies on knowledge of the destination host's subnet mask. For instance, the class B subnet 192.168.255.0/24 has a broadcast address of 192.168.255.255, assuming the IP block 192.168.0.0 has been subnetted. In addition, BSD stacks will also treat the network address as a broadcast address.

 

Subnet Directed Broadcast Address:

 

This broadcast also relies on knowledge of the destination hosts’ subnet mask. This broadcast targets a specific subnet. For instance, the class C subnet 192.168.1.0/27 has a broadcast address of 192.168.1.31.

 

Network Directed Broadcast:

 

This broadcast address addresses a whole network. For example, the class A network 192.0.0.0 has a broadcast address of 192.255.255.255.

 

How the Reconnaissance Technique Works:

 

What differentiates the “Netmask-based ICMP Echo Request Smurf Broadcast Scan with Crafted ICMP Payloads” reconnaissance technique from a general Smurf scan is the crafted payload. The attacker uses a tool, such as SendIP, to modify the ICMP payload to contain the broadcast IP address. The rationale behind this is that the echo reply packet must return the payload data sent in the echo request packet, and therefore the attacker will know which broadcast address corresponds to the responding machine. The attacker also sends an echo request packet to the network address of the suspected subnet. This aids the attacker in correctly identifying the subnet mask used to variably subnet the network.

 

To fully illustrate this attack, we will use a partial variably subnetted class C address block as an example. Many times networks are subnetted in this fashion to dole out various sized subnets to different groups within an organization.

 

Class C IP Block:  192.168.1.0 - 192.168.1.255

 

Subnet 1:  192.168.1.0/28

Hosts:  192.168.1.1 - 192.168.1.14

Broadcast Address:  192.168.1.15

 

Subnet 2:  192.168.1.16/28

Hosts:  192.168.1.17 - 192.168.1.30

Broadcast Address: 192.168.1.31

 

Subnet 3:  192.168.1.32/27

Hosts:  192.168.1.33 -192.168.1.62

Broadcast Address: 192.168.1.255.63

 

Subnet 4:  192.168.1.64/26

Hosts:  192.168.1.65 - 192.168.1.126

Broadcast Address: 192.168.1.255.127

 

Subnet 5:  192.168.1.128/29

Hosts:  192.168.1.129 - 192.168.1.134

Broadcast Address: 192.168.1.135

 

The attacker must decide how to scan the target network. Most often, they will target the subnets that are most commonly created. For example, these might include subnets with a last octet that is a multiple of 64 less 1 (since networks use zero-based counting), and thus have broadcast addresses of 192.168.1.63, 192.168.1.191 and 192.168.1.255. The attacker may also send an echo request to the network address of each of subnet, which also acts as a broadcast address on BSD-based stacks. These addresses would include 192.168.1.0, 192.168.1.128 and 192.168.1.192.

 

However, there are many different ways to variably subnet a class C network. To account for this, and minimize the number of broadcast scans needed to map the network, the attacker sends echo requests to the broadcast and network addresses that they suspect might exist. To identify the networks that exist from those that do not, the attacker inspects the ICMP payload of the echo reply packets (assuming echo replies are received from the victim).

 

For example, suppose the attacker sent crafted ICMP echo requests to the following addresses: 192.168.1.0, 192.168.1.15, 192.168.1.40, and 192.168.1.47. The attacker is guessing we have a subnet with a network address of 192.168.1.0, a broadcast address of  192.168.1.15, and a subnet mask of 255.255.255.240. They are also guessing we have a subnet with a network address of 192.168.1.40, a broadcast address of  192.168.1.47, and a subnet mask of 255.255.255.248. Since the class C network described above does not have a 192.168.1.40 network, but does have a 192.168.1.0 network, they will be able to determine which of the two networks exist and if we are using machines that have a BSD-based stack. In addition, the attacker will know if they guessed the broadcast address correctly, and thus can deduce the subnet mask being used for that network. They accomplish this by inspecting the payload of the echo reply packets for the broadcast IP address that was hardcoded by the SendIP tool.

 

More specifically, if the attacker receives ICMP echo replies with payloads containing the IP addresses 192.168.1.0 and 192.168.1.15, they can deduce that the network 192.168.1.0 exists and uses a subnet mask of 255.255.255.240.

 

This technique allows the attacker to maximize the network topology information returned from a single scan, and yet remain somewhat covert among all the other ICMP echo requests an organization might receive.

 

How the Malicious Program Works:


SendIP works by taking command line arguments and building the desired packet based on the arguments. If an argument is not supplied, a default value is used. For instance, when crafting an ICMP echo request packet, if a value for the IP ID is not passed as an argument on the command line, the default value is set using a random value. If for any option the argument “r” is supplied, a random value is used. Also, the tool sets the ICMP ID and sequence number to 0.

 

To craft the ICMP payload, the attacker must pad the payload string with the appropriate amount of bytes to get past the ICMP header fields and into the ICMP payload. This is because the tool copies the payload string on the command line into the ICMP message data structure, and then overwrites the ICMP header fields with either the command line supplied arguments or the default values. If the attacker does not pad the payload string with the appropriate amount of fill, the corresponding amount of bytes from the payload will be truncated.

 

Diagram of the Attack:


The following diagram is just one representation of a network that is vulnerable to this

attack.

 

 

How to Perform Netmask-based ICMP Echo Request Smurf Broadcast Scanning With Crafted ICMP Payloads Using SendIP:


SendIP gives the user the option of crafting a TCP, UDP, RIP, or ICMP packet. The tool also has a man page that is bundled with the tar ball and rpm package. The SendIP command line format and options as defined in the man page are as follows:

 

./sendip <hostname> -p <type> -d <data> <options>

 

Where:

<hostname> is the name of the host the packet is being sent to. If an argument

is not supplied, the packet is sent to the localhost, 127.0.0.1.

 

<type> is the packet type. The default type is IP, but can be set to TCP, UDP or ICMP. RIP packets are transmitted via UDP, so all UDP options apply.

 

<data> is the packet payload in hex. If an argument is not supplied, the default is 10 bytes of 0’s. The “-d” flag must be used for passing payload data to the SendIP binary on the command line.

 

<options> are the field values the attacker may set from the command line.

Table 1 shows the IPv4 ICMP options, as defined in the SendIP man page. Note that the default value “Correct” means the value cannot be crafted or is determined based on other field values from the message. In addition, SendIP supports IPv6.

 

      Option Flag                     ICMP Field                  Default Value                      Notes

-ct

Type

8

See RFC 792

-cd

Code

0

 

-cc

Checksum

“Correct”

See RFC 792

Table 1: ICMP IPv4 SendIP Command Line Options


Note that if an ICMP packet is to be sent to a broadcast address, the “-sb” option must be used. The argument that is supplied to the –sb option is the number of ICMP packets to be sent to the broadcast address.

 

SendIP also lets the attacker define the IP header field values on the command line. Table 2 below shows the SendIP options used to set these fields.

 

      Option Flag                        IP Field                      Default Value                     Notes

-is

Source IP

127.0.0.1

 

-id

Destination IP

“Correct”

 

-ih

Header Length

“Correct”

 

-iy

Type of Service (TOS)

0

See RFC791

-il

Length

“Correct”

 

-ii

Identification Number

Random

 

-ifr

Reserved Flag

0

 

-ifd

Don’t Fragment

0

 

-ifm

More Fragments

0

 

-if

Fragment Offset

0

 

-it

TTL

255

 

-ip

Protocol

“Correct for type”

 

-ic

Checksum

“Correct”

 

-io

Options

 

“not yet implemented”

Table 2: IP IPv4 SendIP Command Line Options

 

Using these options, an attacker could send a crafted ICMP echo reply to the host 192.168.1.21 with the destination address in the ICMP payload, a TTL of 255, a TOS of 0x04 (decimal 4), an IP ID of 41101, and a source address of 192.168.1.28 with the following command:

 

./sendip 192.168.1.21 -p ICMP -d "00000000c0a80115" -ct 0

-it 255 -iy 0x04 -ii 41101 –is 192.168.1.28

 

Note that the ICMP payload string is padded with 8 bytes of zeros, which is number of bytes preceding the ICMP payload as shown in Figure 5.

 

Signature of the Attack:


The following traffic shows a “standard” ping to a Cisco router and its reply, the traffic signature of the SendIP tool to the network address and broadcast address of a subnet, and the resulting responses. The following traffic was generated on a class C subnet with the following characteristics (note that the IP addresses and MAC addresses have been sanitized):

 

Subnet Network Address: 192.168.1.0

Subnet Netmask: 255.255.255.224

Subnet Hosts: 192.168.1.1 - 192.168.1.30

Subnet Broadcast Address: 192.168.1.31

 

The following host was used to generate the traffic:

 

Attacking host (Linux box running Mandrake 7.1): 192.168.1.28

 

A script was used to generate the “standard” ping and the SendIP pings. The script used is as follows:

 

#!/bin/sh

 

ping 192.168.1.30

 

./sendip 192.168.1.0 -p ICMP -d "00000000c0a80100"

–sb 1 -it 240 -iy 0xC0 -ii 1206 -ct 8 -is 192.168.1.28

 

./sendip 192.168.1.31 -p ICMP -d "00000000c0a8011F"

-sb 1 -it 240 -iy 0xC0 -ii 1206 -ct 8 -is 192.168.1.28

 

Snort captured the traffic to a file using the following command:

 

./snort –dve > sendip_traffic

The responses to the broadcast packets were generated by machines running various versions of Solaris (2.6, 7, and 8), as well as two Cisco 2600 routers. There was also NT machines in the subnet, but NT’s do not respond to echo requests sent to the broadcast address. The packet capture from Snort is shown below:

 

Here we see the attacker pinging the 192.168.1.30 host. Take note of the TTL, IP ID number, the TOS number, the ICMP ID and sequence number, and the ICMP payload data. These values are characteristic of a non-crafted ICMP echo request message sent from a Linux host. Note the payload will look different, and may contain more or less data, if the sender uses the “-s” option in their ping command.

 

06/11-10:12:13.191427 0:D0:59:13:a:b -> 0:30:80:3C:a:b type:0x800 len:0x62

192.168.1.28 -> 192.168.1.30 ICMP TTL:64 TOS:0x0 ID:290 IpLen:20 DgmLen:84

Type:8  Code:0  ID:38403   Seq:0  ECHO

CD DF 24 3B F1 E7 02 00 08 09 0A 0B 0C 0D 0E 0F  ..$;............

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./

30 31 32 33 34 35 36 37                          01234567

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Here we see the ICMP echo reply from the Cisco router. Note the TTL value has been set to 255, the TOS is 0, the IP ID, and the ICMP ID and sequence number are the same as in the ICMP echo request. Also, the ICMP payload from the request is returned in the reply. The fact that the IP ID is the same can be used in doing OS fingerprinting in this attack.

 

06/11-10:12:13.192641 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x62

192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0x0 ID:290 IpLen:20 DgmLen:84

Type:0  Code:0  ID:38403  Seq:0  ECHO REPLY

CD DF 24 3B F1 E7 02 00 08 09 0A 0B 0C 0D 0E 0F  ..$;............

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./

30 31 32 33 34 35 36 37                          01234567

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Next we’ll see the attacking host sending crafted ICMP echo request messages to 192.168.1.0 using the SendIP tool. Notice the TTL, TOS, IP ID, and ICMP payload data are set to the values passed on the command line in the script above. In particular, notice the payload is the destination IP address in hex.

 

Here we send an echo request to the network address of the subnet.

 

06/12-10:56:37.916820 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2E

192.168.1.28 -> 192.168.1.0 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:8  Code:0  ID:0   Seq:0  ECHO

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Notice that the echo replies have a different IP ID than the request, except the hosts 192.168.1.25 and 192.168.1.30 (both are Cisco routers).

 

06/12-10:56:37.916938 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.8 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:37552 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.916940 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.1 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:38350 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.916954 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.9 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:29590 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.916974 8:0:20:A9:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.26 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:50336 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.916977 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.15 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:51382 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.916989 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.14 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:30044 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.917776 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/12-10:56:37.917979 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 00                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Now the attacking host sends an echo request to the broadcast address of the targeted subnet. Again, the payload is the destination IP address in hex.

 

06/11-09:16:50.509428 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2E

192.168.1.28 -> 192.168.1.31 ICMP TTL:240 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:8  Code:0  ID:0   Seq:0  ECHO

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

The remaining portion of the packet capture shows the hosts in the 192.168.1.0 network responding to the attacking hosts’ ICMP echo request to the broadcast address.

 

06/11-09:16:50.509535 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.1 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:12024 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509551 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.8 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:11521 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509572 8:0:20:B4:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.9 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:3149 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509606 8:0:20:F8:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.14 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:6493 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509609 8:0:20:A9:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.26 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:29865 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509621 8:0:20:B2:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.20 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:6403 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.509624 8:0:20:FD:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.15 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:30341 IpLen:20 DgmLen:32 DF Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.510403 0:2:16:3E:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.25 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/11-09:16:50.510589 0:30:80:3C:a:b -> 0:D0:59:13:a:b type:0x800 len:0x3C

192.168.1.30 -> 192.168.1.28 ICMP TTL:255 TOS:0xC0 ID:1206 IpLen:20 DgmLen:32

Type:0  Code:0  ID:0  Seq:0  ECHO REPLY

C0 A8 01 1F                                      ....

 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Had the attacker not known the subnet mask, and sent two ICMP echo requests to the broadcast addresses 192.168.1.31 (subnet mask of 255.255.255.224) and 192.168.1.15 (subnet mask 255.255.255.240), he would have known which of the two subnet broadcast addresses was correct based on the ICMP echo reply packet’s payload.

 

How to Protect against Smurf Broadcast Scanning:


The following measures should be taken to protect your organization from being scanned for Smurf amplifiers and from suffering a Smurf attack.

 

1.      Do not allow ICMP echo requests to or past your firewall from the Internet. Depending on your network policy, you may wish to block echo requests at the router and only allow in echo replies [4].

 

2.      Do not allow ICMP directed broadcasts to the router directly connected to your internal subnets. For Cisco routers, apply the following command to every interface on the router: no ip directed-broadcast. Note that in Cisco IOS 12.0 and higher, this rule is the default [5].

 

3.      Implement egress filtering to ensure a Smurf attack is not launched using reserved IP addresses to or from your internal network [6]. The following papers provide an explanation of egress filtering and gives illustrated examples on how to implement egress filtering and other critical router blocking recommendations:

 

What is Egress Filtering and How Can I Implement It? Egress Filtering v 0.2

http://www.sans.org/infosecFAQ/firewall/egress.htm

 

Cisco Anti-Spoof Egress Filtering

http://www.sans.org/dosstep/cisco_spoof.htm

 

Top Ten Blocking Recommendations Using Cisco ACLs - Securing the Perimeter with Cisco IOS 12 Routers

http://www.sans.org/infosecFAQ/firewall/blocking_cisco.htm

 

4.      To determine if your network is being used a Smurf amplifier, or to see if ICMP echo request packets with crafted payloads are being sent to your network from known Smurf amplification sites, check http://www.netscan.org. This site contains a browsable and searchable list of known ICMP Smurf amplifiers.

 

5.      Consider loading a Smurf amplifier-blocking ACL into your router. The following site has an option to print a current list of Smurf amplifiers in Cisco ACL format to your browser screen: http://www.powertech.no/smurf/list.cgi?format=cisco-acl. As of 6/10/01 at 21:12:51 CET, this list contained ACL rules for 668 known Smurf amplifier addresses.

 

6.      Use an IDS such as Snort that can implement a custom signature that looks at the IP and ICMP header fields and packet payload to detect a "Netmask-based ICMP Echo Request Smurf Broadcast Scans with Crafted ICMP Payloads" attack. The following Snort Version 1.7 rule will accomplish this:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Echo Request SendIP Smurf Scanner and Subnet Broadcast Recon"; itype:8; icmp_id:0; icmp_seq:0; content: "| The first two or three octets of your IP block in here, in hex, without spaces. See the note below. |";)

 

Note: If your IP block is the class C network 192.168.1.* or the class B network 192.168.*.*, the content string should be: “|C0A801|” or  “|C0A8|”, respectively.

 

An ICMP echo request packet with a crafted IP ID, ICMP ID and ICMP sequence number sent from SendIP, and detected by Snort version 1.7 using the default signatures from http://www.snort.org, will be identified by the “ICMP Broadscan Smurf Scanner” signature in the icmp.rules file. This is a false identification. The Broadscan tools, as well as hping2 (all available at http://packetstormsecurity.org/UNIX/scanners), cannot craft the IP ID or the ICMP ID number without custom modification of the source code. See Appendix A for packet traces from the Broadscan and hping2 tools.

 

Of course the attacker could reverse the destination address octets in the payload, or devise a totally random mapping they store offline (ie 192.168.1.0 -> cat, 192.168.1.31 -> dog, etc.). This would render the Snort signature useless in this specific case. However, the “ICMP Broadscan Smurf Scanner” signature is generic enough that it will trigger on such a packet.

 

Finally, it should be noted that ISS Realsecure does not have the ability to detect this particular attack. Realsecure only identifies the packets as  "ICMP Echo Requests". After inspecting the Access database table Realsecure uses to store the event data, very few of the IP and ICMP fields are logged. In particular, the TOS and ICMP payload data are not logged. These fields were critical in identifying this particular attack and the tool suspected of creating it.

 

Source Code:


The SendIP program is available at the following URL’s:

 

http://www.earth.li/projectpurple/progs/sendip.html

 

http://packetstormsecurity.org/UNIX/utilities/sendip-1.5.tar.gz

 

The program can be downloaded as a tar ball, source RPM or a binary RPM from the first URL, and as a tar ball from Packetstorm. There are numerous files in the package, including source code files, header files, a makefile and shell script, and a GNU Public License file. For this reason, the source code and its accompanying files will not be included here.

 

All testing and traces produced for this paper was done using SendIP version 1.5 from the Packetstorm web site.


References

[1] Ricketts, Mike “SendIP”, April 26, 2001. URL: http://www.earth.li/projectpurple/progs/sendip.html (June 2, 2001).

 

[2] Postel, J. “Internet Control Message Protocol DARPA Internet Program Protocol Specification” RFC 792. September, 1981. URL:

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0792.html (10 June, 2001).

 

[3] Stevens, W. Richard “TCP/IP Illustrated, Volume 1” Addison-Wesley, 1994.

URL: http://www.bookpool.com/.x/a2x6nrz4y8/sm/0201633469

 

[4] Winters, Scott “Top Ten Blocking Recommendations Using Cisco ACL, Securing the Perimeter with Cisco IOS 12 Routers” August 15, 2000. URL:

http://www.sans.org/infosecFAQ/firewall/blocking_cisco.htm (10 June, 2001).

 

[5] Cisco Sytems Inc. “Improving Security on Cisco Routers” 1992-2001. URL:

http://www.cisco.com/warp/public/707/21.html (10 June, 2001).

 

[6] SANS Institute “Cisco Anti-Spoof Egress Filtering” Revision 1.26. March 23, 2000. URL: http://www.sans.org/dosstep/cisco_spoof.htm (10 June, 2001).


Appendix A

 

Snort packet captures of the broadscan.c, broadscan05.c and hping2-beta54 tools sending crafted ICMP echo requests.

 

The Broadscan tools cannot craft an ICMP ID of 0, or a TOS value of 0xC0, without the attacker significantly modifying the source code. In addition, the broadscan packet captures below reflect a few modifications to the hardcoded IP octets in the source code to enable the tool to run on my network. These modifications did not affect the attack signature in any way, other than the destination address having a last octet that the original source code could not create. All the following traces were obtained from traffic created by binaries compiled and executed using Mandrake Linux 7.1.

 

broadscan.c

 

06/06-15:15:17.032604 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x62

192.168.1.28 -> 192.168.1.31 ICMP TTL:64 TOS:0x0 ID:1064 IpLen:20 DgmLen:84

Type:8  Code:0  ID:54020   Seq:0  ECHO

55 8F 1E 3B 3D 7F 00 00 08 09 0A 0B 0C 0D 0E 0F  U..;=...........

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./

30 31 32 33 34 35 36 37                          01234567


broadscan05.c

 

06/06-15:14:32.398046 0:D0:59:13:a:b -> FF:FF:FF:FF:FF:FF type:0x800 len:0x62

192.168.1.28 -> 192.168.1.31 ICMP TTL:64 TOS:0x0 ID:1062 IpLen:20 DgmLen:84

Type:8  Code:0  ID:51716   Seq:0  ECHO

28 8F 1E 3B AD 12 06 00 08 09 0A 0B 0C 0D 0E 0F  (..;............

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................

20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./

30 31 32 33 34 35 36 37                          01234567

 

Note that the -E option in hping2 could supposedly be used to read data from a file, which might create the crafted ICMP. However, I could not get the IP ID to hardcode to a single, unchanging value, or craft the ICMP ID to be 0. Hping2 can however craft the TOS value.

 

hping2-beta54

 

Output from the command: hping2 192.168.1.26 -1 -N 0 -o C0 -C 8 -K 0 -d 4


 06/07-10:42:05.635143 0:D0:59:13:a:b -> 8:0:20:A9:a:b type:0x800 len:0x2E

192.168.1.28 -> 192.168.1.26 ICMP TTL:64 TOS:0xC0 ID:1104 IpLen:20 DgmLen:32

Type:8  Code:0  ID:44036   Seq:0  ECHO

58 58 58 58                                      XXXX


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


06/07-10:42:06.634480 0:D0:59:13:a:b -> 8:0:20:A9:a:b type:0x800 len:0x2E

192.168.1.28 -> 192.168.1.26 ICMP TTL:64 TOS:0xC0 ID:1105 IpLen:20 DgmLen:32

Type:8  Code:0  ID:44036   Seq:256  ECHO

58 58 58 58                                      XXXX


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


06/07-10:42:07.634465 0:D0:59:13:a:b -> 8:0:20:A9:a:b type:0x800 len:0x2E

192.168.1.28 -> 192.168.1.26 ICMP TTL:64 TOS:0xC0 ID:1106 IpLen:20 DgmLen:32

Type:8  Code:0  ID:44036   Seq:512  ECHO

58 58 58 58                                      XXXX


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


Non-Active Sitemap

Copyright © 2000-2014 Whitehats.ca
Contact Information 519.221.9132 : Web Contact webmaster@whitehats.ca