 |
 |
|
|
|
|
|
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.
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:
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
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
C0 A8 01 00 ....
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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.
[1]
Ricketts, Mike “SendIP”, April 26, 2001. URL: http://www.earth.li/projectpurple/progs/sendip.html
(June 2, 2001).
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).
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
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
|
||
|
Copyright
© 2000-2010 Whitehats.ca |
||
