DoS | Maximum Mac OS X Security

Although DOS may be considered an attack class all its own, DoS does not refer to early PC operating systems. DoS ”or Denial of Service ”attacks are designed to stop a machine or network from providing a service to its clients . Depending on your network, this can mean just about anything: keeping your mail server from delivering mail, stopping your Web server, or even keeping you from logging in to your machine to work locally. The attack itself can take on a number of forms, from a direct network attack to a local attack instigated by a user account (or someone with access to a user account) on your system. No matter what the target or how it takes place, DoS attacks usually hit hard, are difficult to diagnose, and can put you out of business until the attack has ended.

NOTE

Many DoS attacks are launched against a particular application or service. Throughout the book wherever there has been (or is) a recent DoS for a Mac OS X daemon or application, we will attempt to provide a description and CVE reference for further information. This section is meant to provide a more general overview of DoS attacks.

Network Target DoS Attacks

The most effective and costly DoS attacks take advantage of holes in an operating system's TCP/IP implementation to bring down the entire machine. These are the "holy grails " of attacks ”simple, fast, and affecting everything they touch. The first widespread DoS that affected individual users is the now infamous Ping of Death .

Ping of Death

In 1996, it was discovered that an IP packet (see Chapter 7, "Eavesdropping and Snooping for Information: Sniffers and Scanners"), constructed with a length greater than 65536 bytes (an illegal size ) could crash, disable, or otherwise disrupt systems running Windows 95, Mac OS 7.x, Windows NT, Linux, Netware, and a wide range of printers, routers, and other network devices. Windows machines proved to be an especially useful launching platform for the attacks because the Windows ping command allowed these illegal packets to be sent directly from the command line with ping -l 65510 <hostname or IP> . Software quickly followed for other operating systems that could scan an entire network, sending the invalid packets, spoofing the source address, and literally forcing hundreds of users to reboot within seconds of the attack starting.

Operating system vendors responded quickly to the situation, issuing patches shortly after the problem was discovered (less than 3 hours, for Linux!). A complete description of the PoD, the machines affected, and example attack source code can be found at http://www. insecure .org/sploits/ping-o-death.html.

WinNuke

Another "popular" TCP/IP DoS attack affected Windows machines by the thousands. Windows 95/NT machines were found to be easily crashed by packets with the OOB (out of band ) flag set on an established connection. Because most Windows machines ran file sharing services, these attacks were commonly aimed at port 139, the standard NetBIOS/IP port. A remote attacker would connect to the port, then send a packet with the OOB flag set. The result? An instant Blue Screen of Death. "Winnuke" software was released for other users to take advantage of this flaw, resulting in much glee from Macintosh and Unix users.

Strangely enough, after Microsoft issued their initial patches for the problem, Macintosh computers could still crash remote systems with WinNuke. The Macintosh TCP/IP implementation set a TCP Urgent flag within outgoing TCP packets. Windows machines could not handle this additional flag, and continued to crash at the hands of Macintosh users until Microsoft released a second patch. Information on the Windows OOB bug and WinNuke code can be found at http://www.insecure.org/sploits/windows.OOB.DOS.html.

SYN Floods

The previous two attacks have used bugs in the TCP/IP implementation, but it is also possible to exploit the properties of TCP/IP itself to create a DoS condition. A popular means of doing this is through a SYN flood . SYN packets, introduced in Chapter 7, are used by a client computer to initiate a connection with a remote machine.

As demonstrated in Figure 9.1, upon receiving a SYN packet and sequence number, a server allocates resources for the connection and sends a SYN packet, acknowledgement , and another sequence number. The client should then respond with a sequence number and second acknowledgement at which point the connection will be opened. If the client does not acknowledge immediately, the server must wait a specific amount of time before it can assume the connection is dead and de-allocate resources.

Figure 9.1. Initial TCP/IP conversation.

graphics/09fig01.gif

SYN floods work by overflowing a server with SYN packets (often from spoofed source addresses), causing it to allocate more resources than it can manage (thereby running out of memory), or more connections than it allows (forcing valid connections to be denied ). The end result in either case is that the server becomes inaccessible for, at least, the duration of the SYN flood.

TIP

You can use netstat to display the status of connections on your Mac OS X box.

You can detect SYN floods by looking for abnormally numerous incoming SYN packets in relation to general TCP/IP traffic. High ratios of SYN packets can trigger the operating system to drop incoming SYN packets ( denying connections) until the flood has ended, or take a more complex but less disruptive approach ”such as using SYN cookies.

