13.3 Remote DesktopRemote Assistance

13.3 Remote Desktop/Remote Assistance

Integrated remote control is one of the most useful features of Windows XP. This concept is not new, as illustrated by PC Anywhere , VNC, and Back Orifice. The fact that this technology now comes included with the Windows XP operating system has opened a new chapter in the history of Microsoft's family of desktop operating systems. However, several security issues have been discovered since the release of XP that can make these new additions a potential security risk.

13.3.1 Abusing the Remote Desktop

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:

1. If the Default view is enabled, click the Start button.

2. Right-click on My Computer and select Properties.

3. Click on the Remote tab.

4. Check the "Allow remote users to connect remotely to this computer" box.

5. Click the Select Remote Users... button.

6. Click the Add button to allow users Remote Desktop access.

To grant remote access permissions to a user, the account must have a password assigned.

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.

13.3.1.1 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

13.3.2 Abusing Remote Assistance

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.