The security of remote tech support (ultravnc sc or x11vnc with wrapper script)

Well, I’ve got a nice way of doing “easy” one click (or one cut and paste) light desktop support for windows or linux, one uses ultravnc sc, the other uses x11vnc with a special wrapper script. So, what security flaws are there in this process? Well, for starters, I see the biggest vulnerability for the computer running the listening vncviewer (because it HAS to be available to the outside world.) That means the tech support desk must keep on top of vncviewer updates and keep the service turned off when not expecting a client connection. The other question that comes to mind is encryption though….

There are ways to encrypt ultravnc sc and x11vnc, the ultravnc sc would probably be a bit more straightforward with the dsm encryption plugin, however the x11vnc encryption, as best as I can see would have to be through a ssh tunnel. Which might not be the best (ssh tunnel would require a login on the remote machine, or a user from the remote machine to log on to the support machine…) either one of those opens up more worms than it MIGHT be worth. Why would we be concerned about encryption..? If it were a static vnc setup, with a server available most of the time, we would have password authentication and wouldn’t want someone snooping our password. SSH encryption would prevent that. However, that’s not the model that the remote tech support “single click” approach uses….

In this case the server initiates the connection to a hard coded viewer. That session could be eavesdropped on I suppose since it’s in the clear, but I don’t see it being of much value as most mitm attacks are geared at pulling text out of login sessions, text out of web page downloads (hijack domains by substituting text that’s in the clear…) It’s not obvious to me that the framebuffer binary screen refreshes could be snooped as easily, or…. in this case, what an attacker could actually do with the stream of data. Usually, such things are used to gain access to the machine, but in this case, the server goes away after the connection, so there’s no advantage to be gained there.

I hope at some point to sit down and look at what “tools” there might be to view vnc sessions and look at what they’re geared towards. The last I saw though, password information (of the vnc server login) was the goal and I don’t know that I’ll find anything otherwise. So, that angle of the security of the plain text vnc is still an open question, but I’m doubtful that this setup would be a great risk. (Plain text connections to a password protected vnc server ARE a greater risk… if you’re setting up a vncserver for permanent “outside world” accessibility, encrypt connections to it somehow.)

The worst case there that I see is that someone can eavesdrop on the support session by viewing it. (Much the same way jpg’s can be displayed from a hijacked browsing stream?) Maybe keystrokes from the client could be parsed, but with the tools I just looked at, there aren’t *easy* ways to do it, like there are easy ways to capture say, an email login over pop3….

It looks as though the x11vnc writer is looking at integrating stunnel ssl encryption in a future release, that MIGHT be a great answer to simplify encrypting the linux remote tech support connection, but shared libraries might get in the way of wide-compatibility.

As for the wrapper script, that’s the achilles heel in the linux version of this. I think, it would be possible for someone to alter the $REMOTELISTENER machine name on the fly and hijack a session that way. Of course, they could also hijack the initial wget call and substitute some other file in place of the script. Of course, I would think for someone to take that effort, they would be intent on targetting you specifically. (given that it’s a text string I wonder if that could be substituted in a binary download of the ultravnc sc as well? There it would probably have to be the same length as the original…)

As I think about the script there may be ways to improve the error checking on that to make it harder for such a hijack to happen. I think the chances of someone trying that are probably low and would indicate a TARGETTED interest in monitoring/hijacking a specific persons connection through the scripted run.

   Send article as PDF   

Similar Posts