SYN cookies now protect most modern operating systems, such as Linux and BSD, against SYN floods. During a TCP/IP conversation, the server and client exchange sequence numbers to maintain a synchronized conversation. A SYN cookie is a specially calculated sequence number that is based on the remote client's IP and is not guessable by the client. When making the initial acknowledgement of the SYN packet, the server sends back this special cookie (SEQ(B) in Figure 9.1) and then, for all intents and purposes, forgets about the conversation. If it receives an acknowledgement with the appropriate sequence number (SEQ(B+1)), it knows the connection is legitimate and allows it to proceed.

DDoS

In a simple DoS assault, the attacker uses his or her PC or a compromised machine to send packets to the victim. Although a single computer is capable of causing plenty of problems, it is also reasonably simple to block at your router or network firewall.

Attackers quickly discovered that to create a sustained DoS situation, they would need to hit from multiple locations simultaneously , and the DDoS, or Distributed Denial of Service attack, was born. A DDoS attack typically uses multiple compromised computers, or zombies , that are "waiting" for an attack to be triggered ”from a master computer, as seen in Figure 9.2. The zombies do not need to use spoofed addresses and can be used much more aggressively against the target because they are not the actual attacker. DDoS attacks need only flood the attacked network with packets, rendering it inaccessible.

Figure 9.2. A DDoS attack uses multiple zombies to attack a victim.

graphics/09fig02.gif

DDoS attacks are difficult to stop because of the number of routes that may be used during an attack. Recent attacks have used ICMP traffic to synchronize the states of the zombies, making the detecting and firewalling of potential zombies even more troublesome . Successful DDoS attacks are usually carried out only after a significant amount of upfront work has been performed to prep the zombies and scout the targets.

For examples and analysis of DDoS attacks, read the following analyses:

Tribal Flood Network . http://staff.washington.edu/dittrich/misc/tfn.analysis.txt
Stacheldraht . http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.txt
Global Threat . http://bots.lockdowncorp.com/gtbot.html
Trinoo . http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt

NOTE

While most large-scale DDoS attacks do require zombies, a very popular attack ”Smurf ”does not. The Smurf attack works by forging the reply-to address on an outgoing broadcast ICMP packet. The packet is sent to an entire network with the goal of tricking the machines into replying simultaneously to a victim address ”overwhelming them with data. Because a single packet is used to generate multiple attacking responses, this is called a magnification attack.

More information about Smurf attacks can be found at http://www.pintday.org/whitepapers/dos-smurf.shtml, and example code can be found at http://www.crimelist.com/dos.htm.

At this time, there are no known instances of Mac OS X being used in a DDoS attack, but there is no guarantee that the clients for distributed attacks won't be made available at some time in the future.

Protection

Denial of service attacks are difficult to stop because they are unpredictable and often exploit protocol or network weaknesses and do not require the remote machine to be compromised. A completely secure Mac OS X machine could be crippled by a network DDoS attack no matter how well the administrator has protected the network. The Internet has a finite amount of bandwidth on a finite number of routes available for a given host. If those routes are flooded by thousands of machines simultaneously throwing packets at the host, it doesn't make any difference what software, operating system, or security the target machine has in place.

Protection comes from prevention and understanding. Following these guidelines will help protect you from DoS attacks:

Keep your software up to date and secured by using the software's own security mechanisms. This is repeated throughout the book and cannot be stressed enough. Even though most DDoS attacks are the result of compromised clients, a sendmail daemon with relaying accidentally left active could be used as a client in a DDoS email attack without any compromise being necessary (see Chapter 13, "Mail Server Security").
Firewall, if possible, network clients. DDoS clients often require a trigger from the attacker to start operating (sometimes sent via IRC). If the trigger cannot be received, the compromised client doesn't pose a threat (see Chapter 17, "Blocking Network Access: Firewalls"). Blocking broadcast and multicast traffic and verifying packet source addresses are good overall preventative measures.
Implement intrusion detection. Intrusion detection software can alert you to DoS attacks and help prevent system compromises from taking place (see Chapter 18, "Alarm Systems: Intrusion Detection").
Understand your network topology and upstream provider. An attack aimed at an entire network or the network's routing/firewall/etc. equipment cannot be stopped by an end user sitting in front of his or her Mac. Your upstream provider may be able to block the attack, or, at the very least, you can disable your feed until the attack has subsided.

Top