|
|
|
|
| |
| 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. |
| |
Credit:
The information has been provided by Bob Keyes of BindView.
|
| |
Vulnerable systems:
Compaq - Tru64 UNIX V4.0F (ESTABLISHED)
FreeBSD - FreeBSD 4.0-REL (ESTABLISHED)
General Linux - Linux 2.0 kernel-based systems (ESTABLISHED)
Hewlett-Packard - HP-UX 11.00 (ESTABLISHED)
Microsoft - Windows 95,98,98SE (FINWAIT_1)
Microsoft - Windows NT 4.0 SP6a (ESTABLISHED & FINWAIT_1)
Novell - Netware 5 SP1 (ESTABLISHED)
Red Hat - Red Hat Linux 6.1 Kernel 2.2.12 (ESTABLISHED)
SGI - IRIX 6.5.7m (ESTABLISHED)
Slackware - Slackware Linux 4.0 (ESTABLISHED)
Sun - Solaris 7, 8 (ESTABLISHED)
Immune systems:
IBM - AIX 4.3
Microsoft - Windows 2000
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 exploited 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 indicates 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 went to its maximum of 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 immune to this kind of attack.
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 keep-alives, these can be adjusted to potentially allow for quicker recovery (assuming that the NAPTHA attack did not crash the system). For example, the TCP keep-alive 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 keep-alive time is adjusted from 2 hours to 30 seconds, and the number of keep-alive 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";)
7. Vulnerable Windows 95/98/ME/NT systems should read the following advisory:
Incomplete TCP/IP Packet vulnerability (Patch available)
|
|
|
|
|
|
|
|
|
|
