Network Defense:  Trouble in the Stack
by Rik Farrow and Richard Power

In September of 1997, the network staff at a large Univeristy noticed
that network load has suddenly peaked.  Using a network monitor, the
staff discovered that their network has been flooded with ICMP echo
responses (Ping replies).  The replies are heading out of their 
router, to a single host which is also the victim of this attack.

Welcome to the world of denial of service attacks using easily
obtainable tools.  This attack used a program named smurf.c, and could
have been easily blocked by the router at the border between the
university's network and the Internet.  Application gateway firewalls
would have also blocked this attack, as would correctly configured
stateful packet filtering firewalls (although the default behaviour
of many SPF firewalls would be to permit this attack).

The last six months of 1997, and the beginning of 1998, saw many new
attacks based on an intimate knowledge of the TCP/IP protocol.  In
March, a series of automated attacks crashed Windows NT and 95 systems
coast-to-coast, using a variant based on earlier attacks.  These
systems were vulnerable even if they had already been patched.
Attacks like this one require more than packet filtering to stop them.
But many attacks can be prevent by correctly configuring your routers.

Simple Things

Router based defenses can defeat all IP source address spoofing.  The
catch is that every ISP would need to implement this defense using
packet filters.  RFC 2267, posted in January 1998, explains the
rationale for blocking packets with spoofed source addresses 
(http://ds.internic.net/rfc/rfc2267.txt).  This RFC was written in
response to attacks begun in 1996, the SYN Flood attack, in which an
attacker uses software to simulate the opening of a TCP connection.
The source address of the connection in this attack is spoofed, that
is, crafted and not correct, so that acknowlgements to the simulated
opening will never be responded to.  Often, the source addresses are
chosen from a pool of Private Network addresses (RFC 1918), which by
design will not be routed within the Internet.

The authors of the RFC, Paul Ferguson of cisco Systems, Inc. and Daniel 
Senie of BlazeNet, Inc., suggested a solution for Internet Service
Providers (ISPs): block packets with spoofed source addresses.  ISPs
know all of the network addresses for which they advertise routes, and
can use packet filtering so that only packets which include these
network addresses as source addresses can enter the Internet.  While
some spoofing would still be possible (one ISP customer could spoof
another customer's address), this would stop most attacks based on
source address spoofing.  

The weakness of RFC 2267 is that all ISPs must participate for this
to work.  Some of the attacks which RFC 2267 was designed to prevent 
may have come from the ISPs themselves.  SYN Flooding is a denial of
service (DOS) attack designed to make TCP servers, such as Web
servers, unresponsive.  It is easy to imagine one ISP sabotaging
another ISP's Web servers in the hopes of driving away the attacked
ISP's Web customers.  More realistically, most ISPs are not motivated
to attack their competitors, and the technical difficulty, or the
performance penalties encountered when packet filters are used, result
in many ISPs ignoring RFC 2267.

You can prevent packets with spoofed source address from leaving your
own networks by applying a similar packet filter on the interfaces of
routers which connect you to the Internet or other networks.  Although
you might consider it unlikely that your network might be the source
of an attack, your users might try some experiments on their own--ones
which would be very embarassing if traced back to your site.

Smurfing

Other denial of service attacks require the use of source address
spoofing.  The ICMP directed broadcast attack, made popular by the
appearance of the smurf tool in the summer of 1997, affects two
networks.  The attacker, using a spoofed source address in the smurf
tool, sends ICMP echo requests (the same packets used by Ping) to the
directed broadcast address of a victim network.  The directed
broadcast address consists of the network portion of an IP address,
and all ones for the host portion of the address.  For example, for
the network 192.168.22.0, the directed broadcase address would be
192.168.22.255.

By using the directed broadcast address, the attacker's ICMP packets
will be routed across the Internet to the victim's network.  Once in
the target network, most IP stacks will respond to a broadcast address
(255 in this example), by replying.  In the smurf attack, the
computers in the victim network send ICMP echo replies back to the
source--another victim, as the source address used was spoofed.  So
two networks can be attacked simultaneously using this attack.  A small
stream of ICMP packets results in a much larger response (from all
computers responding to the broadcast address), swamping both victims'
networks.

There are no applications which rely on directed broadcast for their
correct functioning.  Implementation of RFC 2267 can stop the packets
with spoofed source addresses--when it is universally applied.  But
you can configure your own routers to block directed broadcasts.  A
packet filter which blocks packets with a destination address
containing all one's in the host portion will stop this attack cold.
Cisco routers now support a configuration option, 
"no ip directed-broadcasts", which will block all directed broadcast 
(or permit only those which match an optional access control list).

Some earlier attacks based on spoofed source addresses relied on
source routing to route reply packets back to the attacked.  Again,
Cisco routers make this easy to block by using the command
"no ip source-route".  Most modern routers will permit you to drop
source routed packets, which are not required by any application, but
are sometimes used by network administrators to test their own
networks.

Fragmentation Attacks

Another attack tool appeared in the summer of 1997.  Teardrop
initially was used to test an implementation problem in Linux TCP/IP
stacks.  TCP/IP stackes handle packets which are too large to transmit across
a network by fragmenting them.  Flags are set in the IP header, and
the fragments are not reassembled until received by the destination
computer's IP stack.  It was noticed that the code which reassembled
fragments on Linux systems did not check to see if a received fragment
had a shorter length than a previously received fragment.  When the
number of bytes to copy to reassemble the packets was calculated, the
result was a negative number--or, since operating systems expect
unsigned numbers, a very large postive number.  The resulting copy
operation overwrote much of memory, typically crashing the system.

Linux users, for the most part, quickly patched their systems.  Users
of Windows NT and Windows 95 with the Winsock 2.0 update were not as
lucky.  Teardrop quickly became a favorite denial of service attack.
The attack used ICMP echo request packets (permitted by many packet
filters and stateful packet filter firewalls), and so was effective
against computers which were supposed to be protected by firewalls.
Firewalls using application gateways based on UNIX systems were not
vulnerable to this attack because these firewalls reassemble packets
before forwarding them (thwarting this class of attacks), and in many
cases, always block ICMP packets of any type.

A more recent version of this attack appeared in March of 1998.
This is the attack mentioned at the opening of this column which
crashed Windows NT and 95 systems at the Massachusetts Institute
of Technology, Northwestern University, the University of Minnesota
and University of California campuses in Berkeley, Irvine, Los
Angeles and San Diego.  Unclassified Navy computers connected to
the Internet also crashed on Point Loma and in Charleston, South
Carolina, Norfolk, Virginia, and elsewhere.

This attack used UDP packets instead of ICMP packets, and instead of
using a fragment size resulting in a negative number, simply used a
very small fragment size.  The attack tool, bonk.c, showed up on
security mailing lists within days of the first reported attack.
In this case, routers, and packet filtering firewalls, could have been
of help in preventing this attack.  However, many of the attacks used
port 53, the same port used by the Domain Name Service, and easily
slipped through stateful packet filters with default configuration and
many other packet filtering firewalls as well.  Application gateways
firewalls based on UNIX systems easily blocked this attack.

Land

The Teardrop attack affected versions of Linux before 2.0.32
(Caldera Linux) and Microsoft NT and patched Windows 95 systems.
A CERT Advisory, CA-97.28.Teardrop_Land, includes a list of affected
vendors and contact information.  This advisory also described the
Land attack, which affected many UNIX systems, as well as Windows NT
and 95 systems.

The Land attack uses spoofed source addresses, and so would be blocked
with total compliance with RFC 2267.  The trick to this attack is to 
simulate a TCP connection, but use the victim's own IP address as the
source address.  The victim computer than attempts to contact itself
in order to respond to the simulated connection, and this may result in the
system crashing.  Unlike the Teardrop attack, the Land attack affected
many versions of UNIX, and also the IP stacks of some routers and switches.

Denial of service attacks makes networks unusable, and/or crash
computers.  They do not permit the attacker to breakin and gain 
access to a command prompt or to read or write files.  Still, as
computers and networks have become an essential part of businesses and
the economy, their financial impact is difficult to calculate yet
significant.

One question that often arises is why do these problems appear in the
TCP/IP protocol, which has been in use for over twenty years?  Why
weren't these problems discovered earlier?  The answer lies partially
in the complexity of software, and also in the existence of new
implementations of TCP/IP stacks.

DOS attacks such as the SYN Flood or Land were not anticipated by the
designers of TCP/IP and the programmers who wrote TCP/IP stacks.  In
the SYN Flood attack, a packet is sent which uses a non-routable
source address, something which makes no sense at all when you are
designing a connection-oriented protocol.  The assumption likely made
by the programmers is that if a packet requesting a connection has
been received, and yet there is no route back to the source, the
condition must be temporary, and the solution is to keep trying until
either the retry count is reached or the route becomes established.
In the attack, there never will be a route, and the connection queue
becomes full with the attacker's packets, blocking legitimate connection
requests.

The Teardrop attack represents flaws in newer, less tested, TCP/IP
stacks.  Most UNIX vendors use TCP/IP stacks which all had a single
source:  a port of TCP/IP to the Berkeley UNIX system supported by
the Department of Defence's Advanced Project Agency (DARPA) back in
1982.  These TCP/IP stacks have shared the same periods of trials and
testing during the eighties, giving them an equal chance to be
debugged.  These versions have since diverged of course.  In the Land
attack, SUN's Solaris operating systems were not vulnerable but its
older SunOS, as well as HP/UX versions 9-11 (unpatched) were
vulnerable.  

For vendors with newer TCP/IP stacks, such as Microsoft, or the Linux
community, their implementations are receiving a trial by fire which
is uncovering flaws.  Linux systems and Windows NT/95 computers are 
usually attached to networks, and many of these networks are not adequately
protected by firewalls (or perhaps, not protected at all).  So it is
possible for a single, new attack to affect thousands of computers
around the world.  Homogeneity will make attacks like these more
common.  The Internet Worm in November of 1987 took advantage of bugs
found mainly on Sun systems, but differed in that the Worm actually
uploaded and executed itself on each affected machine.  Denial of
service attacks do not involve the execution of code remotely
introduced, but flaws in the victim which cause it to become
unresponsive.

Application gateway firewalls were also notably more successful in
blocking these attacks than routers or stateful packet filtering
firewalls.  Routers and various packet filtering firewalls do not
reassemble fragmented packets, but only check to see if the filter
rules, checking information in the first fragment, permit this packet
to pass through the firewall.  Application gateway firewalls completely
reassemble packets before they even reach the firewall engine where
they will be tested against a rulebase.  Application gateway firewalls
also intercept ICMP packets, generally making the network behind the
firewall invisible to ICMP packets from external networks.  Many ICMP
packets are useful and important to the correct functioning of TCP/IP,
and application gateway firewalls handle the interpretation of these
packets and respond appropriately--but without copying these packets
to internal computers.  So they do better against both fragmentation
based attacks and attacks involving ICMP.

The correct configuration of your routers should not be ignored.
Routers form the first line of defense (and sometimes the only line of
defense) between your network and a hostile Internet.  Not only should
you defend your network against attacks, but defend the Internet (and
other networks) from attacks from your own network by apply the
concepts in RFC 2267 to your own border routers.  In a column later
this year, we'll talk more about protecting your networks with
routers.

Resources:

CERT Advisories:
http://www.cert.org
ftp://ftp.cert.org/pub/cert_advisories/CA-97.28.Teardrop_Land

RFC 2267 (note that this server may be moved this Spring):
http://ds.internic.net/rfc/rfc2267.txt

Information about patches for the Teardrop attack on Windows NT/95:
ftp://ftp.microsoft.com/bussys/winnt/kb/Q154/1/74.TXT

Patch information for the Land attack on Windows NT 4.0:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/
hotfixes-postSP3/land-fix/Q165005.txt

Patch information for the Land attack on Windws 95:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/
hotfixes-postSP3/land-fix/Q177539.TXT