Welcome to Michael & Jean's
New Humble Abode

Smurfing

Overview

This article provides provides in-depth information for Cisco routers in the prevention of Smurf attacks. Some information is general and not related to an organization's particular vendor of choice; however, it is written with a strict Cisco router focus. No confirmation has been made to the effects on other vendors' equipment. The only testing that has been performed was on Cisco equuipment. There are attempts to collect information from other colleagues who are willing to put other vendors' boxes through tests and/or provide information on logging packets or minimizing the effects.

Description

The "smurf" attack, named after its exploit program, is the most recent in the category of network-level attacks against hosts. A perpetrator sends a large amount of ICMP echo (ping) traffic at broadcast addresses, all having spoofed source addresses of a victim. If the routing device delivering traffic to those broadcast addresses performs the IP broadcast to layer 2 broadcast function noted below, most hosts on that IP network will take the ICMP echo request and reply to each with an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet.

Currently, the providers/machines most commonly hit are IRC servers and their providers.

There are two parties who are hurt by this attack... the intermediary (broadcast) devices--called "helpers", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the helpers generate.

Let's look at the scenario to paint a picture of the dangerous nature of this attack. Assume there is a co-location switched network with 100 hosts and an attacker using a T1. The attacker sends a 768kb/s stream of ICMP echo (ping) packets, with a spoofed source address of the victim, to the broadcast address of the "helper". These ping packets hit the helper's broadcast network of 100 hosts; each of them takes the packet and responds to it, creating 100 ping replies outbound. If the bandwidth is multiplied, 76.8 Mbps is used outbound from the "helper" after the traffic is multiplied. This is then sent to the victim (the spoofed source of the originating packets).

Keep From Being the Source That Perpetrators Use to Attack

The perpetrators of these attacks rely on the ability to source spoofed packets to the "helpers" in order to generate the traffic which causes the denial of service. In order to stop this, all networks should perform filtering either at the edge of the network where customers connect (access layer) or at the edge of the network with connections upstream.

Paul Ferguson of cisco Systems and Daniel Senie of OpenROUTE Networks have written an Internet-draft pertaining to this topic.

Stop Being an Intermediary

This attack relies on the router serving a large multi-access broadcast network to frame an IP broadcast address (such as 10.255.255.255) into a layer 2 broadcast frame (for ethernet, FF:FF:FF:FF:FF:FF). The RFC for routing states that a router MAY perform this translation for directed broadcasts. Because in a few select cases it is desirable most vendors have chosen to implement this behavior. Generally this behavior should not be needed.

Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing.

Because most host IP stacks pay little attention to the IP header of an ICMP packet, or (if they check the IP header for ICMP) implement responses to ICMP broadcasts, the packet is handed to the ICMP layer, where in the case of smurf attacks, an ICMP echo reply is prepared and shipped out to the spoofed address source of the packet--the victim.

To stop Cisco routers from converting these layer 3 broadcasts into layer 2 broadcasts, use the "no ip directed-broadcast" interface configuration command. This should be configured on all routers which provide routing to large multi-access broadcast networks (generally LANs), with more than 5-10 devices. It is unnecessary on point-to-point interfaces, such as POS, serial T1, HSSI, etc. No testing has been done on multipoint frame-relay; however, since it is a multi-access network, it should behave just like a LAN. Point-to-point sub-interface models will behave like many point-to-point links--again, this command really isn't needed there.

There is one case study where this will stop intended behaviour: In the case where samba (an SMB server for UNIX) or Windows NT is used to "remote broadcast" into a LAN workgroup so that the workstations on that LAN can see the server, the LAN machines will be prevented from seeing the remote server. This is *only* in the case where there is no WINS server (WINS is routed unicast) and a "remote broadcast" is being used--it's a rare but notable condition.

How to Suppress Attacks

The amount of bandwidth and packets per second (pps) that can be generated by this attack is quite large. With a 200-host LAN, it was possible to generate over 80 Mbits/sec traffic at around 35 Kpps toward the target--a pretty significant amount. The victims receive this because traffic is multiplied by the number of hosts on the broadcast network used (in this case, with a 200-host network, it was only required to send 400 Kbits/sec to the broadcast address--less than one-third the capacity of a T1).

Many hosts cannot process this many packets per second; many hosts are connected to 10 Mbit/sec ethernet LANs where more traffic than wire speed is sent. Therefore, the ability to drop these packets at the network border, or even before it flows down the ingress pipes, is desired.

Cisco routers have several "paths" which packets can take to be routed; each has a varying degree of overhead. The slowest of these is "process" switching. This is used when a complex task is required for processing packets. The other modes are variations of a fast path--each of them with a set of advantages and disadvantages. However, they are all handled at interrupt level (no process-level time is required to push these packets).

