88

I have a sort of a conflict with my company's Security Lead Engineer. He says that Remote Desktop Protocol (RDP) is not secure enough and we should be using TeamViewer instead. We use RDP not only to access local resources inside our corporate network but also for the access to resources (running Windows 2012+) in cloud hosting.

In both the scenarios how secure is it to use RDP?

prot
  • 991
  • 1
  • 6
  • 7
  • 18
    How is RDP being used (or proposed to be used)? Opening port 3389 facing the internet on all production servers and calling it a day is a bad idea for security. There are many options within Windows to make RDP more effective, so the answer to how secure a RDP based cloud hosting remote management method is, would be: "maybe" – Jeff Meden Aug 09 '16 at 14:15
  • 91
    TeamViewer is much, much less secure than RDP. With a properly configured RDP setup, you can have a pretty secure system, but with TW, your systems get compromised [if **they** do a mistake](http://www.theregister.co.uk/2016/06/01/teamviewer_mass_breach_report/). – ave Aug 09 '16 at 14:50
  • 24
    I would never allow teamviewer as a renote access solution. RDP inside a VPN – Rui F Ribeiro Aug 09 '16 at 19:53
  • In most cloud providers like azure and aws, you can setup security groups and only allow rdp traffic from whitelisted iOS – spuder Aug 10 '16 at 01:30
  • 3
    One of issues with TW, which RDP prevents by default, is: "Who moves my mouse!?" ;) – PTwr Aug 10 '16 at 12:18
  • 47
    Sorry, but how does such a person get to a place in life where they have the title "Security Lead Engineer"? Did they win a raffle? – underscore_d Aug 10 '16 at 13:12
  • @underscore_d Not related to the question... but ostensibly they were a member of a security team and promoted to team lead, or were hired on directly as a team lead. Just like any other job in the world. – TylerH Aug 12 '16 at 18:22
  • 3
    @TylerH and how did they get a position on that security team (and not lose it) in the first place? – Doktor J Aug 12 '16 at 19:48
  • @underscore_d We still don't know how prot's network was organized. The security lead engineer could object against exposing an RDP server to the Internet, not against using RDP itself. – enkryptor Aug 13 '16 at 13:55
  • 3
    @enkryptor but in what way would replacing RDP with TV make things any better, if not a lot worse? TV still exposes known ports, right? and _is_ an MITM? and has had mishaps in recent memory? and means [the computer you're connecting to gets left w/ your session running in unlocked, public facing fashion, available to anyone who would think to turn on the screen](http://security.stackexchange.com/a/133468/81253)? If the OP has details that would make this seem sensible then sure, this might be revealed in retrospect to be a very well-reasoned decision... but I'm just not seeing it as it stands – underscore_d Aug 13 '16 at 14:57
  • 1
    @underscore_d "TV still exposes known ports, right?" - no, its client work through the server. No need to open listening ports – enkryptor Aug 13 '16 at 21:06
  • 1
    Really TV is for providing workstation IT support to people remotely. It's pretty good for that, and very handy that the person you are helping can chat with you and see the screen while you are providing support. That's what I would limit TV to. For remotely logging into servers as others have said RDP over VPN is a much better solution. – Matthew Lock Aug 14 '16 at 07:22
  • 1
    If you don't want to open a listening port for RDP, you can connect to the machine through reverse connection (e.g. reverse SSH tunnel). – Lie Ryan Aug 14 '16 at 15:01
  • 2
    RDP over SSH (I use this from Linux to access Windows and Linux boxes remotely). – Mark K Cowan Aug 15 '16 at 13:52

10 Answers10

95

I believe that Teamviewer is a proxy service for tunnelled VNC connections. Hence, the first security consideration with regard to that service is that it is MITM'ed by design. There have been suggestions that the service was compromised a couple of months ago.

(Note that although VNC uses encryption, the entire exchange is not, by default, encapsulated - but it's trivial to setup a SSL/ssh/VPN tunnel).

Next consideration is that it means installing third party software on your systems - but then if you're running a Microsoft platform then you're already running software from multiple vendors which is probably not covered by your patch management software; keeping software up to date is one of the most effective means of protecting your systems.

As long as your RDP connection is using SSL, it should be at least as secure as Teamviewer, and IMHO, a lot more so.

symcbean
  • 18,278
  • 39
  • 73
  • 4
    How do you know if RDP is using TLS? (I assume you meant TLS instead of actual SSL.) – jpmc26 Aug 09 '16 at 16:38
  • 4
    Yes, TLS. The tunnelled connection uses port 443 by default (old style RDP uses 3389 from memory). There's also an option when configuring the server. – symcbean Aug 09 '16 at 21:16
  • 2
    RDP will use a TLS connection if the server is configured with a certificate (Windows Server 2012 and later use a self-signed certificate by default, desktop Windows does not IIRC) even on port 3389. – Dai Aug 11 '16 at 01:41
  • 10
    @TheD RDP on desktop versions of Windows also uses TLS, albeit with self-signed certificates (unless joined to a domain). – Michael Hampton Aug 11 '16 at 03:37
  • 1
    @symcbean You can run TeamViewer in local mode, in which case you connect by an IP address instead of using a "TeamViewer ID" and bouncing through their servers. I use it all the time over VPNs (and also on internet-connectionless LANs). Does that change any of your points at all? – Jason C Aug 15 '16 at 05:02
  • 6
    @JasonC It reduces TeamViewer to simply a RDP/VNC clone, with all the disadvantages that RDP has, plus the 3rd party nature of TeamViewer (one more party to trust). – Aron Aug 15 '16 at 06:02
72

Edit: According to the comments there seems to be combination of configuration options in the enterprise edition of TeamViewer which might reduce my concerns. Since I have never used those, I cannot give an assessment about those and how well they work. According to the comments it might to be a buggy solution.

I am a server admin (Windows and Linux) and I would block any attempt to install TeamViewer on the servers for following reasons:

  • all data travel over a trusted (?) third-party server and this is on the internet: why should I trust them? Are you sure there is no security hole that lets someone on the data path attack the systems? Do I trust that their servers don't get compromised?
  • it depends on the internet: network/internet problems are more likely to disable the ability to remote admin the systems
  • third-party closed source software with proprietary (undocumented?) protocol: should I trust them and that their protocol is secure?
  • I don't know about user/rights management for TeamViewer but this might also be a problem. As far as I know, TeamViewer gives you the screen of the currently logged in user, which might give problems with audits (which person did a certain action?) and user rights (the person connecting gets the rights of the previous connected user). I hope everybody has it's own user on the server and doesn't use the same (maybe even administrator!) user.

To me, there are too many red flags.

Our servers are in an isolated subnet where the firewall/switch only allows preconfigured ports in and allows users to connect with VPN to this subnet with their username/password. We follow a defence-in-depth approach: only certain groups get privilege to connect to the VPN with their user. Inside the VPN, they can use RDP or SSH. If there should be a security vulnerability in RDP, the attacker would first need access to VPN or LAN. This would mean they would be either our IT staff (which a company must trust to some degree), get access to VPN or physical access or hack one of the servers. Physical access means breaking into the datacenter; if this happens, there are bigger worries. The same goes for someone of the IT staff going postal. If they breach one of the servers, they would also need a privilege escalation vulnerability to attack because they are locked down accounts. For VPN access, he would need a vulnerability in the VPN or get the account of someone with VPN privileges.

And all of this only in the case that there is an RDP vulnerability. Most likely only an attacker classified as an advanced persistent threat (APT), which is to say someone using sophisticated techniques to target your specific system in a sustained attack, would have a 0-day exploit for RDP and it is more likely that such an attacker would be able to use easier methods/vulnerabilities in other software.

H. Idden
  • 2,988
  • 1
  • 10
  • 19
  • 2
    A lot of these points go away when you run TeamViewer in local mode. In that case you connect by IP instead of some ID number, and you never touch their servers (works over a LAN with no internet connection as well). – Jason C Aug 15 '16 at 05:05
  • @JasonC I haven't seen this feature yet. I will need to check this out. This would indead change some of these points. But the problem about the audit-ability and the fact that you get the screen/user like it was left from the last one still remains (might or might not be a problem depending on the company). – H. Idden Aug 15 '16 at 17:14
  • The "local mode" usage isn't obvious; on the server side you go into Extras -> Options -> General and pick "accept exclusively" for "Incoming LAN Connections". Weirdly, sometimes the UI gets buggy and you need to do this on the *client* side too to enter IP addresses instead of IDs (adding to the list of confidence-breaking TV quirks). The client side may be more well-behaved in newer versions. – Jason C Aug 15 '16 at 17:19
  • 1
    To your last point, TV has enterprise software to control all of that. So it's not really a point – Insane Aug 15 '16 at 17:46
  • @Insane thanks for the information. This feature was added after the last time I reviewed TeamViewer more completely. – H. Idden Aug 15 '16 at 18:10
  • Thanks for all the comments. I added the information to the answer. – H. Idden Aug 15 '16 at 18:10
36

In addition to the other great answers, TeamViewer offers less physical security because it requires that the screen is unlocked in order to facilitate a remote session.

That is, anyone walking past a keyboard and monitor of a remotely administered session can observe it and possibly take over the session should the remote user not be paying attention.

Note, it appears possible to blank the screen after installation of a display driver, however this has to be done on each connection leaving a window of opportunity.

Also, you are now trusting the security of the TeamViewer screen blanking rather than the security of the Windows lock screen - make sure that you are comfortable with that.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Of all the good points against TV here, this just might be the one that jumps out and screams 'avoid like the plague' the most blatantly of all. I don't know whether to laugh or cry. – underscore_d Aug 13 '16 at 14:56
  • @underscore_d Keep in mind that this is a thing that people could purposefully desire in some scenarios, such as remote support: if the user at the other side can see (more or less) what you're doing, it's more reassuring for them, which makes it less likely that they try to claim that you did something harmful during your support session. – gbr Oct 05 '18 at 14:12
26

To begin, I know nothing about TeamViewer, so I won't attempt to comment on it.

Historical RDP servers used "RDP Security", which is indeed a broken protocol and vulnerable to MITM. Don't do that. Even 2003r2 can do TLS for RDP, so there is no modern reason you should be forced to use RDP Security.

Modern Servers will support TLS, so the security of RDP is directly related to the security of TLS. With registry tweaks you can enforce a subset of TLS that you like - force to 1.2, restrict to certain cipher suites, maybe other things.

Also, there is a RDP specific angle here in that the server can restrict connections to only those that support "Network Level Authentication". NLA still uses TLS, it is just a protocol change to perform the authentication earlier in the exchange. I believe this is intended to protect against a denial of service attack where unauthenticated users repeatedly attempt to connect without authenticating.

If you were to decrypt and trace a RDP TLS Sesssion using NLA, you would see the following:

  • X.224 Exchange, unencrypted, 1 packet in each direction to determine if client and server can talk NLA
  • TLS Handshake
  • NLA (really [MS-CSSP]) exchange to perform authentication
  • Normal RDP protocol exchange per [MS-RDPBCGR]
Daniel Bungert
  • 361
  • 2
  • 4
  • Also might like to point out that forcing TLS 1.2 can break other stuff (namely SQL Server). It's a good security measure, but be wary when enabling it. – AStopher Aug 09 '16 at 22:02
  • 11
    @cybermonkey Breaking software that doesn't support TLS 1.2 is a *good thing* :P – Navin Aug 11 '16 at 00:47
17

Assuming that you're using a modern version of RDP and configure it correctly (e.g. enable NLA, sort out proper certificates) the main risk of exposing it directly to the Internet tends to be the problem of exposing a username/password authentication system to the Internet, which is that you're allowing attackers to attempt to brute-force Active Directory Accounts (assuming this is an AD environment and not a set of stand-alone servers).

This isn't great as you either end up with a DoS risk with account lockout set or a risk of unauthorised access with no account lockout set (someone will always choose a weak password, or use one that gets breached elsewhere), so if you are exposing RDP directly I'd recommend two-factor authentication on users that are allowed access via this mechanism.

As for TeamViewer, there isn't a risk of direct access but you are placing trust in them as an organisation and has been pointed out by other answers they have had security concerns recently.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
10

I'll expand on Daniel Bungert's explanation of protocols involved and why they work together. Having written a MitM proxy for RDP, I'm very familiar with the inner workings of most protocols involved. (More than I'd like to be...)

You can configure it to only operate over TLS. This offers great security in it's own right, every message is wrapped with TLS encryption. There are group policies you can manage which will set the allowable TLS encryption protocols. You can use this to specify only the ones with key-lengths or algorithms that you deem fit. These are general windows settings and not rdp specific. Your only concern would be users accepting bad certificates, in which case a MitM attack is possible.

However, you can further configure it to only operate with NLA authentication. Specifically, this will use CredSSP with NTLM. This prevents MitM because the certificate used in the TLS layer is used (along with other things) to encrypt the password. You can then no longer just forward the encrypted password because the target rdp service will not authenticate a hash that was generated with a certificate other than it's own. The reason my mitm works is because we know the passwords that are being used to connect to the proxy, and with that we can extract information and generate a new hash for the target rdp service. A malicious rdp proxy will not have that advantage.

So with both TLS and NLA configured, rdp is safe from users that may accept bad certificates. This counters Overmind's concerns about mitm attacks.

8

I'd go with some kind of VPN from the user's remote computer to a firewall at work, and then run RDP over that encrypted link.

Problem with leaving a port open is that eventually it is found, and you'll have brute-force login attempts. Either that will just slow your environment down, or it will lead to accounts being locked out, or they find a username with a weak password (There's always that one user....)

