, , , , , , , , , , , , ,

Being able to access a desktop from another machine over the network (or the Internet) is pretty cool stuff, and as it turns out, the remote desktop thing might be the easiest and most attractive way of doing naughty things with a target’s computer, so it’s worth a post here explaining how risky it is to allow on a network.

VNC Basics
As far as I can determine, VNC started out as a ‘thin client’ thing, rather like the mainframe model of computing where the keyboard and monitor formed a ‘dumb terminal’ and the services were handled by a central computing system. The ‘dumb terminal’ and the ‘mainframe’ in this case are virtual – they’re software applications that communicate desktop events over the Frame Buffer Protocol. If a mouse cursor moves on one machine, that update will be sent to the other, so both machines should see exactly the same desktop.

Remember there is only a single desktop active throughout this session, and those sitting at the client and server both have control of it (unless the server’s configured otherwise).

VNC in Action
Well, I said remote desktops are pretty cool, and I just had to experiment with this again. The setup is really straightforward, and very similar to that in the browser exploitation demo I did last week. We have a router, a machine running the VNC server and another machine functioning as the VNC client. Anything with a VNC client should be able to get a remote desktop session with a VNC server, regardless of the OS it’s installed on.
Hopefully the netbook has something (other than Metasploit) that’s also capable of breaking into a remote desktop session – I’m curious to see how easy this is in practice.


For this I used the vino VNC server and the Vinagre client. In reality it shouldn’t matter which programs are used – any VNC client should function with any VNC service. Configuring the server is remarkably easy. Just don’t run this in the root account or with admin privileges. In the terminal, we type:

This will open up the GUI.


Unfortunately there are a couple of problems here. VNC passwords are truncated at eight characters, and the option to configure UPnP router for port forwarding might allow remote logins. Together this would make the remote desktop service easy to bruteforce from outside the network. In theory, at least.

With the server running, we can now go to the client machine, open the VNC client and start a session. If the IP addresses are unknown for whatever reason, we can simply use ifconfig and netdiscover to find them.


Those doing this in Linux Mint for the first time might get ‘connection closed’ when they attempt to connect. The following entry might be needed in Startup Applications on the server:
Name: Shared Desktop
Command: /usr/lib/vino/vino-server --sm-disable

Then reboot the machine and try connecting again.


And hopefully we’ll get a session, with the remote desktop appearing within the VNC viewer’s window. And before anyone asks, yes, I’ve also seen this deployed on a huge scale (well over 10,000 users) and work almost flawlessly over the Internet.

Traffic Analysis
Since the communication is between the applications themselves, I thought it would be worth running Wireshark before starting the remote desktop session to capture the authentication and session packets straight from the network interface before they reached the application layer.

The client makes the initial request and the server replies with the RFB version it uses. The server then tells the client the security and authentication methods it supports, and the client chooses from them. There appears to be a lot of authentication happening while the session was active after the login, but nowhere was the password visible in plaintext.

The Important Bit
After the session’s done, we stand down by unchecking the desktop sharing option in Vino, disabling the entry we just added in the Startup Applications list, and blocking port 5900 (incoming and outgoing) on the firewall if possible. If the router’s firewall doesn’t provide that option, it’s worth looking at host-based options such as iptables and ufw/gufw.

Security Implications
VNC is so easy to set up for Windows machines that scammers, often impersonating Microsoft tech support, are sometimes able to socially engineer people into installing and configuring a Remote Desktop service. Very little effort is required at either end when it works.

But social engineering is a cop-out. More interesting is the idea of bruteforcing an already running VNC server on a prize target, or finding an exploit that establishes a session through some other method. Since this is running on my own network, I can try doing it the quick and dirty way.
Here I’ve installed a dictionary attack program, just to see how effectively this could be done from a low-powered netbook, and whether there were any protections against it, such as a time delay between login attempts – very important because a poorly secured VNC server is essentially a backdoor.

I set ‘client12’ as the VNC session password, something we could realistically expect would be used. Next I ran a dictionary attack against the server, which, because of my crappy engineering skills or because the server forces a delay between login attempts, was painfully slow. I did check the attack actually was in progress using netstat, then went back to Wireshark to see the dictionary attack program and the server repeating the negotiation, challenge and response cycle for every attempt.


What next? Possibly finding another vulnerability in an existing service, or using a backdoor to set one up. As we can see, there are several types of exploit for various implementations of VNC, with some merely bypassing authentication altogether:


Using these could be as simple as the Penetration Testing Lab’s two-stage example, where the author fingerprinted with nmap then launched the relevant Metasploit module. It’s worth mentioning here that an SMB exploit, which the UWN Thesis blog has incidentally just done a post on, can also get us a remote desktop session without a server installed on the target.

We’d expect to see VNC servers as one of the basic components in remote access malware that’s marketed to criminals and government agencies, alongside something that will send the target’s IP address to a server whenever the system boots, and probably some extra code to hide the process.