|
|
trends in computer attacks
by Elias Levy Elias Levy is the moderator of BugTraq, a full disclosure security mailing list, and webmaster of <underground.org>. He also consults and speaks on issues of UNIX and network security.
Over the last few years, we have seen a number of different types of attack become well known. This has become particularly evident because the Internet has recently suffered a number of large-scale attacks, involving thousands of computers, using these techniques. Here are descriptions of some of these attacks with some simple ways to harden your hosts and networks against them. I am assuming you already have taken some minimal security precautions, such as installing the latest patches. IP Spoofing When the IP protocol was first designed, the Internet was a much friendlier place. Authentication of IP packets was not a feature to be added until the development of IPSec [1] [2] [3]. Even so, it will take many years for IPSec to be deployed and widely used. This has brought us to our current chaotic state of affairs. IP spoofing is the act of injecting into an IP network packets with a source address other than that assigned to the sending host. This "spoofed" address can be unassigned or belong to another host. IP spoofing is generally the building block used by other network attacks. It allows the attacker to impersonate another host and/or hide his origin. This has made tracking the source of many network attacks a very painful process reminiscent of the way the telephone companies used to track the source of a telephone call by tracing the wires in switches one central office at a time this was a very slow and error-prone process. Unfortunately, there is no silver bullet to stop IP spoofing. The best we can do is protect ourselves against attacks that attempt to spoof our own addresses and stop our network from being the source of such attacks. Preventing Reception of Spoofed Packets In a common attack involving IP spoofing and predictable TCP sequence numbers, an attacker masquerades as a trusted local host with an IP address in our network to obtain access to some other host in our network. We can stop such attacks at our border routers by configuring them to drop any packets coming into our network with a source address belonging to our network. We can also stop packets with known "bad" addresses from coming into our network [4]. Bad addresses are 0.0.0.0 (all zeros broadcast), 255.255.255.255 (all ones broadcast), 127.0.0.0/8 (loopback), 10.0.0.0/8 (reserved), 172.16.0.0/12 (reserved), and 192.168.0.0/16 (reserved). Preventing Transmission of Spoofed Packets To stop our network from becoming the source of such attacks, we must configure our border routers to drop any packets exiting our network with a source address not belonging to our network. If all networks attached to the Internet applied such filtering rules to their routers, we would see an incredible decrease in the number of network attacks, and tracking them would be much easier. Filtering is not more widespread because it imposes a performance penalty on the router that is unacceptable to some network operators. This should be weighed against the bad publicity you will generate and possible legal actions that may come about if your network is found to be the source of an attack. Internet access providers who route traffic for other networks must take them into account when configuring the input and output filters in their routers. For more information on IP filtering to stop IP spoofing, see [5]. IP spoofing filters may interfere with Mobile IP protocols [6]. Work is currently under way within the IETF to rectify this problem. Source Routing Source routing is a little-used feature of the IP protocol that allows the sender of an IP packet to determine the route the packet will travel through the network. When attackers spoof IP packets they do not see the response packets from the target unless the attackers are attached to the same broadcast network as the host they are spoofing, or they are located somewhere along the route the packets travel back to the spoofed host. Source routing allows attackers to route the response packets through a segment to which the attackers are attached. They can then see the response to their spoofed packets and obtain information such as TCP sequence numbers. If you are using some type of network analysis tool, such as tcpdump or Network Flight Recorder [7], the source route information can be used to trace the source of an attack, because the attacker must be attached to one of the networks in the path of the route of each packet. No widely used applications or protocols deployed in the Internet today use source routing. It is recommended that you disable this feature in all your routers and hosts. SYN Flooding SYN flooding is a network attack that exhausts the resources of the target machine by sending it a large number of spoofed TCP connection requests. These requests tie and consume memory and data structures in the target machine and may cause legitimate connection requests to be denied. This type of attack became popular after two hacker publications published articles, together with source code, to demonstrate the problem [8]. A large-scale attack against the Internet access provider PANIX and others soon ensued [9]. A number of different solutions have been offered, and as many have been implemented. They include SYN cookies, RST cookies, random early drop, increasing the backlog queue, creating new light-weight structures to be used instead of protocol control blocks, and using hashes instead of linked lists [10] [11]. Apply the appropriate patch or solution from your vendor. Smurfing Smurfing is an attack that involves spoofing a number of ICMP echo (ping) packets with the victim's address as the source address and a directed broadcast address as the recipient. A directed broadcast address allows you to address every host on a subnet. By carefully selecting a large, densely populated subnet, an attacker can generate enough traffic from the subnet hosts responding to the ping packets to consume a lot of network and host resources with a few spoofed packets. This type of attack came to the public's attention when a number of large-scale attacks on Internet service providers and IRC servers occurred during December 1997 and January 1998 [12]. A similar attack uses the UDP echo service instead of ICMP echo packets to generate traffic. This is even more devastating because the target will send back ICMP unreachable messages, thus contributing to the traffic [13]. It is also possible, in certain situations, to create loops between the echo and chargen services in the relay hosts and the victim host. Very few applications use directed broadcast addresses. Some of these are network management and mapping tools and, in some instances, Microsoft's network browsing applications. It is recommended that you disable translation of layer 3 broadcasts into layer 2 broadcasts at your router. You can also configure your hosts not to respond to broadcast ping packets or to ignore ping packets altogether. You should also disable the echo and chargen services. For a long discussion on smurfing, see [14]. Predictable Initial TCP Sequence Numbers This attack allows an attacker to create a one-way TCP session with the target hosts while spoofing another host by guessing the TCP sequence number used by the other end. This attack was first described by Robert Tappan Morris in 1985 [15] and generalized by Steven Bellovin in 1989 [16]. It was made famous by the break-in into Tsutomo Shimomura's computers [17] that led to the hunt for and eventual arrest of Kevin Mitnick. [18] This attack is normally aimed at services that trust IP addresses such as the r-commands, but can generally be used to impersonate other hosts. In this way, you can, for example, send untraceable email. Contact your vendor for a patch if your operating system is vulnerable. Buffer Overflows Buffer overflows have become the most common security vulnerability found in UNIX operating systems today. They result from the lack of a good string or buffer data type in C and the misuse of the standard C library's string functions. We obviously have learned little from history. This is the same attack method the Internet Worm used ten years ago (in November) to infect machines via fingerd [19]. In the most common attack, an intruder attempts to overflow the buffer of a remote daemon or a setuid program to inject his machine code into the program's address space and overwrite the return address of some function. When this function returns, it will jump the intruder's code, which will normally spawn a shell. For a long discussion of buffer overflows, see [20]. Operating System-Specific Actions Here are some actions and commands specific to particular operating systems you can use against the attacks described previously. You should take the time to understand the negative side effects such changes will have in your environment. AIXTo prevent AIX from forwarding packets, use the command /usr/sbin/no -o ipforwarding=0 To prevent AIX from forwarding source-routed packets, use the command /usr/sbin/no -o nonlocsrcroute=0 AIX cannot be configured to discard source-routed packets destined for itself. To defend against SYN flooding, apply the appropriate patch (or superseding patch) from the following list:
AIX 4.X ships with response to broadcast pings disabled by default. AIX 3.X cannot be configured to prevent it from responding to broadcast pings. To prevent AIX 4.X from responding to broadcast pings, use the command no -o bcastping=0 BSD/OSTo prevent BSD/OS from forwarding any packets, use the command sysctl -w net.inet.ip.forwarding=0 BSD/OS versions prior to 2.1 ship with source routing enabled by default. Newer versions ship with source route forwarding disabled by default. To prevent BSD/OS from forwarding source routed packets, use the command sysctl -w net.inet.ip.forwsrcrt=0 BSD/OS cannot be configured to discard source-routed packets destined for itself. Under BSD 2.1To defend against SYN flooding, apply the patch K210-022. This patch adds a SYN cache. The are new sysctl entries to tune it's behavior: net.inet.tcp.syn_cache_limit, net.inet.tcp.syn_bucket_limit, and net.inet.tcp.syn_cache_interval. To enable a check that tries to detect spoofed IP packets, apply the patch K210-021 and use the command sysctl -w net.inet.ip.sourcecheck=1 Be careful. This may cause legitimate packets to be dropped if you are in an environment with asymmetric routing. To prevent memory exhaustion by fragment reassembly, apply patch K210-021. This limits the number of fragments in the reassembly queue. To tune the limit, use the command sysctl -w net.inet.ip.maxfragpackets=100 These patches have been integrated into BSD/OS versions greater than 2.1. CiscoAssuming that your router connects to your ISP using a serial 0/1 interface, you can apply the following access list to attempt to stop some IP-spoofed packets:
access-list 111 deny ip 0.0.0.0 0.0.0.0 any
interface serial 0/1
Apply the following access-list to stop any spoofed packets from
leaving your
access-list 122 permit ip < your-network-address> < mask> any For more information on configuring Cisco access control lists, see [21]. Upgrade to IOS 11.1(14)CA or later. This version integrates changes so that packets denied by an access list will be dropped at the interrupt level, with the exception of two packets per second per access list deny line. This greatly reduces the overhead incurred by the access lists. To prevent Cisco routers from forwarding source-routed packets, use the command no ip source-route To prevent Cisco routers from converting layer 3 broadcasts into layer 2 broadcasts and becoming an intermediate site in a smurf attack, use the command no ip directed-broadcast Digital UNIXTo defend against SYN flooding, increase the listen queue and lower the initial time-out. These tunable parameters are present in Digital UNIX 3.2G, 4.0, 4.0A, or later.
# dbx -k /vmunix To fix the predictable TCP sequence numbers, apply one of the following patches:
FreeBSDTo prevent FreeBSD from forwarding any packets, use the command sysctl -w net.inet.ip.forwarding=0 FreeBSD ships with source route forwarding disabled by default. To prevent FreeBSD from forwarding source-routed packets, use the command sysctl -w net.inet.sourceroute=0 FreeBSD cannot be configured to discard source-routed packets destined for itself. FreeBSD versions prior to 2.2.5 cannot be configured to ignore broadcast or multicast pings. Newer versions ship with response to broadcast and multicast pings disabled by default. To modify this behavior, use the command sysctl -w net.inet.icmp.bmcastecho=0 HP-UXTo prevent HP-UX from forwarding any packets, use the command HP-UX 10.x: nettune -s ip_forwarding 0 HP-UX 9.x:
adb -w /hp-ux /dev/kmem HP-UX ships with source route forwarding enabled by default, cannot be configured to prevent the forwarding of source-routed packets, and cannot be configured to discard source routed packets destined for itself. To prevent HP-UX from using predictable sequence numbers, use the command HP-UX 10.x: nettune -s tcp_random_seq < value> HP-UX 9.x: echo "tcp_random_seq?W < value>" | adb -w /hp-ux where < value> is one of
old behavior (default) The seed value for the rand*() functions is based on the time when tcp_init() (or nettune) is called, so don't make your uptime public (i.e., rstatd). To defend against SYN flooding, apply the appropriate patch (or superseding patch) from the following list:
After you apply the patch, turn on SYN flooding protection by using the command nettune -s hp_syn_protect 1 See [22] for information on how to tune the so_qlimit_min kernel parameter. IRIXTo defend against SYN flooding, apply the appropriate patch (or superseding patch):
LinuxTo prevent Linux from forwarding any packets, recompile the kernel with the option CONFIG_IP_FORWARD turned off. To prevent Linux from forwarding any source-routed packets or accepting any source-routed packets destined for itself, recompile the kernel with the option CONFIG_IP_NOSR turned on. To defend against SYN flooding, recompile the kernel with the option CONFIG_SYN_COOKIES or CONFIG_RST_COOKIES turned on. To prevent Linux from responding to pings altogether, recompile the kernel with the option CONFIG_IP_IGNORE_ECHO_REQUESTS turned on. If you are using Linux as a firewall, recompile the kernel with the option CONFIG_IP_ALWAYS_DEFRAG turned on to protect machines behind it from IP fragmentation attacks. To mark the stack as nonexecutable apply this patch and recompile the kernel with the option CONFIG_SECURE_STACK turned on. NetBSDTo prevent NetBSD from forwarding any packets, use the command sysctl -w net.inet.ip.forwarding=0 NetBSD versions prior to 1.2 cannot be configured to discard source-routed packets. Newer versions ship with source route forwarding enabled by default. To prevent NetBSD from forwarding source-routed packets use the command sysctl -w net.inet.ip.forwsrcrt=0 NetBSD cannot be configured to discard source-routed packets destined for itself. To prevent NetBSD from converting layer 3 broadcasts into layer 2 broadcasts and becoming an intermediate site in a smurf attack, use the command sysctl -w net.inet.ip.directed-broadcast=0 OpenBSDOpenBSD ships with forwarding disabled by default. To prevent OpenBSD from forwarding any packets, use the command sysctl -w net.inet.ip.forwarding=0 OpenBSD ships with source route forwarding disabled by default. To prevent OpenBSD from forwarding source-routed packets, use the command sysctl -w net.inet.dosourceroute=0 OpenBSD 2.2 and earlier cannot be configured to discard source-routed packets destined for itself. OpenBSD-current discards source-routed packets destined for itself if the net.inet.dosourceroute is not set. OpenBSD has unpredictable initial TCP sequence numbers. SolarisTo prevent Solaris from forwarding any packets, use the command ndd -set /dev/ip ip_forwarding 0 Solaris ships with source route forwarding enabled by default. To prevent Solaris from forwarding any source-routed packets, use the command ndd -set /dev/ip ip_forward_src_routed 0 Solaris cannot be configured to discard source-routed packets destined for itself. To prevent Solaris from using predictable sequence numbers, use the command ndd -set /dev/tcp tcp_string_iss < value> where < value> is one of
0 old behavior '0' is the old predictable algorithm. '1' used random(3) and may be predictable if the attacker knows the time the machine was booted or the time the kernel parameter was changed. New in Solaris 2.6, '2' implements the recommendations of RFC 1948. For it to work, you must configure a long-term secret on each machine. Sun recommends that this secret be encrypted password entry for the root account as it is found in the shadow password file. To configure this secret, use the command
ndd -set /dev/tcp tcp_1948_phrase Under Solaris 2.6, the correct way to enable unpredictable sequence numbers is to edit /etc/default/inetinit and add TCP_STRONG_ISS=2 If you have many machines with the same encrypted root password, you will want to find another secret to use for setting tcp_1948_phrase. To defend against SYN flooding, tune TCP abort time-out value using the command ndd -set /dev/tcp tcp_ip_abort_cinterval 10000 The value is given in milliseconds, which may make sites over links with high latency unreachable or unreliable. You can also increase the size of the backlog queue by using the commands
echo "tcp_param_arr< 14/W 0t10240" | adb -kw /dev/ksyms
/dev/mem To prevent Solaris from responding to broadcast pings, use the command ndd -set /dev/ip ip_respond_to_echo_broadcast 0 To protect against some buffer overflows and mark the stack as nonexecutable in some Sparc architectures, use the script found here. If you have any questions, corrections or additions please feel free to reach me at <aleph1@dfw.net>. References
[1] RFC 1825: Security Architecture for the Internet Protocol [2] RFC 1826: IP Authentication Header [3] RFC 1827: IP Encapsulating Security Payload [4] RFC 1597: Address Allocation for Private Internets [6] RFC 2002: IP Mobility Support [7] Network Flight Recorder, Inc. [8] Project Neptune, Phrack Issue 48, File 13 [9] "WebCom Security Software Failed in Server Attack," Wired News [10] Syncookies Mailing List Archive [11] "Re: SYN/RST cookies (was Re: a quick clarification...)," David Borman post to the tcp-impl mailing list. [13] "More broadcast fun" T. Freak post to the BugTraq mailing list. [14] "Smurfing: The Latest DoS Attack" [15] R.T. Morris, "A Weakness in the 4.2BSD Unix TCP/IP Software," Bell Labs Computer Science Technical Report #117 [16] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite," Computer Communications Review 19:2, April 1989, pp. 32-48 [17] Technical details of the attack as described by Markoff in The New York Times. Tsutomu Shimomura post to comp.security.misc [18] Jonathan Littman, The Fugitive Game [19] E.H. Spafford, "The Internet Worm Incident," Technical Report CSD-TR-933 [20] "Smashing The Stack For Fun And Profit," Phrack Issue 49, File 14 [21] "Increasing Security on IP Networks" [22] Hewlett-Packard Security Bulletin: HPSBUX9704-060, April 30, 1997
|
 Need help? Use our Contacts page.
First posted: 28th May 1998 efc Last changed: 28th May 1998 efc |
|
Issue index