Slashdot Mirror

← Back to Stories (view on slashdot.org)

Critical Flaw Found in VNC 4.1

Posted by ryuzaki0 on from the public-desktops dept.

jblobz writes "IntelliAdmin has discovered a critical flaw that allows an attacker to control any machine running VNC 4.1. The flaw grants access without the attacker obtaining a password. The details of the vulnerability have not been released, but their website has a proof of concept that allows you to test your own VNC installation for the vulnerability"

46 of 175 comments (clear)

  1. SSH by Anonymous Coward · · Score: 5, Insightful

    You should tunnel unencrypted services like VNC over SSH anyway.

    1. Re:SSH by AmigaAvenger · · Score: 2, Informative

      maybe you haven't used ssh before, but when you tunnel stuff over ssh you no longer even care if vnc has a password! the ssh tunnel drops you behind the firewall or directly on the console of the machine, all traffic goes over ssh, which means you already have logged in with a valid username/password.

    2. Re:SSH by Anonymous Coward · · Score: 2, Insightful

      Gah, pay attention.

      The parent was saying that the problem was not with the lack of encryption, it was a problem with the authentication. He's not saying that SSH wouldn't solve the problem, simply that the problem would not be solved by SSH's encryption like the original poster implied, but its extra layer of authentication which is not affected by this vulnerability.

    3. Re:SSH by merryberry · · Score: 2, Informative

      Windows remote desktop suffers from very weak authentication. The best solution to this VNC flaw and using remote machines in general is to use a VPN to ensure that authentication is managed with public key cryptography, with all data thereafter being encrypted with symmetric keys. It also means it's so much simpler to run different services without having to create separate SSH tunnels. http://openvpn.net/ has a great solution working on all platforms.

    4. Re:SSH by riffer · · Score: 2, Informative
      You are confusing interactive SSH logins with VNC logins. Your message is, sadly, not informative and in fact misleading.

      Tunneling a protocol over SSH does not eliminate the need to authenticate on that protocol! The very nature of tunneling means whatever protocol is carried down the tunnel is unmodified

      Tunneling VNC over SSH simply means you establish a secure shell connection and do port forwarding between your target host and your client. Your client forwards connections to the localhost on a specified port (say, 5900) through the SSH connection to the remote host. So the traffic is encrypted the entire way, but unencrypted once it hits the remote host.

      So here's a simple outline of the steps to do:

      • Let's say you are using a host named "Guido" and you want to securely VNC into a host named "Barbarella"
      • Establish an SSH connection to Barbarella from Guido, enabling port forwarding.
        Let's say you decide to forward connections to 3145 on localhost (Guido, in this case since he's the system you are connecting from) to port 5900 on Barbarella (our target).
      • Bring up your favorite VNC client software on Guido and connect it to "127.0.0.1:3145"
      • The local SSH client is listening on port 3145 on the localhost (Guido) and detects the connection attempt.
      • Local SSH client on Guido forwards all the data it's getting from the 127.0.0.1:3145 connection down the encrypted connection on port 22 to the SSH server on Barbarella. This data is identified differently than standard SSH traffic (i.e. interactive keyboard traffic)
      • SSH server on Barbarella takes the forwarded traffic from Guido and sends it to port 5900 on 127.0.0.1 (in this case, Barbarella)
      • The VNC server on Barbarella detects an incoming connection and responds accordingly
      • The SSH server on Barbarella takes the response(s) from the VNC server and forwards them back down the encrypted pipe to the client (Guido)
      • The SSH client on Guido takes the forwarded VNC traffic from Barbarella and sends it to the local VNC client
      • Lather, rinse, repeat.
      • Profit!

      This same procedure is used for any kind of protocol you want to forward over SSH. Note that this is NOT the same thing as the secure versions of some protocols that have been released (i.e. IMAPS, POPS and so-on). Those are modified versions of established protocols where encryption is written both into the protocol standard and the actual software. Most VNC servers do not have built-in encryption.

      Note also that some VNC server solutions (such as UltraVNC) do support encryption from the client to server. UltraVNC does it with a plugin architecture, though it's not exactly perfect.

      Other important things to note, and to clear-up the rampant confusion in this thread:

      • VNC authentication is not plain text. However, the encryption used is fairly weak. It can be decrypted with little effort if the authentication between a VNC server and client is sniffed. Thus, tunneling the VNC connection over SSH defeats that method. However, the password is stored locally on the server in equally weak form. If a person gets ahold of the encrypted form of the server password, they can decrypt it instantly using one of several different vnc password cracking tools (and no, it's not brute force)
      • I would not blindly trust the IntelliAdmin website's "proof of conecpt" webpage. They are not publishing this supposed exploit, nor the source to their testing page. So there's no way of knowing what they are doing. Additionally, you are assuming that they (or someone in their organization) will not abuse this access.
      • UltraVNC has support for doing Microsoft NTLM authentication, which despite what some may think is more secure than the default VNC authentication scheme.
      • Security is about layers. SSH tunnels are great. But you should still use a password on your VNC server and no, you should not tell everyone on Slashdot your password is "password". Even better, keep the VNC server turned off when you are not going to need it (hint: cron can be useful to down the server during the hours you are usually at home sleeping)

      Oh, and my CISSP number is 81554.

      --
      In the darkness of future past, The magician longs to see. One chants between two worlds, "Fire, walk with me!"
  2. Not enough details by Raleel · · Score: 2, Insightful

    It says that the VNC port has to be accessible from the internet. Normally, I don't do this. I run it so that you can only connect from localhost and ssh tunnel through. It doesn't detail if it would affect an installation like this, but I doubt it.

    --
    -- Who is the bigger fool? The fool or the fool who follows him? --
    1. Re:Not enough details by GooberToo · · Score: 2, Informative

      You missed the point. He's saying no one can reach his box unless they have SSH'd into hix box first. That means he's not likely at risk unless someone has gotton past SSH first and/or already have a local account.

    2. Re:Not enough details by micheas · · Score: 2, Insightful
      Your system is affected just as much as any other. Unless the machine is single-user, all other users on the system will be able to exploit VNC.


      This is wrong. A system that only accepts connections via the loopback interface is only subject to privilege escalation attacks. This is a far cry from a remote compromise. In a system with untrusted users this is still a big deal but it is far less problematic than remote compromise.

      System administrators should understand that binding a service to loopback is not a valid means of sandboxing insecure software.

      True, but it is a valid way of reducing risk. The mantra is defense in depth. If your VNC is only vulnerable to people with local access it is has a greater chance of not being broken into than if it is vulnerable to everyone on the Internet.

      If your VNC is bound to the loopback and you are logging to a remote host you have a real chance of finding out who is guilty of privilege escalation. If it is on a public facing interface you have a lot more work trying to identify the guilty party.
      --
      Work bio at MMWD
  3. Yikes! by timeOday · · Score: 5, Insightful

    Surely inspection of the vulnerability test will betray the flaw to attackers?

    1. Re:Yikes! by alexmipego · · Score: 2, Interesting

      I was thinking the exact same thing. Since they allow you to test that, an hacker can setup a machine with a vunerable version and use a sniffer to see what the proof of concept code is doing.

      This guys will be responsible for a few server's hacking.

    2. Re:Yikes! by julesh · · Score: 4, Informative

      But isnt the slashdot crowd always for the release of exploits?

      Yes, indeed. However this isn't a release of an exploit, it is somebody saying "bring your machine, and I'll exploit it for you."

      What this means, effectively, is that anyone who is prepared to go to the effort of sniffing packets can easily figure out what's going on, but the rest of us are still in the dark. I can't use this to test the machines on my internal network because there's no way I'm going to open the VNC ports on my firewall. He may be wrong when he says on the previous article that (e.g.) TightVNC isn't vulnerable, it may be vulnerable to a slight variation of the attack that could easy be found by somebody who knew how it worked, but because he's released no details to anyone who doesn't make a large effort to understand the problem we can't know that. But be sure that there are some blackhats out there who have already tested this and understand why it works who have tried to figure out if they can make it work on another version.

      This behaviour is wrong in every way possible. Disclosure should be complete or not exist at all, IMO. Anything between is dangerous.

  4. tight vnc by bazooka_foo · · Score: 3, Interesting

    i guess tight vnc is okay??

    that is what I use

  5. SSH tunnels by ArbitraryConstant · · Score: 5, Insightful

    Like many services meant for users that can be expected to have a password, this is best tunneled through SSH. Access is controlled by a comparatively secure protocol and server. It's still best to patch (eg someone might get unpriviledged access to a machine and use this flaw to escalate the breach), but having a gateway that's more secure than any of the components behind it is nice. Even if the gateway itself has flaws from time to time.

    --
    I rarely criticize things I don't care about.
  6. Capture the packets by a_greer2005 · · Score: 4, Informative

    The hole hasnt been detailed but they have a web baced proof of concept exploit? do I need to spell it out for you? SNORT the segment while you run the test and BINGO -- Got 'em!

  7. scope of bug... by AmigaAvenger · · Score: 5, Informative

    only RealVNC is affected, which is a crappy vnc anyway. TightVnc and better yet UltraVNC are far ahead of RealVNC, neither of which are affected btw.

    1. Re:scope of bug... by petard · · Score: 3, Interesting

      only RealVNC is affected, which is a crappy vnc anyway. TightVnc and better yet UltraVNC are far ahead of RealVNC, neither of which are affected btw.

      I wouldn't assume they aren't affected by this. They very likely aren't, but it looks like this guy stumbled upon the flaw as he was implementing an independent VNC viewer from the VNC specification. It doesn't sound like he really has his mind around why RealVNC is affected, so it'd be prudent to assume that they are. (i.e. Once he understands why the attack works he may be able to produce one easily against TightVNC and UltraVNC.)

      At any rate, if you operate your VNC service in a reasonable configuration, you're safe. By "reasonable configuration" I mean listening only on 127.0.0.1 so that people have to connect via ssh or client-authenticated stunnel to get to it. VNC authentication is not safe on an untrusted connection. And you shouldn't trust your connection unless your network is so small and has such well-controlled access that you can physically inspect every device on it in <30 minutes with absolute certainty that you haven't missed any.

      --
      .sig: file not found
    2. Re:scope of bug... by pe1chl · · Score: 4, Interesting

      Our experience with *VNC has been that "better" is often subjective.
      We used the original VNC for quite a while then switched to TightVNC. It seemed "better", but on the Windows platform there were some situations where it had difficulty finding the need to redraw certain screen areas.
      (I am of course assuming that the 'poll full screen' option is not used, but limited areas of the screen are polled)
      Sometimes a click on a window bar is needed to refresh that window, sometimes it is enough to move the mouse around a little.
      The ancient version did allow you to refresh the screen by "painting" the area with the mouse cursor, but TightVNC usually refreshes an entire updated area when it is moved over by the mouse.

      However, as there still were apps which did not work entirely satisfactorily (especially when extensive use was made of tooltips), we kept looking and it seemed that UltraVNC was promising. It was installed on a few systems and it worked ok, then rolled out to a lot of systems.
      Now, problems again appear, but in other situations.
      Sometimes it delays refreshing a bit long, and shortening the timer increases the CPU usage too much.
      Using the special video driver improves things a little, but it has proven difficult to find a really well-working setup that does not have annoying lag and does not overload the system either.
      One one system it was even replaced by RealVNC because of system load issues.

      Fortunately all those servers and clients inter-operate, or else there would be a big mess by now.
      (also, we fortunately can automatically and silently install new or other versions on at least the client systems, so switching is not too hard)

      I wonder what other people's experiences are. I don't define "better" as "having more toolbar buttons" or "having more added options like file transfer", but I am still looking for a better VNC in terms of good interactive performance without overloading the server system.

    3. Re:scope of bug... by moonbender · · Score: 3, Informative

      I wouldn't assume they aren't affected, either, but the guy did test Ultra and Tight, and both weren't affected. So there. It's not in TFA, but one link away.

      --
      Switch back to Slashdot's D1 system.
  8. Specific to RealVNC 4.1. TightVNC and UltarVNC OK by McGruff · · Score: 2, Informative

    From the initial article preceding the proof of concept, TightVNC, UltarVNC and RealVNC 4.0 are not affected.

  9. Bottom Line by bogie · · Score: 5, Informative

    "I started to wonder how widespread this flaw was so I downloaded TightVNC, and UltraVNC. They are immune. Both of them reject my connection right away"

    "So it looks like a flaw is in the current RealVNC 4.1.1 authentication process. I am not going to give any clues as to what it is until I can figure it out totally, and promptly let the RealVNC team know so they can resolve the issue."

    So there you go. This is apparantly not a system-wide VNC issue and is a RealVNC 4.1.1 issue only. Submitter you suck.

    --
    If you wanna get rich, you know that payback is a bitch
  10. Re:RealVNC by grub · · Score: 2, Informative

    Answering my own question, from this link:
    I started to wonder how widespread this flaw was so I downloaded TightVNC, and UltraVNC. They are immune. Both of them reject my connection right away.
    --
    Trolling is a art,
  11. OMFG!! by LoztInSpace · · Score: 2, Funny

    OMFG! There's software that allows someone to take complete control over my machine?!?!?! Gah!! What sort of bastard would write such a hideous virus/worm thingie!??!

    (yeah - I know..it's a joke)

  12. Re:encrypted wireless? by Anonymous Coward · · Score: 2, Informative

    If WEP, then you should be very worried. If WPA then less worried (assuming your key is actually at all good). Also this only affects RealVNC (I believe). Also MAC filtering is pretty much only 'useful' to prevent people from accidentally connecting to your network (same with WEP).

  13. FC 4 vnc-server-4.1.1-10.1 tested and passed by layer3switch · · Score: 2, Interesting

    I have FC 4 2.6.16-1.2108_FC4smp kernel with some minor kernel sweak. For this test, I have activated vnc server (why need vnc when you have ssh.. who knows..*sigh*) with default config and disabled my paranoia iptable rules for this test. Also opened up port range from 5800 to 6001 (just to prove the point) from my firewall and set to port forward to VNC machine.

    I even disabled password for the account VNC display is binded to and set to no encryption for VNC.

    Nothing happened. No display, nah da, nothing.

    I have stable FC4 vnc package version 4.1.1-10.1.

    --
    "Don't let fools fool you. They are the clever ones."
    1. Re:FC 4 vnc-server-4.1.1-10.1 tested and passed by armitage_23 · · Score: 2, Informative

      Using VNC over an SSH can be much faster than XForwarding. For instance, when you have a high latency link or the application has 32-bit icons.

      Using a VNC desktop and squashing the color depth down gives a huge speed up.

      It can also help when you're moving from meeting to meeting. I leave a VNC session running with a few apps, and I can connect to it from various physical locations, even if my IP changes or I have to turn off my laptop. Try that with X forwarding.

    2. Re:FC 4 vnc-server-4.1.1-10.1 tested and passed by markdavis · · Score: 2, Interesting

      > For this test, I have activated vnc server
      > (why need vnc when you have ssh.. who knows..*sigh*)

      Um, because you can't use ssh to connect to an existing/running collection of Xserver and Xclients. Sigh.

      Inotherwords, you can't use ssh to connect to your Mom's machine in a different city and help figure out why she has trouble using/interacting with Kmail or some other GUI program. But with vncserver + vncviewer, you CAN.

      It is annoying, because what would be 1,000 times better for *ix->*ix would be an X protocol "mirrorer" that could take everything off of an already running server and mirror it to a nested Xserver on another machine. This would be many orders of magnitue faster and more accurate than VNC.

    3. Re:FC 4 vnc-server-4.1.1-10.1 tested and passed by mhesseltine · · Score: 4, Informative
      you can't use ssh to connect to your Mom's machine in a different city and help figure out why she has trouble using/interacting with Kmail or some other GUI program. But with vncserver + vncviewer, you CAN.
      You may want to look into x11vnc, which will allow you to connect to a running X session and view it using VNC. This is how I access my home machine from work when I want to check on a running GUI task at home. SSH in, run x11vnc -display :0, then connect to the tunneled VNC connection. Works great, and when I'm done, I just take down the x11vnc so it's only up and running when I need it.
      --
      Overrated / Underrated : Moderation :: Anonymous Coward : Posting
    4. Re:FC 4 vnc-server-4.1.1-10.1 tested and passed by Nazo-San · · Score: 2, Informative

      Don't forget. VNC is OS independant. I can fire up a VNC session on my linux box and use a VNC client on the box itself then leave the session open and connect to it from a windows box. Ok, via Cygwin you can pull off X, but, it is definitely not worth all that extra clutter when a simple VNC client can achieve the same purpose and is designed to do it better (remote X is really intended for a lan dumb client type setup whereas VNC can be used to add JPEG compression, decrease color depth, etc so works about as well as you can hope over the internet.)

      PS. I found a nice little client called DirectVNC which uses the DirectFB (framebuffer) to give you VNC in a console. Since this is for a server type setup, I find it handy since I can have just one X setup running essentially this way. Eg, I don't have to start X to get to the VNC session even. It strikes me that this could also be handy on some minimalistic setups such as some live discs perhaps.

  14. Company sells remote control software by srh2o · · Score: 3, Insightful

    I'm a bit skeptical about the motives here when the comapany is in the business of selling Remote Control software. But, I have to agree with the other posters that talked about tunneling over ssh and only allowing connections from the localhost. I'm not sure why anyone would run VNC live on an untrusted network anyway.

  15. SSH Port forwarding by Savage-Rabbit · · Score: 5, Informative

    The parent was saying that the problem was not with the lack of encryption, it was a problem with the authentication. He's not saying that SSH wouldn't solve the problem, simply that the problem would not be solved by SSH's encryption like the original poster implied, but its extra layer of authentication which is not affected by this vulnerability.

    Unless I am very much mistaken SSH would be a valid work around for the problem and it has nothing o do with SSH encryption although it makes VNC use safer, it has to do with SSH tunneling. Even if the computer you are connecting to with VNC only has port 22 exposed to the internet you can still connect to the VNC server on one of the usual ports in the 59xx range. Before you can do that, however, you first have to use SSH port forwarding by to create an SSH tunnel and physically log onto the target system with the 'ssh' command using the '-L' option. That basically means that you can only get at the VNC server by creating an SSH tunnel first. This makes any authentication vulnerability of the VNC server a non issue, not that a for this bug ASAP would be a bad thing. You should always force users to use SSH when connecting via VNC and not just rely on VNC's native authentication all on it's own.

    --
    Only to idiots, are orders laws.
    -- Henning von Tresckow
    1. Re:SSH Port forwarding by ookabooka · · Score: 2, Informative

      VNC's authentication is PLAINTEXT. It's just a little authentication thing to keep random people out, and is by no means secure. FTP is the same way, username/password are transmitted plaintext. The article is a short blurb about how they discovered a way to completely bypass authentication, so even random people have access to your desktop. IMO, if you are doing anything where security is atleast of moderate concern, you should close the port and do ssh tunneling. Otherwise you have to be willing to accept the risk that come with security holes like these, plaintext passwords, and even man in the middle attacks that allow the attacker to view the desktop during an active session. Basically, weak security has gotten even weaker.


      P.S. They have a neat little prog that will test your computer to see if it is vulnerable, though it is currently disabled because "Slashdot is too much for it to handle."

      --
      If you are about to mod me down, keep in mind that this post was most likely sarcastic.
    2. Re:SSH Port forwarding by redcane · · Score: 2, Insightful

      But if your running VNC without authentication, who is it running as? If it is running as and someone ssh'ed in as a guest, they can tunnel to the VNC session. You still want working authentication on VNC unless you *really* trust all the users on your network/box, or have some nasty firewall rules (even with a firewall you can't stop people connecting locally, or you lock legit users out).

    3. Re:SSH Port forwarding by gk2004 · · Score: 2

      SSH tunneling helps a lot, but it does not protect you against other users on the VNC server machine.

    4. Re:SSH Port forwarding by ComaVN · · Score: 2, Informative

      vnc authentication is not plain text, but anything you do over it (like logging in to your account) is.

      --
      Be wary of any facts that confirm your opinion.
  16. OS X Affected? by wo1verin3 · · Score: 3, Insightful

    Can anyone check to see if OS X's implemtation of VNC (desktop sharing) is vulnerable?

    1. Re:OS X Affected? by Anonymous Coward · · Score: 5, Funny

      Sure, what's your IP address?

    2. Re:OS X Affected? by Lactoso · · Score: 2, Funny

      127.0.0.1

  17. And here's how you do it .... by tarka69 · · Score: 5, Informative
    Start the vnc-server with the following:
    vnc4server -nolisten tcp -localhost

    Add the following to your ~/.ssh/config:

    Host lucretia
            HostName lucretia.dyndns.org
            Compression yes
            LocalForward 5901 localhost:5901

    Then ssh into the machine to create the tunnel. You then connect to the remote VNC session with "xvncviewer localhost:1".
    --
    The comfort you demanded is now mandatory - Jello Biafra
  18. Built-in VNC server in Mac OS X vunerable? by Kadin2048 · · Score: 2, Interesting

    Does anyone know if this exploit affects the VNC server that is built in to Mac OS X? I've never been clear on which mainstream software package it's based on (if any, it doesn't make it obvious either, it's just "VNC Access" and a checkbox, but I can't imagine Apple would have rewritten a VNC server from scratch if they didn't have to).

    There's no real good way to set up that service with an SSH tunnel -- I think it's intended use is only on local networks when you're behind a firewall, but on the other hand there's nothing that marks it as being screamingly insecure when you go to turn it on, either (IIRC). If you want to tunnel it, or rather, if you want to limit access to connections that are coming in via an SSH tunnel, I think you have to run a regular VNC server and set it up manually.

    The test page is down right now so I can't check it one way or the other, but I'd be interested to see if anyone knows what code is actually used for Apple's built-in VNC server, and whether people believe it's vunerable.

    --
    "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    1. Re:Built-in VNC server in Mac OS X vunerable? by Anonymous Coward · · Score: 2, Informative

      The Remote Desktop server process that runs in Mac OS X does provide support for legacy viewers (it uses an enriched protocol when talking to actual ARD clients), but it does not contain code from other VNC servers (trust me ;) )

      This vulnerability is with the Windows-based RealVNC server and its protocol implementation only, and not with the protocol itself.

  19. Re:tight vnc (NOTE TO MODERATORS) by julesh · · Score: 2, Informative

    Erm... "yes, it is."

    Note to self: proofread post before posting.

  20. Ouch! However... by Idaho · · Score: 2, Informative

    ...it is a good idea not to run VNC all the time anyway. It'd be dangerous even if it was completely designed from the beginning with security in mind, which it wasn't. I'm not even sure that the password is sent encrypted (probably it is by now), but certainly the normal traffic is not encrypted AFAIK.

    Also, there have been vulnerabilities before.

    This, of course, is not good, but whether it is acceptable also depends on the purpose that you're using it for.

    I installed VNC on the computers at my parents place, but it's disabled by default (but put in an obvious place in the start menu). When there is a problem, my parents can call me, I'll tell them to start the "Remote control thingy" (1 click in the start menu) and then I can reach the computer.

    Not much can go wrong that way, of course someone could intercept the traffic etc. if they like to stare at default windows desktops I wish them good luck.

    However, don't type the admin password over VNC, I'd guess...it's like doing 'su root' over telnet....

    --
    Every expression is true, for a given value of 'true'
    1. Re:Ouch! However... by ledow · · Score: 2, Informative

      And like any such plaintext algorithm, suitable wrappers exist and should ALWAYS be used.

      UltraVNC incorporates custom extensions that implement a Microsoft encryption DLL on Windows machines (also works flawlessly through Wine). Coupled with UltraVNC SC, you can create a single executable that anyone can download from your website and run and it will connect, fully encrypted, back through whatever firewall they have to your machine which (if it is running a suitable client) will take it over as normal.

      Or you can just do it the old fashioned way, via SSH, or even better - NOT LEAVE PLAINTEXT-PROTOCOL SERVERS RUNNING ON INTERNET-CONNECTED PC'S. You wouldn't run telnet on your parent's machine, don't run VNC without some sort of encryption.

  21. Alarmist by porkface · · Score: 2, Informative

    VNC has always had exploits. It was never designed to be secure. It was built for cross-platform system management on LANs, and everyplace I've ever downloaded it (except the RealVNC site) has always carried the original AT&T labs disclaimer that it is not a secure service.

    RealVNC has always tried to market up their version, and has been the fastest to add new features; two common warning signs when looking at a software's level of security.

  22. one workaround by sl4shd0rk · · Score: 2, Funny

    Is to post your vnc server on slashdot, thereby disabling any vnc access for you http://www.intelliadmin.com/blog/2006/05/vnc-flaw- proof-of-concept.html

    --
    Join the Slashcott! Feb 10 thru Feb 17!
  23. Re:VNC is an important tool by birder · · Score: 2, Insightful

    I've never seen the need for VNC. If you're connecting to a Windows box, use rdesktop/remote desktop. If you're connecting to a Linux/Unix machine, use ssh and tunnel X over it if you need pictures (Install Cygwin on Windows machines for X - a much better tool to install than vnc). In fact tunnel 3389 over ssh as well so as to not expose the machine outside the private network.