Slashdot Mirror
Critical Flaw Found in VNC 4.1
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"
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.
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!
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.
From the initial article preceding the proof of concept, TightVNC, UltarVNC and RealVNC 4.0 are not affected.
"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
Answering my own question, from this link:
Trolling is a art,
If it says it has to be available from the internet, or it won't be vulnerable. Period. Why the fuck would they go into anymore detail than that? Yours isn't available from the internet, so it's not vulnerable. No "I doubt it" it necessary.
I know people like to have karma points, but for fuck's sake...
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).
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
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.
Add the following to your ~/.ssh/config:
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
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.
Overrated / Underrated : Moderation
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.
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.
Erm... "yes, it is."
Note to self: proofread post before posting.
...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'
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.
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.
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.
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 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).
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:
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!"