Security Basics mailing list archives
RE: VNC Security
From: "Conlan Adams" <conlan () midwesteyebanks org>
Date: Tue, 26 Apr 2005 12:26:09 -0400
Sorry to beat a dead horse, but I feel there are better solutions to running VNC over the public internet in almost all cases. Can VNC be made "secure enough" for the public internet? Maybe, but it can be made much more secure with less work for the user. In all of the following scenarios we want to assume that having the user do any real configuration is a "Bad Thing"(tm). Talking the user through more than a few clicks always gets difficult. Requiring the user do something after your done is even worse. Often they wont, there motivation is gone once the issue they called you for is fixed. Scenario A is assuming the following points. 1. It is not a single user who is at a location by themselves. If this is the case in your scenario, go to Scenario B 2. Rarely does the user have, or want access to the firewall controls where there is more than one user in a network environment. 3. You have a server at the location. Rarely is there more than one networked user at a location and there is no server present. 4. You can trust your users not to maliciously attack your network from the inside via sniffing, or other attacks. If you cannot trust your users, you have a much larger security concern, and probably need to arrange for a "Human Resources Solution" for those staff members. Just install SSH via Cygwin or otherwise on a server or designate a workstation computer as the server, and use it for remote access. Disable password based logins, and generate keys for yourself and others. Port forward SSH out the firewall, and turn on VNC inside the firewall for internal users. Use the port tunneling in SSH to connect to your users, or just VNC into the machine that has SSH on it and VNC to additional machines from there. Total user work required, none. Scenario B is assuming the following points 1. A single remote user with a software firewall. Perhaps a laptop user traveling 2. This is a remote worker for an established office, not a one person organization. If this is not the case, go to Scenario C. I would suggest a VPN in this situation, even PPTP or L2TP. The user can connect in from remote, on a pre-setup connection that doesn't make use of the software firewall. Once they are connected you can easily connect to them and take over their machine and do what needs to be done. Total user work required, to double click a vpn connection. Scenario C is assuming the following points. 1. A single remote user with a software firewall, who doesn't belong to a larger corporation, a one person organization. You're supporting them as a contractor. At your location, setup a SSH server available on the internet with password logins disabled and keys for various users who need your support. On their machine a PuTTY configuration (or similar client) with all the port forwards setup and the connection details configured. Have the client connect initiate the putty connection (as simple as a double click) which forwards the port for VNC to the SSH server on a predestined port. Connect to this port and take over their machine. Total user work required, double clicking on a PuTTY connection. All of these require less actual work on the part of the user (GOOD THING) and are much more secure. Can you "safely" run VNC over the public internet? Sure. Do you want to? I know I don't. In my book there are better ways to do it. Conlan Adams -----Original Message----- From: Andy Bruce - softwareAB [mailto:andy () softwareab net] Sent: Monday, April 25, 2005 7:47 PM To: Mike Miller Cc: Steve Bostedor; security-basics () securityfocus com; VNC List Subject: Re: VNC Security First--I believe we're talking apples and oranges. VNC is not an appropriate solution for a true corporate network unless a firewall and a secure link is available (and even then is dodgy). My scenario is this: a. Random user in cyberspace has a problem. b. User installs VNC under direction of tech support: i. strong password ii. not installed as service iii. temporary port forwarding only c. User allows remote person to login, generally for 20-30 mins. d. User stops VNC server process and disables port forwarding My point was that, for all practical purposes, this scenario has zero risk. Let's talk about what happens if an attacker does happen to be watching data packets and does manage to break the password during that session: 1. The attacker is still subject to limitations of the VNC data protocol. For the attacker to gain real hidden control, he would have to have the VNC server software accept his own third-party program via remote copy and execute. 2. Unless the attacker had that type of attack, he would have access only to mucking with the primary (zero) desktop in Windows, so no danger of a hidden desktop there. (VNC simply doesn't support anything other than primary desktop, as my remote users with Fast User Switching have found to their chagrin.) To take control of the situation, the hijacker would have to send keyboard/mouse commands to that desktop to activate some process during the hijack process. Therefore, I most certainly would notice it. The only exception is if the attacker simply mucked with the Windows registry, perhaps to navigate to a tainted Web site upon next login. That's a larger issue than whether VNC is secure. 3. As stated above, I explicitly instruct my users not to install VNC as a service, and then to stop the server process when we're done (and then turn off port forwarding). So, even if the attacker did get into the machine and cause a password reset--it won't help. The VNC service won't be running when the user next boots the machine. And if it was running, the port forwarding and Windows firewall would prevent the attacker from getting access to it again. Only Wez and the user community can let me know if there are any security flaws in VNC that allow the remote system to execute physical programs simply based on passed data packets commands. I was under the impression that the only way that the VNC client executes programs is by sending keystrokes/mouse clicks to the remote system. (In other words, no type of "exec" function built into the protocol.) Therefore, the VNC server itself isn't ever executing any software via API calls--instead, VNC simply passes keyboard/mouse input to the OS and it's the OS that's does the execution. And the user is watching the desktop on at least one side of the connection. So--while the effort to trap/break in to a VNC server may be well worth the effort for a corporate network with access to a rich mine of data, in my example it doesn't apply. Andy Mike Miller wrote:
On Tue, 19 Apr 2005, Andy Bruce - softwareAB wrote:I have to agree with Steve that this is, for all practical purposes, a non-existent security risk. The only things that could go wrong: a. "Somebody" is sniffing the packet stream while the VNC passwords are being exchanged, and, during that 20 minute interchange, cracks the password and logs onto the VNC server. Of course, we would notice
this problem on both ends!I don't know if it is possible to crack the VNC password, but I don't agree that you would necessarily notice this on both ends. If the attacker were to log into the session when you weren't using it, he could then make some changes to your system (for Windows) that would allow him more access to your machine later. If you were using Windows he could start up another VNC desktop that you might not notice, and he could use a different password if he wanted to (by copying the vnc password file, changing the password, and copying it back). I hope that it is hard to crack the passwords. I think it is hard to do it but I'd like to hear more about that. Mike _______________________________________________ VNC-List mailing list VNC-List () realvnc com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Current thread:
- RE: VNC Security, (continued)
- RE: VNC Security Joshua Berry (Apr 20)
- RE: VNC Security Steve Bostedor (Apr 20)
- Re: VNC Security Alexander Bolante (Apr 20)
- RE: VNC Security Steve Bostedor (Apr 20)
- RE: VNC Security Steve Bostedor (Apr 20)
- RE: VNC Security Joshua Berry (Apr 20)
- RE: VNC Security Steve Bostedor (Apr 20)
- RE: VNC Security Joshua Berry (Apr 21)
- RE: VNC Security Joshua Berry (Apr 21)
- Re: VNC Security Alexandre Zglav (Apr 21)
- RE: VNC Security Conlan Adams (Apr 26)
- Re: VNC Security Andy Bruce - softwareAB (Apr 26)
- RE: VNC Security Conlan Adams (Apr 26)
- Re: VNC Security Andy Bruce - softwareAB (Apr 26)
- RE: VNC Security Alexandre Zglav (Apr 27)