One Way An Attacker Uses Convenience Against You

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.

This entry was posted in General InfoSec by Troy Vennon. Bookmark the permalink.

About Troy Vennon

I recently separated from the U.S. Marine Corps after 8 years. I spent the first 3 1/2 years building classified and unclassified networks all over the world. There was a natural progression from building those networks to securing those networks. My last 4 1/2 years in the Marine Corps took me to Quantico, Va where I was stationed with the Marine Corps Network Operations and Security Command (MCNOSC). While with the MCNOSC, I was a member of the Security section, which was responsible for the installation and daily maintainance of the 34 Points-of-Presence that made up the Marine Corps 270,000+ user network. After a period of time with Security, I moved over to the Marine Corps Computer Emergency Response Team (MARCERT). There I was the Staff Non-Commissioned Officer of the MARCERT, which was responsible for the 24x7 monitoring of network traffic across the Marine Corps. Specifically, we monitored network traffic for malicious intent and investigated any network incidents as they occurred. While with the MCNOSC, I attained my CISSP, CCNA, and OPST (OSSTMM Professional Security Tester). I have been with MicroSolved for the past 4 months as the Senior Security Engineer, Technical Lead, and Project Manager.

Leave a Reply