How Safe Is Remote Desktop / Terminal Services?

First, see What Is Remote Desktop / Terminal Services?

To use Remote Desktop / Terminal Services, a server running Remote Desktop / Terminal Services must be exposed to the internet to accept incoming connections.

The remote user connects to the server via its public address (an IP address or domain name) with software called a Terminal Services or Remote Desktop client and is presented with a login prompt:

At this point the user has not been authenticated and the system will offer the login prompt to anyone. If the user successfully logs in they are provided with a full Windows environment.

So how safe can this be — opening your network to the internet and allowing virtually anyone to connect?

The answer is that it is pretty safe. But, as discussed in “Computing: Security Primer”, securing computer systems is a never-ending process. No computer system can be regarded, at any moment, to be 100% safe and unbreakable, without unplugging it from the outside world, turning it off and locking it in a bank vault. The only definitive statement you can make is that the system is as secure as it can be using the best practices at that time.

Fortunately a relatively small number of basic principles will keep most systems safe.

What Are The Risks?

Fundamentally there are three major risks in Terminal Services:

1. Weak Credentials. Since Terminal Services presents a login prompt to all-comers, obvious usernames and weak passwords make it relatively simple for an attacker to simply log in legitimately and roam your network.

2. Software Faults. The existence of faults in all editions of Windows which give rise to security vulnerabilities is well known. Faulty software exposed to the internet is an irresistible attraction for hackers. When exploit code appears, there is an initial hurried rush to install patches but the attacks continue for years afterwards. For example, as of this writing, the CodeRed worm is several years old and may be considered to be obsolete and irrelevant, but attach a vulnerable (unpatched) system to the internet and it will be infected surprisingly quickly. In November 2004, Avantgarde discovered that unpatched Windows XP SP1 systems were compromised by a variety of worms such as Sasser and Blaster in a matter of minutes.

   Remote Desktop connections are secured with encryption, so “software faults” could also relate to problems with encryption, such as a weak ciphers or man-in-the-middle attacks

3. Ex-Employees. It doesn't take a lot of technical knowledge for an ex-employee to obtain the Terminal Services client and make attempts to enter your network with their own credentials, especially as Terminal Services use is increasing and the employee may already be trained in its use.

Attacks could come from hackers deliberately targeting your organisation or automated “worms” randomly attacking IP addresses and looking for predefined vulnerabilities. A hacker will attempt to use a combination of weak passwords or other lax configuration and software vulnerabilities, and may spend hours or days attacking the system. An automated worm will typically probe the system once and move on if unsuccessful.

How Can the Risks be Mitigated?

• Disable anonymous access. There are two layers of anonymous access in Windows; one is the Guest account which is used to handle users who do not have valid credentials. Normally the Guest account is disabled by default, and although in small workgroups the Guest account has a legitimate role to play, as soon as you accept connections from outside the Guest account must be turned off. The second is that certain information about a system is available to users before they authenticate. This can be controlled, although being too restrictive may disable some applications. See http://support.microsoft.com/kb/246261 for details. (In fact the levels of anonymous access accepted are not particularly relevant for Terminal Services, but it's a good principle to apply anyway.)

• Use non-obvious usernames. If your website contains a staff directory, and John Smith's email address is [email protected], and Jane Brown's address is [email protected] and so on, it's fairly obvious to an attacker that their internal network usernames are john and jane. Even if you don't publish a list, it's not difficult to find out the names of staff and their email addresses from business cards, brochures and simply by asking the receptionist! Slightly obscured usernames such as John51 and Jane09 will not be hard for users to remember and will substantially deflect attempts to deduce login credentials.

• Use complex passwords. If an attacker has deduced an account name, the next step is to guess passwords and this may be simpler than you think. With a small amount of effort an attacker may be able to determine an employee's middle name, home address, childrens' name and so on and these are good candidates for password guessing. Passwords must be complicated and lengthy — but this doesn't mean they need to be meaningless like H81QQhl-a20!sdh. Good passwords can be constructed and remembered simply by taking visual cues from your environment. Look around your office and use a word, a number and a few punctuation marks (! ? - =). Capitalise the word and avoid birthdays, pet and children names and phone numbers. For example, a fine password is My desk is in the corner!.

• Don't use the same passwords on multiple systems. Unfortunately, people are inclined to use the same password across many systems and sometimes use their work email address for personal services. This means that an intrusion into a third-party system (such as famous hacks into Adobe and Sony user databases) which reveals an email/password pair, could provide access into a corporate network via Remote Desktop.

  Generally speaking, it's preferable for corporate passwords to be assigned to users by helpdesk, so there's no possibility that users' favourite passwords are being used in the corporate network.

• Use login policies. If users only require access during business hours, limit their account to those hours. Enable lockout policies whereby accounts are disabled after a certain number of failed login attempts.

• Be aware of staff changes. If someone leaves, or no longer needs access to the system, their account must be disabled immediately. Human Resources and Information Technology staff, who may usually have no reason to speak to each other, must communicate staff changes urgently.

• Use non-standard ports. See “Using Non-Standard Ports in Terminal Services/Remote Desktop”. Many internet worms exist which roam the internet attacking IP addresses on the default Remote Desktop port of 3389, usually looking for servers with known vulnerabilties or weak passwords. If the server is accessible on some other port number, automated or random worm probes won't gain any traction.

