When I try to connect to a remote desktop, a message appears which says something like "Make sure you trust this PC, connecting to untrusted computer might harm your PC". Why would it harm my PC? I can understand that if I am sharing local resources or something like that, but if I am just connecting to a remote desktop how would that harm my computer? isn't it like sandboxed? how will the remote desktop access my PC?
-
Is the remote control bidirectional, maybe? – copy Jul 07 '13 at 01:38
-
3I think you got your terminology wrong. The client is the local computer you're sitting in front of. The server or *host* is the remote computer you're connecting to. – CodesInChaos Jul 07 '13 at 20:35
-
@CodesInChaos Well, I suck in English and in Computers, what do you expect :D thanks mate – Jul 07 '13 at 22:29
-
But logically, I am the host, because it is my PC and I am hosting the remote desktop.. this is how I thought of it :( – Jul 07 '13 at 22:33
-
2No. You're not _hosting_ anything, but you are _controlling_ the remote host. All you do is have a "client software" establish a connection to a remote host (the RDP server), one that you see its desktop and can remotely control through your RDP client on your local computer. This nomenclature is important for exactly this issue we're having here - to avoid confusion and ambiguity. None of us here chose it, but if we're to understand each other, we need to use same terminology, and the industry accepted one is usually the easiest way to avoid such problems. ;) – TildalWave Jul 07 '13 at 22:44
3 Answers
This is a good question! First a disclaimer that I'm not really qualified to give a complete answer, as I have so far been fairly good at avoiding RDP security issues in untrusted environments. I do use both RDP clients and servers though, but only ever on trusted hosts. That said, I do have a few thoughts why we're seeing such warnings;
It would be fairly reasonable to assume that the majority of security risks would be undertaken by running a RDP server (what Microsoft calls Remote Desktop Services), and there were some quite infamous exploits of it in the past, for example vulnerability to the pass-the-hash or MiTM attacks on non-encrypted connections. We probably still all remember disabling Remote Assistance and removing associated port exceptions in firewalls as one of the first things we did upon installing Windows XP, for example. But risks involved in using a RDP client (or Remote Desktop Connection in Microsoft's terminology) don't seem so self-obvious.
For a more in-depth explanation on terminology used and distinction between a RDP client and a RDP server, please see the update at the end of my answer. But to make things clearer, this is the warning dialog that OP is talking about in the question:
While I haven't been able to find documentation on any recent self-propagating exploits (i.e. viruses, trojans, or worms) taking advantage of Remote Desktop Connections through the use of the updated RDP protocol clients, especially those using TLS, there are still some risks involved with connecting to untrusted RDP servers:
User activity tracking and keylogging: In essence, untrusted RDP server could log all your activity on the server, including websites you browse to, files you download, documents you accessed and were changing, passwords you entered to access remote services through the RDP server, basically keep track of your complete user session.
Infection of client through remote hosted files: Any files you download from the server hosting a RDP session could be tampered with, or infected with malware. You could falsely assume trust in any of these files, thinking since you put them there during your previous RDP session that they weren't tampered with or infected in the meantime, transfer them to your RDP client and open/execute/...
Man-in-the-middle: Similar to user activity tracking, only this time the attacker is active on the RDP server you connect to and is listening in on your RDP client to RDP server connection, RDP server to remote LAN / WAN connections, or possibly both. On top of being able to inspect contents of exchanged network packets, man-in-the-middle is also able to change their contents. The RDP session can be encrypted using TLS, effectively preventing eavesdropping on it, but that isn't necessarily the case with where else you connect to (remote LAN or WAN) using the RDP server.
Social engineering attacks: You could be a victim of a social engineering attack where the attacker gains your trust under false pretense, and cons you into entering a RDP server address that you believe can be trusted in your RDP client while establishing a new session, but the address you entered is actually of attacker's choosing. The attacker could host a RDP server on that address for the sole purpose of recording your login credentials for another, real RDP server you intended to connect to. Thanks to @emtunc for reminding me of this threat!
Honestly, I've probably left out a lot of other possibilities to abuse users trust in the RDP server they're establishing a session with, especially when RDP server can not be trusted but the user assumes this trust anyway, failing to see the potential danger in doing so. But these four example attack vectors should be hopefully enough to demonstrate that there is a clear need for such warnings you're receiving.
Edit to add: Seeing there's some confusion regarding terminology used in my and other answers (which we all use in same way as far as I can tell), I want to clear things up which of the two ends involved in a RDP session is considered a client, and which a server (or a host). These are the excerpts from Wikipedia, to exclude any biased and opinion based explanation:
Wikipedia on Client (computing): A client is a piece of computer hardware or software that accesses a service made available by a server. The server is often (but not always) on another computer system, in which case the client accesses the service by way of a network. The term applies to programs or devices that are part of a client–server model
A client is a computer program that, as part of its operation, relies on sending a request to another computer program (which may or may not be located on another computer). For example, web browsers are clients that connect to web servers and retrieve web pages for display. Email clients retrieve email from mail servers. Online chat uses a variety of clients, which vary depending on the chat protocol being used. Multiplayer video games or online video games may run as a client on each computer. The term "client" may also be applied to computers or devices that run the client software or users that use the client software.
Wikipedia on Server (computing): A server is a system (software and suitable computer hardware) that responds to requests across a computer network to provide, or help to provide, a network service. Servers can be run on a dedicated computer, which is also often referred to as "the server", but many networked computers are capable of hosting servers. In many cases, a computer can provide several services and have several servers running.
Servers operate within a client-server architecture, servers are computer programs running to serve the requests of other programs, the clients. Thus, the server performs some task on behalf of clients. The clients typically connect to the server through the network but may run on the same computer. In the context of Internet Protocol (IP) networking, a server is a program that operates as a socket listener.
To put this into perspective how this terminology applies to a RDP session, I'm also including excerpts from the previously linked RDP server (Remote Desktop Services) and RDP client (Remote Desktop Connection) Wikipedia pages:
Remote Desktop Connection (RDC, also called Remote Desktop, formerly known as Microsoft Terminal Services Client, or mstsc) is the client application for Remote Desktop Services. It allows a user to remotely log in to a networked computer running the terminal services server. RDC presents the desktop interface (or application GUI) of the remote system, as if it were accessed locally.
The server component of Remote Desktop Services is Terminal Server (termdd.sys), which listens on TCP port 3389. When an RDP client connects to this port, it is tagged with a unique SessionID and associated with a freshly spawned console session (Session 0, keyboard, mouse and character mode UI only). The login subsystem (winlogon.exe) and the GDI graphics subsystem is then initiated, which handles the job of authenticating the user and presenting the GUI.
And to put it visually, Remote Desktop Connection client on Windows 8 looks like this before establishing a RDP session:
- 10,801
- 11
- 46
- 85
-
I also recommend reading SearchSecurity's [Is RDP secure? Guide to Microsoft RDP security, secure remote access](http://searchsecurity.techtarget.com/guides/Is-RDP-secure-Guide-to-Microsoft-RDP-security-secure-remote-access), and if you're interested in securing the server side of a RDP connection also the checklist to go through in [this answer](http://security.stackexchange.com/a/109/20074) to the question [Is it secure to connect to a remote Windows Server using Remote Desktop only?](http://security.stackexchange.com/q/102/20074) on [security.SE]. – TildalWave Jul 07 '13 at 02:36
-
2Your answer is ok, but the problem it is not really answering the part about how will it affect the host pc, you are talking about security in general when it comes to RDP.. I want only the part about how will it affect my pc (the host) – Jul 07 '13 at 16:22
-
@HaLaBi - I was limiting my answer explicitly to how a remote RDP server (the one you connect to using Remote Desktop Connection, and where you get the warning message on as described in your question) might infect a RDP client. I realize that this client-server terminology might not be apparent and cause some confusion, but that's the _industry-wide naming convention_. What I'm saying is, I've actually described (some of) possible ways of your client PC being affected through the RDP connection, which you say in your comment that I did the other way around. I'm a fair bit confused now :? – TildalWave Jul 07 '13 at 17:19
-
I was talking about how a HOST would be harmed.. a host in this case is the PC I am using to connect to a remote desktop, I was not talking about how the remote machine will be harmed. – Jul 07 '13 at 19:35
-
@HaLaBi - Yes, that's what I was talking about also, that's what my answer is all about and I thought I made a clear distinction between the two in my introduction. It's also what all other answers that were posted until now (and comments) here are discussing. – TildalWave Jul 07 '13 at 19:38
-
-
@HaLaBi - Yes, I know that you didn't mean the "host", but the latter part of your previous comment that does describe what you are asking in the question is what I was answering. Again - my answer is about the risks of connecting your PC (the client) to a remote RDP host (the server) that might not be trusted. So it is you that sees the Remote Desktop window and controls the remote host through it. This is what my and both other answers are about. It is also the only side of a RDP session that security warnings you describe actually make sense. See our answers on why. ;) – TildalWave Jul 07 '13 at 22:36
-
@emtunc - Yes, credentials theft by RDP session hijacking would fall in the MiTM category, but hosting a fake RDP server for that purpose would probably be easiest to achieve by means of social engineering attack. That's another category that I didn't think of at the time of writing, but the point was to show the reasons behind the particular warning message OP describes. The warning message displayed is actually: _"This remote connection could harm your computer. Make sure that you recognize the remote computer before you connect."_ so it's directly covered in it. But cheers, you're right! ;) – TildalWave Jul 08 '13 at 23:01
-
@TidalWave Have you ever heard of any defects in the RDP client its self that might allow the malicious server to execute code on the client machine? I seem to recall a knowledge base article about this around 2012, but I have no idea if it was ever actually exploited in the wild. – trognanders Dec 01 '14 at 09:54
A basic RDP client will, by default, share the clipboard through the RDP session (because it is very convenient). This alone allows the remote server to obtain a copy of everything you select and "copy" on your client, be they text excerpts, files... which is a glaring security issue when the remote host is hostile. Similarly, an hostile server may inject hostile code in the copy&paste mechanism: if you do a copy&paste of a file from a directory on your desktop system to another directory on your desktop system, then the hostile server may intercept the copy and alter the file in transit, thus injecting a virus (if the file is executable in some way).
The theory is that an hostile server cannot do anything bad to the client if all of the following are true:
- There is no shared resource between client and server.
- The server won't get any input (such as key presses and mouse movements) unless the human user explicitly chooses so.
- The RDP client code dutifully validates all data from the server and has no vulnerability such as a buffer overflow in its handling of the protocol messages obtained from the server.
Betting that any of these three conditions is met, let alone that all three are met, would strike me as rather risky...
Even the much simpler situation of doing a text-only SSH connection to an untrusted server is possibly dangerous.
A remote desktop connection allows someone else to fully access a computer. From the other side, the accessed computer could try to send any kind of suspicious and/or malicious data packages using the established "trusted" remote desktop connection.
In malware analysis (for example), one would never connect to an untrusted and potentially infected system without taking the appropriate precautions like using a VM which can be deleted afterwards when it becomes apparent that the infected system you are analyzing is indeed infected and spreads it's nasty stuff using any available network connection. In your case, that would be the remote desktop connection you're about to "trust" when clicking that OK button.
And that's the reason why it reads you need to make sure you are connecting to a trusted computer.
Always keep in mind that a remote desktop connection is - in it's core - nothing else than a bi-directional network connection between two computers. Therefore, all network-related risks are relevant here.
For what it's worth, that message could as well say: "are you sure the other system is not compromised and that the person using the other system has no malicious intents?"
You can't imagine how many non-benign packets I've seen transported over remote desktop connections while I analyzed systems. Those would have instantly infected your system and in most cases you probably wouldn't notice it before harm is done. Trust me, that's the last thing you want to happen...
The message may raise an eyebrow when first reading it, but as soon as you realize what you are about to do (create a "trusted" network connection to a remote system), the warning sure makes sense.
EDIT
In case you missed it: on June 11, 2013, Microsoft had to call out a particularly important patch (MS12-037) which addressed (among other things) a critical flaw in the remote desktop protocol of all Windows operating systems (RDP). If you want to be as secure as possible, make sure you've applied the latest updates and security patches to your system.
- 1,286
- 2
- 14
- 41
-
1RDP is a client-server type protocol built on top of TCP transport layer protocol. While it's technically correct that this connection is bidirectional, the software stack (the RDP protocol) on each side responds to different set of commands they listen to using TCP sockets. This is not much different than how a web server and a web client (a browser) communicate using HTTP protocol on top of TCP. In a nutshell, the client will only respond to a fairly limited subset of commands and can not be equated with what commands the server is capable of interpreting and executing. – TildalWave Jul 07 '13 at 06:24
-
@TidalWave Thanks, I already know all that (part of my job to know it). Also, it's not as if my reply states that you could be connecting to a botnet's command-and-control server with your pants down. ;) I guess we both agree that remote desktop connections received several security fixes in recent months (and years) that make it *"unlikely"* for anything bad to actually happen, but OP asked why the message is shown and I think the reason can be found in both our answers. Talking protocols and packets: I hope you know the badness resides in exploited details and not the command-set, don't you? – e-sushi Jul 07 '13 at 06:40
-
1Well yes I guess we both agree in two different styles, but I just wanted to point out the difference in clients and servers in a RDP connection, something that was so far missing in both our answers. This is why this question is interesting, because we're usually all well aware of risks of running the server part, but be rarely hear about the risks or simply connecting a client to such server. Of course, the HTTP client security is much discussed ever since the browsers are capable of executing JavaScript, Flash,... But for RDP clients, it's even difficult to find proper VA documentation. :? – TildalWave Jul 07 '13 at 06:50
-
@TildalWave Short reminder: back in the days, the “Morto” worm used several well-known vulnerabilities in Microsoft operating systems (specifically the Windows Remote Desktop Protocol) to spread malicious code from host to host over the Internet and local networks. Based on the experience, security professionals change the default RDP port. Also, not so long ago (March 2012) Microsoft’s Patch Tuesday addressed two critical Microsoft Remote Desktop Protocol (RDP) security vulnerabilities that could be exploited by attackers to take control over and crash a Windows system. Trust RDP? Not really. – e-sushi Jul 07 '13 at 06:51
-
@TidalWave (1) I type too slow. Your comment came quicker. ;) (2) Too bad this isn't a forum. I would love to dive into a constructive discussion related to RDP protocol (securing and best-practice) one of these days. (3) Giving you a +1 on your answer to show I agree that - even when styles differ - we both think along the same line. – e-sushi Jul 07 '13 at 06:54
-
Those last two patches you mention were addressing possible unauthenticated client exploits of RDP servers. Same goes for `Win32/Morto.A` spreading by compromising administrator passwords for RDP connections. RDP clients simply don't respond to these exploits same as servers do, but it is true that default Windows installations came with both server and client software installed and enabled, and many users didn't disable the server. Still, I think we should limit our answers to this question's scope - RDP client security. ;) – TildalWave Jul 07 '13 at 07:06
-
About your last comment's point #2 - stop by our [DMZ](http://chat.stackexchange.com/rooms/151/the-dmz) chat room. Anything goes there, sometimes even constructive discussions :) Oh, and ditto on #3 – TildalWave Jul 07 '13 at 07:07
-
1@TildalWave Added an edit containing info about MS12-037, which includes RDP security patch - released June 11, 2013. When combining all information in both our answers, we should have wrapped up an nice little package related to the security question of OP. Now, I'll bookmark that DMZ chat room - got some work on my desk. Nice meeting you - cya around. – e-sushi Jul 07 '13 at 07:32