Bugtraq mailing list archives

updated Bindview NAPTHA advisory

From: Bob Keyes <bkeyes () MAIL BOS BINDVIEW COM>
Date: Mon, 18 Dec 2000 17:24:32 -0500

The NAPTHA DoS vulnerabilities

Issue Date: 30 November 2000
Updated: 18 December 2000
Contact: Robert Keyes

Topic:

Network DoS vulnerabilities

Overview:

A set of network DoS vulnerabilities has been discovered, and the name
NAPTHA is being used to describe them as a group. The NAPTHA
vulnerabilities are weaknesses in the way that TCP/IP stacks and network
applications handle the state of a TCP connection.

Affected Systems:

The Naptha DoS vulnerabilities "Tested Products"

Impact:

By creating a suitably large number of TCP connections and leaving them in
certain states, individual applications or the operating system itself can
be starved of resources to the point of failure. In the past, attacks that
would exploit TCP connections in this manner have not been implemented
because they would typically exhaust the resources of the attacker as
well. The innovation provided by the Naptha attack is that it is possible
to easily create a DoS on the target with little resource consumption on
the part of the attacker.

Background:

DoS
A denial of service attack is a purposeful action to significantly degrade
the quality and/or availability of services a system offers.

DoS->RS
Resource Starvation is a type of denial of service attack. Here is where
we need to define the difference between an attack and a notable
vulnerability. With sufficient network resources available to the
attacker, any system is vulnerable to DoS->RS.

What makes a method of DoS->RS notable is that it consumes far more
resources of the victim than resources of the attacker. A great difference
in resource levels indicate a vulnerability in the victim's system. The
software designed to expose this vulnerability can be called a DoS->RS
exploit.

DoS->RS->TCP_STATE
The kernel keeps a record for every TCP connection. A large number of
connections, regardless of activity, require more memory and CPU time. It
is theoretically possible for a user on a machine with a large amount of
RAM, a fast processor, and a well-tuned operating system to overwhelm a
lesser system solely by using such standard programs as TELNET, however
the amount of resources consumed on the attacking system is large enough
so that this is not considered a serious vulnerability.

An attack program utilizing a network API such as Berkeley Sockets is more
efficient and therefore more dangerous, but is not usually efficient
enough expose a dangerous vulnerability on the victim's system.

Details:

Naptha is a demonstration of an efficient DoS->RS->TCP_STATE exploit. It
is efficient because it does not use a traditional network API to set up a
TCP connection. Unlike a real TCP/IP stack, it does not keep any record of
connection state. It responds to a packet sent to it based on the flags in
that packet alone. When operated in a manner that will produce many
hundreds or thousands of connection records on the victim, it consumes
very little of the attacker's resources in comparison to the resources it
uses up on the victim's system. In this way, it can expose vulnerabilities
of a particular service, or the TCP/IP stack itself, on the victim's
system.

Below are a few examples of the many possible Naptha weaknesses:

- Novell's Netware 5.0 with sp1 installed locked up after 3000
open connections on port 524. All 64MB of the system's RAM
became utilized and the CPU utilization as well maxed out at
100%. The server still had not timed out connections and
recovered memory after 12 hours being left idle.

- FreeBSD 4.0-REL became unusable after 495 connections to the
ssh port. Each connection started an instance of the daemon
which quickly exhausted available file handles; the system
reports "too many open files in system". After approximately 30
minutes the connections start timing out and the system becomes
usable again.

- We have had reports of Windows 2000 be vulnerable, but haven't
been able to reproduce those results. Research continues.

See the complete list of tested products at the end of this document.

The Workings of Naptha
----------------------

The objective of this section is to describe the basic structure of
the Naptha attack so that researchers can verify our claim that such an
attack is possible and should be considered with all due seriousness.

While there has been some previous work in this area, no one has
published or demonstrated a tool that can leave connections in any of
the various TCP states on the victim machine (ESTABLISHED and FIN-WAIT-1,
etc.) or that has a multi-component architecture (allowing one to hide
part of the attack on different hosts).

Naptha gains much of its effectiveness through the fact that the attack
can be made in a distributed manner.

The first part sends out a sequence of SYN packets from all possible
ports of a forged IP address to the victim. Depending on the requirements of
the individual attack scenario, multiple copies of this program on the
same host could be used to attack different hosts, or multiple hosts could
attack a single victim. This sounds like a SYN flood, but there's more to it.