• Apply software updates. No amount of draconian access policies and complicated passwords will help if a software fault allows an attacker into the system. Software faults ultimately mean that something that should not happen will be allowed to happen, and in the case of a service that is accepting requests from other systems, that can give rise to a security hole.

  There have been a few software updates issued which relate to Terminal Services security, but the majority of Windows updates could be said to be unrelated to Terminal Services. However, ALL security updates are critically important because it is not always possible to determine what is at risk at the time the updates are published. Some faults which were initially thought to be benign or only affecting one aspect of the system were later found to be highly dangerous and able to be exploited from several vectors.

  Software updates must also be applied to the applications users are accessing. If the user is reading email in a Terminal Services session, and a virus gets loose through a software vulnerability (email-borne viruses are still the most common security problem), making Terminal Services impenetrable from the outside will not help.

  Windows 2000 and later provide an Automatic Updates feature which can download critical updates and optionally install them and reboot at set times. If this is enabled the system will require less administrative effort to maintain. But this function may not download full Service Packs, so these must still be applied manually as they become available.

• Update the encryption. Remote Desktop connections are encrypted with SSL/TLS, but by default some versions of Windows use relatively weak encryption protocols and ciphers. See Improving Encryption Quality on Windows-Based Servers.

• Keep the technology current. Each new version of Windows contains a version of Terminal Services with more security features than the previous. Even with all patches installed, earlier versions are still architecturally weaker than newer versions. Service packs and patches only fix faults, they do not improve the underlying infrastructure.

• Be informed. Subscribe to security and virus bulletins (see Cadzow Knowledgebase Article 1131) for notification of faults and current threats.

• Educate users. Users must know that their login credentials are private and not to be disclosed to anyone else.

And finally,

• Use virus protection! If an attacker successfully enters the system their first act may be to install a set of hacking tools and some antivirus products can detect these, so an intrusion may be detected quickly on that basis. If the system falls victim to a known worm the antivirus system may detect the files the worm uses even if it can't stop the worm entering in the first place. But be aware that, in a Terminal Services environment, antivirus is really the last line of defence because it can only help you once the system has been successfully compromised, and a successful intruder will most likely disable antivirus programs as their first act anyway.

What About Viruses?

The above discussion is mainly concerned with attacks directly against the Terminal Services server where an authenticated connection does not already exist. In regards to viruses, travelling across legitimate, authenticated connections, there are two issues:

1. Can the client infect the server? and

2. Can the server infect the client?

Can the Client Infect the Server?

The short answer is “no”. The longer answer is, “not today”.

A client establishes communication with the server using Remote Desktop Protocol (RDP). This is a set of instructions that allows the client to send keystrokes and mouse actions to the server and for the server to send screen displays to the client. This is completely separate from the methods that allow, say, a file to be transferred to another machine (SMB), an email message to be sent to another mailbox (SMTP) or for one computer to communicate with another (TCP/IP or NetBIOS), which are the usual ways worms and viruses propagate. So a virus that gets loose on a client workstation may be able to infect (or try to infect) other machines on the network, on the internet or by sending infected emails, but won't be able to transmit itself over RDP.

Or at least: not today.

Although RDP is not currently designed to transmit arbitrary binary data (such as executable files) from the client to the server, user demands may force this functionality to be included in later versions. Further, any faults in RDP which allow the client to cause the server to malfunction may also be exploitable. So the possibilities exist or will exist. History has shown that as certain technologies become ubiquitous, viruses are not far behind. Consider that email, chat (IRC), instant messaging (IM) and peer-to-peer (P2P) have been overrun by viruses — although their major downfall has been the ability to transfer files. Consider also that RDP is included in every new computer running Windows XP, and that there is a burgeoning third-party industry providing client and server tools.

How does one protect oneself from these imagined, future threats? The answer is, fortunately, easy: the same way one protects against today's real, in-the-wild threats. Good security practices — applying patches, maintaining antivirus systems and using a firewall — will keep the client system safe and therefore the server. See Cadzow Knowledgebase Article 1242 for a more fulsome discussion.

Can the Server Infect the Client?

The possibility of some future fault that allows transmission of hostile code from one machine to another is just as valid from the other direction.

But a more immediate and, unfortunately, easily exploitable, threat is drive mapping. Windows Server 2003 when used with Remote Desktop Connection 5.2 or greater allows a drive mapping back to the client workstation from the Terminal Services session. This means that a virus that gets loose in the Terminal Services session can easily copy itself back to the client. This sounds pretty scary, except there are some mitigating circumstances that make a virus attack in this way fairly difficult to get started:

• Drive mapping can be turned off at the server and/or the client, so it would only be enabled when there is a real need;

• A virus that gets loose in a Terminal Services session could only affect that user's profile and the user's client workstation, it could not jump to other Terminal Services sessions (unless the server was poorly configured) or infect other connected clients;

• Virus protection on the client would detect the virus as it was being copied, most likely before it could be executed;

• Virus protection on the server would detect the virus as it entered the system; and

• The most common way for a user to become infected is via email or web browsing, and these are not ideal tasks for a Terminal Services session anyway. If users are only using Terminal Services to access the corporate database and other business applications, their exposure to client-side malcode is negligible or nil.

So once again a fairly simple strategy presents itself: apply software patches and maintain antivirus systems on the server and client.



Copyright © 1996-2023 Cadzow TECH Pty. Ltd. All rights reserved.
Information and prices contained in this website may change without notice. Terms of use.
Question/comment about this page? Please email webguru@cadzow.com.au