You can explore 2 factor auth with smartphone apps, hardware tokens, or pre-printed one-time passwords.

Remember, security is the opposite of convenience.

Criggie
  • 508
  • 3
  • 12
6

This started as a comment.

It's important to point out the "Who's at fault question". If you use a third party service and they fail to provide it's their failure to provide. If you use something in house and it fails, now it's the house's fault. Such distinctions carry a lot of weight. It might not mean anything to actual security, but that can sometimes go to the sidelines.

For example if you need to gain certification for a contract, and that certification says something to the effect of:

You must use secure remote management methods, unencrypted remote management methods are not allowed. Contracting with a third party to provide services is allowed. Encryption must be foo strength and bar requirements. Common services that meet theses requirements are LogMeIn and TeamViewer. Common services that do not meet these requirements are GoToMyPC and plain VNC.

Then the decision could be made to use Team Viewer.

Then there is the risk to the business. It could be argued that Teamviewer is less risk, because your using a service in good faith that is supposed to be secure. At the same time RDP may be more of a risk because now your standing your team's knowledge up against random peoples understanding.

In the end, while this doesn't have any real connection to real security, it's important to remember that companies don't do security cause it makes them money (normally). They do it as Risk mitigation and because they have to to keep making money. Using a third party service may remove some of the risk for the company.

