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