Over the past year, MSI has performed so many information security assessments that I have lost count. As the Senior Security Engineer and quasi-Project Manager, I get to read each and every report that comes out of our technical team, before it gets shipped off to the client. While we occasionally see things that can only be described as “interesting”, there is usually one constant theme amongst the overwhelming majority of our clients that continues to surprise us AND them….and that’s the use of Microsoft’s Terminal Services.
For those of you that don’t know, Terminal Services is a solution that is designed to allow remote access to the graphical user interface (GUI) of the machine on which it is installed. Terminal Services is probably one of the most convenient solutions around for allowing remote access to a particular system. What continually surprises our clients is the fact that we, as the proverbial attacker, are just as capable of taking advantage of that “convenience” as the administrators who regularly use them are.
For an attacker, Terminal Services does not only provide access to a system’s GUI, given the correct credentials, it also provides a way to verify whether those credentials are legitimate. Here’s the deal, when an individual (or attacker) connects to a Terminal Services login portal, they are authenticating to the local machine OR the domain…dependent only upon their current mood or desire. You see, Terminal Services gives you the option to choose where you wish to authenticate, assuming the target host is configured as part of the domain.
While it might be useful to discuss exactly how an attacker can use Terminal Services against you, I think it’s more useful to discuss how we have seen Terminal Services deployed and what some of the better solutions might be.
We primarily see Terminal Services deployed on an internal network, which is where it was designed to be deployed. On some rare occasions (much to our delight, our clients dismay) we see Terminal Services deployed on Internet-facing systems. This should be considered an absolute no-no. If an attacker were able to get their hands on legitimate credentials (any credentials that are valid on the target machine or domain, if configured) there is nothing stopping them from gaining access to the GUI on that Internet-facing system. No need to scan the host for vulnerabilities. No need to run any exploit code. No need to set up any netcat shells. No need to maneuver around the system via the command line. The attacker can log into the host just as if he were sitting at the keyboard.
The problem with allowing Terminal Services on an internal network is that it simply makes an attackers job much easier than it should be. Again, given legitimate credentials, it becomes trivial for an attacker to move from host to host that has Terminal Services installed. You can use your imagination to figure out what the attacker does once logged into the hosts. The big question here is…which systems usually have Terminal Services installed, on an internal network? In our experience, it’s usually the critical systems that administrators need to work with on a regular basis. That’s right…domain controllers, mail servers, web servers, database servers, etc. Many of those systems are usually showered with extra attention to ensure that their patches are current, anti-virus is up to date and logs are analyzed.
If you, the administrator, are dedicating so much time towards keeping those critical systems up-to-date, why keep an authentication portal available that offers no encryption, is vulnerable to man-in-the-middle attacks and grants remote access to the GUI of your most critical systems…all while allowing every single user on the domain to authenticate to the system?
On Internet-facing systems, we would much rather see a VPN solution being used to allow remote access. If a VPN solution cannot be used, we would prefer to see people using some sort of Virtual Network Connection (VNC) or Secure Shell (SSH) solution that encrypts the communication tunnel and authenticates to the service and not the local system or domain.
In both VNC and SSH, a username and password is set when the service is installed and configured. Those credentials are specific only to the actual remote access service and not the sytem or domain as a whole. So, if an attacker compromises those credentials, they don’t automatically have access to the local system or domain…they are still stuck inside the sandbox of the remote access service.
On internal systems, there is really a couple of ways around the Terminal Services problems. If you are dead set on using Terminal Services, MSI would recommend that you disable the service until use is needed. At that time, it is possible to start the Terminal Services service, remotely. Once use has expired, disable the service again. In addition to disabling the service, it is imperative that Terminal Services be configured to only allow administrator accounts to connect and requires a multi-factor authentication token to authenticate. In doing so, you have created a service that is only available when needed and then only to individuals who are administrators AND possess a legitimate token.
The second option would be to use VNC, again. As mentioned, using VNC instead of Terminal Services allows for credentials to be used that aren’t related to the local system or the domain…only the VNC service.
These are just a couple of ways around using Terminal Services. A lot of our clients say that they use Terminal Services because it is convenient. Our answer…yes we know…thank you for the assistance. A lot of times organizations have to try to balance security and convenience in order to allow for functionality. In this particular case, MSI believes that the individuals that normally use the Terminal Services should be technically savvy enough that security can be increased and convenience can be reduced, especially on critical systems.
Then again, if you think your convenience isn’t that big of a security problem, you could always ask us to help validate that theory. Probably much easier AND cheaper than if a real attacker validates the theory for you.