coteyr
  • 1,506
  • 8
  • 12
  • I have had this exact conversation with my CIO over multiple issues. Even though she acknowledges that our team's proposed solutions are probably superior, the value of offloading worst-case scenarios to a 3rd party is worth more from the executive viewpoint. – Foo Bar Aug 14 '16 at 20:17
4

As mentioned you should use RDP + Encryption if possible. But, I have seen no mention of basic security measures against attacks (brute or otherwise) in answers provided.

ANY software/port(s) that is left open to public is going to be scanned/found. Period. RDP or not. Encryption or not. If public access is not needed why allow it?

Creating and admin'ing an 'allow' list based on IP Blocks may be time consuming and a pain (if many hosts accessing), but it should not be overlooked. Be it 1 IP or hundreds of separate network IP's.

You mentioned a 'cloud' based server. So for example, on AWS/ec2, one should be using an EC2 Security Group to allow some IP's or Admin network(s) and deny the rest. Most providers have similar methods.

Point is (and in addition to answers provided): RDP would be my choice, but nothings perfect. It becomes even more imperfect if you are not blocking unwanted networks.

B. Shea
  • 141
  • 4
2

On RDP you can perform a MiTM attack and then all traffic from RDP server to the RDP client and back will pass through our MiTM system. That is why it is not considered secure.

As for Teamviewer, you must put trust in a 3rd party, which is not the option many would go for.

As for a best-case scenario, you should setup your own certificate-based VPN.

Overmind
  • 8,779
  • 3
  • 19
  • 28
  • 35
    RDP uses certificates to authenticate the server. You can only MiTM attack that, if you accept invalid certificates! – Josef Aug 09 '16 at 12:43
  • 1
    So it sounds like certificate pinning or just using RDP over a VPN (which is the prescribed method of TeamViewer as well, no?) should be safe? – Nate Diamond Aug 09 '16 at 15:44
  • 1
    @Josef How scary is the warning about the invalid certificate, and are most users going to recognize it and do something or accept it anyway? – jpmc26 Aug 09 '16 at 16:39
  • 12
    If you configure the group policies right and have a internal CA which signed the certificates, there is no message to accept, it just works with valid certificates and doesn't work with others. That's how this is done in a company. – Josef Aug 09 '16 at 16:55