Date: Tue, 5 Dec 2000 00:00:38 -0500 (EST) From: pW <packetwhore@stargate.net> To: John Howie <JHowie@msn.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <Pine.BSF.4.21.0012042357520.27812-100000@beastie> In-Reply-To: <00dd01c05e53$39c719e0$fd01a8c0@pacbell.net>
next in thread | previous in thread | raw e-mail | index | archive | help
If I am interpreting this the wrong way, I apologize in advance... You seem awfully eager to point out FreeBSD weaknesses... I notice the msn address and the fact that you got this from an NT security list. Well, while FreeBSD or ANY OS is perfect, FreeBSD seems to be good enough to run Hotmail's web servers and mail servers... something that couldn't be done with NT... hmmm.... just thought I would point that out before you take too much satisfaction from a FreeBSD weakness... pW On Mon, 4 Dec 2000, John Howie wrote: > 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 > 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?Pine.BSF.4.21.0012042357520.27812-100000>