The second half runs on a LAN where the forged IP address would be, if it
were a real host. The program first makes sure that the router has an entry
for this phantom host in its ARP table. Next, it listens in promiscuous
mode for a packet from the victim to the phantom host. The program responds
with a packet with the appropriate flags and sequence numbers. Typically,
it listens for SYN/ACK packets and sends ACK. It could also set the FIN
flag and leave the connection in FIN-WAIT-1. To keep connections alive
longer, it can listen for 'regular' data packets or 'keep alive' packets
and send ACK in reply. Multiple victims could be targeted by a single
instance of this program.

This 'phantom' nature makes it hard to track down and eliminate.

In order to be successfully asymmetrical in its consumption of
resources, such an attack program must not set up any TCBs (Transmission
Control Blocks) in the kernel of the attacking machine. This helps to
ensure that the attacker's activities will not be directly constrained
by the client-side kernel limitations. It is also important that the
number of processes needed on the client side not grow with the number of TCP
connections. Naptha does this by completely avoiding use of the OS's
TCP/IP stack, and instead crafts its own raw packets. In fact, in a high
rate Naptha attack, the network's bandwidth would typically be the
constraint rather than the attacking host's resources.

Naptha also has connection rate limiting capabilities. In one variation of
the attack, connections are established at a high rate and the victim is
left with thousands of ports open, and all resources are consumed before
the connections time out. In another scenario, connections are
established at a slow rate to avoid SYN flood protections.

The number of connections and the rate of establishment necessary to
create a DoS is dependent on a number of factors. Different operating
systems have different thresholds of connection numbers, file numbers,
process memory, etc. The application running on that port may also have
its own levels of resource control. Some applications spawn a new process
for each connection. The speed of the CPU and amount of memory in a system
also affects its resistance to a Naptha attack. Lastly, the network
itself plays its part.

In conclusion, the Naptha attack shows how serious a resource starvation
attack can be. There is no single, clear, obvious fix for this problem
but a number of promising ideas.

Recommendations:

Unfortunately, most vendors are vulnerable to Naptha attacks, and until
some vendor patches come out, there is very little that can be done
outside of normal security practices. We do have a few recommendations:

1. Limit the amount of services running on any system you
suspect that might become victim to a Naptha attack, especially
public systems.

2. Limit access as to who can connect to exposed TCP ports on a
system via firewalling techniques. On public systems this may be
impractical, but it should be limited just the same if possible.

3. Ensure that all border equipment, such as routers and
firewalls, is properly configured and you are doing both ingress
and egress filtering. (See RFC 2267)

