Date: Mon, 4 Dec 2000 16:35:10 -0800 From: "John Howie" <JHowie@msn.com> To: <freebsd-security@FreeBSD.ORG> Subject: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <00dd01c05e53$39c719e0$fd01a8c0@pacbell.net>
next in thread | raw e-mail | index | archive | help
Folks, Take note of how FreeBSD failed... john... ----- Original Message ----- From: "Steve Manzuik" <smanzuik@RAZOR.BINDVIEW.COM> To: <win2ksecadvice@LISTSERV.NTSECURITY.NET> Sent: Monday, December 04, 2000 3:09 PM Subject: NAPTHA Advisory Updated - BindView RAZOR > The NAPTHA DoS vulnerabilities > > Issue Date: November 30, 2000 > Contact: Robert Keyes > > Topic: > > Network DoS vulnerabilities > > Overview: > > A class 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 differen ce > 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. > > - Windows 2000 seems to be invulnerable. > > 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 dependant 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 > > > ------------------------------------------------------------------------ > > 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. These connections look a long > time to time out, at least an hour. > > 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. > > ------------------------------------------- > > Contact: advisory+naptha@razor.bindview.com > > _____________________________________________________________________ > ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice" > ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST" > SEND ALL COMMANDS TO: listserv@listserv.ntsecurity.net > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00dd01c05e53$39c719e0$fd01a8c0>