bindview.naptha.txt

2000-12-22T00:00:00
ID PACKETSTORM:23919
Type packetstorm
Reporter razor.bindview.com
Modified 2000-12-22T00:00:00

Description

                                        
                                            ` 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 workar  
ound available at this time See  
V4.0F See Recommendation  
s Notes  
  
FreeBSD FreeBSD Yes ESTABLISHED No patch or workar  
ound available at this time See  
4.0-REL See Recommendation  
s Notes  
  
Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or workar  
ound available at this time See  
See Recommendation  
s Notes  
  
Microsoft Windows Yes FIN-WAIT-1 Workaround availa  
ble at See  
95,98,98SE http://www.microso  
ft.com/technet/security/bulletin/MS00-091.asp Notes  
  
Microsoft Windows NT Yes FIN-WAIT-1, Patch available a  
t See  
4.0 SP6a ESTABLISHED http://www.microso  
ft.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 workar  
ound available at this time See  
SP1 See Recommendation  
s Notes  
  
SGI IRIX 6.5.7m Yes ESTABLISHED No patch or workar  
ound available at this time See  
See Recommendation  
s Notes  
  
Sun Solaris 7, Yes ESTABLISHED No patch or workar  
ound available at this time See  
8 See Recommendation  
s Notes  
  
Red Hat Red Hat Linux 7 Yes ESTABLISHED No patch or workar  
ound available at this time See  
8 See Recommendation  
s 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  
`