4. On Unix systems, use inetd or possibly Dan Bernstein's
tcpserver (http://cr.yp.to/ucspi-tcp.html) to limit spawned
daemon processes. While this will not prevent that particular
daemon's resources from being over utilized, it is possible to
prevent daemons from crashing the server. This may allow the
server to recover.

5. On systems that have adjustments for various TCP timeouts and
keepalives, these can be adjusted to potentially allow for
quicker recovery (assuming that the Naptha attack did not crash
the system). For example, the TCP keepalive settings on Linux
2.2 kernels might help recovery time:

# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
# cat /proc/sys/net/ipv4/tcp_max_ka_probes
5
# echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes
# echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes

In the above example the keepalive time is adjusted from 2 hours
to 30 seconds, and the number of keepalive probes is adjusted
from 9 to 2. It also adjusts the maximum number of probes sent
out to be 100 instead of just 5. These are suggested values --
real world adjusts will almost certainly be required.

6. The programs written to demonstrate the attack have been
released only to the security contacts at OS vendors, through
CERT. The code will not be released to the public. However, the
information below will serve as a 'fingerprint' for IDS to
detect the demonstration code. Please note that the code itself
could be easily modified to change the fingerprint, so this is
NOT a failsafe method of detecting a Naptha attack.

IP:
TOS = Low Delay
ID = 413
TCP:
FLAGS = SYN
SEQ ID = 6060842
WINDOW = 512

Snort (http://www.snort.org) is a free lightweight IDS. Here's a
Snort filter for Naptha:

alert tcp any any <> any any (flags:S; seq: 6060842;
id: 413; msg: "Naptha DoS Attack, see
http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";;)

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

References:

CVE:

The Common Vulnerabilities and Exposures (CVE) project has
assigned the name CAN-2000-1039 to this issue. This is a
candidate for inclusion in the CVE list (http://cve.mitre.org),
which standardizes names for security problems.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1039

CERT Advisory:

http://www.cert.org/advisories/CA-2000-21.html

Microsoft's security bulletin:

http://www.microsoft.com/technet/security/bulletin/MS00-091.asp

Microsoft Security Patch:

NT4:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114

RFC 2267:

http://www.faqs.org/rfcs/rfc2267.html

"Distributed Denial of Service Defense Tactics" security paper

Author: Simple Nomad
http://razor.bindview.com/publish/papers/DDSA_Defense.html

"Strategies for Defeating Distributed Attacks" security paper

Author: Simple Nomad
http://razor.bindview.com/publish/papers/strategies.html

Snort:

http://www.snort.org

Dan Bernstein's tcpserver:

http://cr.yp.to/ucspi-tcp.html

Simson Garfinkel on Process-Table Attack

http://www.securityfocus.com/archive/1/12636

Stanislav Shulanov's Netkill

http://www.securityfocus.com/archive/1/56462

Contact: advisory+naptha () razor bindview com

Acknowledgements: Mark Loveless and the rest of the RAZOR team.

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

The Naptha DoS vulnerabilities
"Tested Products"

Note: The RAZOR team has examined
two TCP states out of many. These
states are the FIN-WAIT-1 state and
the ESTABLISHED state. More research
in this area is underway. We expect
to find a majority of operating
systems affected to some extent.

Vendor Product Vulnerable? TCP state Patch/Workaround Available?
Notes

Compaq Tru64 UNIX Yes ESTABLISHED No patch or workaround available at this time
See
V4.0F See Recommendations
Notes

FreeBSD FreeBSD Yes ESTABLISHED No patch or workaround available at this time
See
4.0-REL See Recommendations
Notes

Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or workaround available at this time
See
See Recommendations
Notes

Microsoft Windows Yes FIN-WAIT-1 Workaround available at
See
95,98,98SE
http://www.microsoft.com/technet/security/bulletin/MS00-091.asp Notes

Microsoft Windows NT Yes FIN-WAIT-1, Patch available at
See
4.0 SP6a ESTABLISHED
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 Notes

Microsoft Windows No N/A N/A
N/A
2000

Novell Netware 5 Yes ESTABLISHED No patch or workaround available at this time
See
SP1 See Recommendations
Notes

SGI IRIX 6.5.7m Yes ESTABLISHED No patch or workaround available at this time
See
See Recommendations
Notes

Sun Solaris 7, Yes ESTABLISHED No patch or workaround available at this time
See
8 See Recommendations
Notes

Red Hat Red Hat Linux 7 Yes ESTABLISHED No patch or workaround available at this time
See
8 See Recommendations
Notes

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

Notes:

Compaq - Tru64 UNIX V4.0F

Two services were tested, portmapper (tcp
port 111) and finger (tcp port 79). These
services were chosen because finger runs
from inetd and portmapper runs without it.

The Tru64 UNIX kernel appears to be
somewhat robust against Naptha attacks.
Sending twenty thousand packets to tcp
port 111 caused no obvious performance
degradation on the Tru64 UNIX host
(except that other attempts to query the
portmapper became unsuccessful). The
netstat command showed a steady-state
value of 4100 ESTABLISHED connections.

Sending a few hundred packets to tcp port
79, however, resulted in creation of too
many finger daemon processes for the
system to continue normal operation.
Trying to start a new process from a login
shell resulted in the error "No more
processes". It is possible that the finger
daemon attack would have been less
effective with a different inetd
configuration, or with different kernel
parameters. We did not investigate this.

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

FreeBSD - FreeBSD 4.0-REL

In testing FreeBSD, a few specific
daemons/ports were targeted. For some, the
stability of the system as a whole can be
affected. The daemons targeted in this
testing are not necessarily at fault for
the problems encountered.

SSH:
Became unusable after 495 connections to
the ssh port. Each connection started an
instance of the daemon which quickly
exhausted available file handles; the
system reports "too many open files in
system". After approximately 30 minutes
the connections start timing out and the
system becomes usable again.

NFS:
Stopped functioning after 964 packets to
the NFS port. While the rest of the system
did not seem affected, the connections did
not time out.

BIND:
Took 961 TCP connections before the kernel
reported "file table is full", and TCP
services failed. UDP DNS seemed
unaffected. The system recovered two hours
after the attack stopped.

Note: These services/ports can be
similarly affected on other Linux and UNIX
variants.

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

Hewlett-Packard - HP-UX 11.00

Two services were tested, portmapper and
telnet. These services were chosen because
telnet runs from inetd and portmapper runs
without it.

TELNET:
HP-UX appears to have some protection. It
stops responding to Naptha packets after
several hundred from the same IP address.
However, until that time it is possible to
make telnetd respond with; "Telnet device
drivers missing: No such device". This
does recover fairly quickly, however.

PORTMAPPER:
After several hundred Naptha TCP sessions,
a telnet session to port 111 will
immediately be disconnected. This broken
state lingers for much longer than the
telnet problem.

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

Microsoft - Windows 95,98,98SE

Leaving a large number of connections in
FIN-WAIT-1 causes the NetBIOS and WWW
services on Microsoft Windows 95, 98, and
98SE to fail and not restart.

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

Microsoft - Windows NT 4.0 SP6a

Exploiting ESTALISHED states on port 139
(netbios-ssn), caused the service to die
after 1010 packets. Port 135 (loc-srv)
died after 7929 packets. Interestingly, if
port 139 had been previously killed by
Naptha, port 135 died after two packets.
If the Naptha attack was paused, port 135
would recover but be immediately
unavailable if the Naptha attack was
resumed. When port 135 died, the CPU
utilization would eventually jump to 100%
and remain there until a reboot.

Leaving a large number of connections in
FIN-WAIT-1 causes the NetBIOS and WWW
services on Microsoft Windows NT 4.0 to
fail and not restart.

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

Novell - Netware 5 SP1

Locked up after 3000 open connections on
port 524, utilized all 64MB of the
system's RAM, and CPU utilization became
100%. The server still had not timed out
connections and recovered memory after 12
hours being left idle.

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

SGI - IRIX 6.5.7m

Two services were tested, portmapper (tcp
port 111) and sgi-dgl (tcp port 5232).
These services were chosen because sgi-dgl
runs from inetd and portmapper runs
without it.

The IRIX kernel appears to be somewhat
robust against Naptha attacks. Sending
twenty thousand packets to tcp port 111
caused no obvious performance degradation
on the IRIX host (except that other
attempts to query the portmapper became
unsuccessful). The netstat command showed
a steady-state value of 195 ESTABLISHED
connections.

Sending a few hundred packets to tcp port
5232, however, resulted in creation of too
many dgl daemon processes for the system
to continue normal operation. Trying to
start a new process from a login shell
resulted in the error "No more processes".
It is possible that the dgl daemon attack
would have been less effective with a
different inetd configuration, or with
different kernel parameters. We did not
investigate this.

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

Sun - Solaris 7, 8

Two services were tested, portmapper and
telnet. These services were chosen because
telnet runs from inetd and portmapper runs
without it.

TELNET:
At around 700 Naptha TCP sessions, a
telnet session will be connected but then
gets the message "can't grant slave pty"
and is disconnected. At 1700 Naptha TCP
sessions, a telnet session will be
connected but nothing else happens. This
is not confined to the telnet port, it
effects every port. If the Naptha attack
is stopped, eventually telnet will
recover. How long it is broken is
dependant on the speed and length of the
Naptha assault and other factors. A
typical downtime was an hour.

PORTMAPPER:
At around 300 Naptha TCP sessions, a
telnet session to port 111 is immediately
disconnected (normally, this is
disconnected when a user hit the enter
key). This fault does not effect other
services. Downtime variable but typically
two hours.

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

Red Hat Linux 7.0

The use of xinetd in this version of Red Hat
does help minimize the affects of a Naptha
attack. However, not all services are run
from xinetd. Only 330 Naptha sessions to
sendmail were neccessary to cause memory
exhaustion of a 128MB system. The VM would
start killing processes, but often not the
correct (sendmail) ones. Eventually VM would
destroy enough bogus sendmail processes to
get enough free memory, but had often killed
a lot of other, legitimate and crucial
processes. Continuing the naptha attack,
even at a low rate (even 1 connection per
second) keeps the system unusable.

Work-around: run as many services as is
practical from xinetd.

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

Contact: advisory+naptha () razor bindview com

Current thread:

updated Bindview NAPTHA advisory Bob Keyes (Dec 19)
- Re: updated Bindview NAPTHA advisory Alfred Perlstein (Dec 20)
  - Re: updated Bindview NAPTHA advisory Bob Keyes (Dec 20)
- Re: updated Bindview NAPTHA advisory Michal Zalewski (Dec 20)
- Re: updated Bindview NAPTHA advisory stanislav shalunov (Dec 20)