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 (https://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 (https://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
            https://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 (https://cve.mitre.org),
       which standardizes names for security problems.

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

       CERT Advisory:

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

       Microsoft's security bulletin:

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

       Microsoft Security Patch:

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

       RFC 2267:

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

       "Distributed Denial of Service Defense Tactics" security paper

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

       "Strategies for Defeating Distributed Attacks" security paper

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

       Snort:

       https://www.snort.org

       Dan Bernstein's tcpserver:

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

       Simson Garfinkel on Process-Table Attack

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

       Stanislav Shulanov's Netkill

       https://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                                https://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   https://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