In IOS versions (even the most recent), access-list denies are handled at the process (slow) level, because they require an ICMP unreachable to be generated to the originating host. All packets were sent to the process level automatically to be handled this way.

Under a recent code change, packets denied by an access-list will be dropped at the interrupt (fast) level, with the exception of 2 packets per second per access-list deny line. These 2 packets per second will be used to send the unreachables. This assumes that the user does not want to log the access-list violations (via the "log" or "log-input" keywords). The ability to rate-limit "log-input" access-list lines is coming in the near future.

Filtering ICMP echo reply packets destined for high-profile machines at the ingress interfaces of the network border routers will then permit the packets to be dropped at the earliest possible point. However, it does not mean that the network access pipes won't fill, as the packets will still come down the pipe to be dropped at the router. It will, however, take the load off the system being attacked. Keep in mind that this also denies others from being able to ping from that machine (the replies will never reach the machine).

This may give customers of providers who use Cisco leverage with the providers' security teams to help save their pipes by filtering before the traffic is sent.

Tracing Spoofed Packet Streams

Tracking these attacks can prove to be difficult, but it is possible with coordination and cooperation from providers. This section only speaks about the abilities of Cisco routers to log/filter packets.

Today, logging packets which pass through or get dropped in an ACL is possible; however, all packets with the "log" or "log-input" ACL options are sent to process level for logging. For a large stream of packets, this could cause excessive CPU problems. For this reason, tracking attacks via IOS logging today is limited to lower bandwidth attacks (smaller than 10k packets per second). Even then, the number of log messages generated by the router could overload a syslog server.

A Cisco bug ID addresses this problem. It has not yet been integrated into IOS releases, however. When it is, it will be possible to log packets at defined intervals and to process logged packets not at that interval in the fast path.

Disclaimer:This information is presented as an interested party only. The information contained herein has not been officially verified by any member of engineering at Cisco Systems, nor do we speak on behalf of Cisco Systems. All research for this paper is being done purely as a matter of self-interest and a desire to help others minimize effects of this attack.

WINDOWS SSPING

Overview

SSPING is a program that can freeze any computer connected to the Internet or on a network running Windows 95, Windows NT, and older versions of the MacOS that are not behind a firewall that blocks ICMP (Internet Control Message Protocol) data packets.

How does it work?

The SSPING program sends the victim's computer a series of highly fragmented, oversized ICMP data packets over the connection. The computer receiving the data packets locks when it tries to put the fragments together. Usually, the attacker only needs to send a few packets, locking the victim's computer instantaneously. When the victim restarts his or her computer, the connection with the attacker is lost and the attacker remains anonymous.

Where can I download a fix?

Patches can be downloaded from Microsoft

Note: We have been informed by Kevin M. Smith that the Microsoft SSPING Patch disables the WinNuke patch. We recommend reinstalling the WinNuke patch over the SSPING patch to ensure that you are not inadvertently nuked because of it.

Windows OOB Bug (WinNuke)

Overview

What? A Bug In Windows?
By using a special program, malicious people can crash any Windows 3.11/95/NT machine without a fix that is on the internet. It is done by sending OOB [Out Of Band] data to an established connection with a Windows user. NetBIOS [139] seems to be the most effective since this is a part of Windows, but any port that listens for data can be attacked, like Identd [113]. Apparently Windows doesn't know how to handle OOB, so it panics and crazy things happen. Reports have been heard of everything from Windows dropping carrier to the entire screen turning white. Windows also sometimes has trouble handling anything on a network at all after an attack like this. A reboot usually fixes whatever damage this causes.

Courtesy of BugTraq

How do I fix this?

There has been a HotFix released by Microsoft to patch this bug by updating Tcpip.sys to correct the problem. Instructions for installing it are available from the following Internet locations:

• Windows NT 4.0
• Windows 3.11:
  Thanks to Tjerk Vonck and EJ for this information:
  
  • Find SYSTEM.INI on the boot drive of your computer
  • Directly under the caption [MSTCP] in SYSTEM.INI insert the following line:
  •  BSDUrgent=0
• This is essentially the same thing as the Windows 95 bugfix, and it works well.

How do I test to see if I am vulnerable to this bug?

Check out the Yikes! Nuke Checker page, that will let you check to see if your machine can be attacked.
Please note: If anything happens to your machine as a result of this test, neither Michael L Griffin Network nor Yikes! can be held reponsible.)

How can I tell who is trying to attack me?

Download one of these Port Listeners:

• Skream's Port Listener (140 KB)
• Port Listener Homepage
• Dr. Bardo's Port Sniffer (97 KB)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -