|
|
| |
"VNC (Virtual Network Computing) software makes it possible to view and fully-interact with one computer from any other computer or mobile device anywhere on the Internet."
Improper security measures allow attackers to bypass RealVNC authentication. |
| |
Credit:
The information has been provided by James Evans.
|
| |
Vulnerable Systems:
* RealVNC version 4.1.1
As documented in rfbproto.pdf by Tristan Richardson, the RFB (remote frame buffer) protocol performs an initial handshake which allows clients and servers to negotiate appropriate authentication measures. There are several methods of authentication, including the standard DES Challenge-Response, as well as an option to disable authentication completely. Due to an incorrect implementation, clients are able to force the server to disable authentication, and allow login without a password.
Proof of Concept:
1. Server sends its version, "RFB 003.008\n"
2. Client replies with its version, "RFB 003.008\n"
3. Server sends 1 byte which is equal to the number of security types offered
3a. Server sends an array of bytes which indicate security types offered
4. Client replies with 1 byte, chosen from the array in 3a, to select the security type
5. The handshake, if requested, is performed, followed by "0000" from the server
In RealVNC 4.1.1 and possibly prior versions which implement RFB 003.008 (though not RealVNC 4.0), the server does NOT perform a check to determine if the byte sent by the client in step 4 has actually been offered by the server in step 3a. In effect, authentication is moved from the server side to the client side. It is possible to force your client to simply request "Type 1 - None" as the security type, and gain access to the server without having to go through the time consuming and cumbersome password entry field.
Here is a typical packet dump:
Server -> Client: 52 46 42 20 30 30 33 2e 30 30 38 0a <- Server version
Client -> Server: 52 46 42 20 30 30 33 2e 30 30 38 0a <- Client version
Server -> Client: 01 02 <- One field follows... and that field is 02 (DES Challenge)
Client -> Server: 01 <- Ahh, the lovely 1 byte exploit! Beautiful, isn't it?
Server -> Client: 00 00 00 00 <-- Authenticated!
Workaround:
Run VNC servers behind firewall, and use SSH tunnels for communication.
|
| Subject:
|
VNC Exploit |
Date: |
17 May 2006 |
| From: |
nevermindscrewspam.org |
| Do they know? Are they going to issue a fix? |
|
| Subject:
|
VNC Exploit |
Date: |
18 May 2006 |
| From: |
WhiteAcid |
| They know. I suppose they're going to issue a fix, have a read of their mailing list (if they provide archives) for more info. |
|
| Subject:
|
Updated versions |
Date: |
18 May 2006 |
| From: |
WhiteAcid |
| Fixes are available at: http://www.realvnc.com/upgrade.html |
|
| Subject:
|
same problem with other version |
Date: |
30 May 2006 |
| From: |
jotesen |
i use an other version (4.1.4) and someone uses a bypass. 5 minutes after changing the password he uses it next time. now i have a new version, i hope it will be better.
sorry about my english, but my teacher has tried to teach me, but i don't understand anything. |
|
| Subject:
|
Re: same problem with other version |
Date: |
3 Jun. 2006 |
| From: |
WhiteAcid |
| Updating to the newest versions (which right now is 4.2.5) should protect you from this exploit. |
|
| Subject:
|
Firewalls and SSH doesnt help |
Date: |
7 Jun. 2006 |
| From: |
Jeff |
I don't see that firewalls nor an SSH server will really help. The problem is: if I can make a connection to a RealVNC 4.1.x server, I can remote that PC without a password. A firewall won't prevent connections on my LAN behind the firewall. And if I can authenticate with the SSH server, it will simply encrypt my connection content to the VNC Server, even thought it's the malicious "e;Type 1"e; exploit content.
The only solution is to upgrade your RealVNC installation or use a different non-RealVNC flavor of VNC.
-Jeff
|
|
| Subject:
|
4.1.8 |
Date: |
10 Jul. 2006 |
| From: |
Fadi Kahhaleh |
Hi,
I have just verified that RealVNC Ent. 4.1.8 is also exploitable via this bypass.
I have updated to the latest version and double checked to make sure its ok.
Damn this is a very vad programming mistake!!!
Fadi .K |
|
| Subject:
|
To Jeff |
Date: |
16 Sep. 2006 |
| From: |
sKewl |
Of course firewall+PLUS+ssh help. You block the VNC port and then only ssh users can VNC into the computer with ssh tunnels.
That's how everyone should do it all the time as every VNC "e;flavor"e; always ends up having some bug.. |
|
| Subject:
|
to jeff |
Date: |
19 Sep. 2006 |
| From: |
tim |
| Hi jeff, I am reading about this issieu but i do not understand one thing. So people are able to gain access through a VNC session, however if the server is locked, they still have to have the server password to gain full access? or am i wrong ? |
|
| Subject:
|
to tim |
Date: |
9 Nov. 2006 |
| From: |
Shdwbox |
Yes, if the server is locked the attacker would need to know the password. Granted that user would more than likley wait for you to login and eventually disable your mouse and keyboard.
|
|
| Subject:
|
This explain it! |
Date: |
29 Nov. 2006 |
| From: |
Dickij03 |
I went on my grandfathers pc today and within using it for 20 minutes i notice the VNC icon turn black... I found this wierd... I carried on for 10 seconds and noticed it did'nt disappear, so i double clicked it and as i did it went white again. For security i ticked the option that makes me accept the connection. Within 4 minutes i get a prompt, with the clients ip. I whois'ed it and found there address, and waited for him to try again. I accepted, and showed a WHOIS result and google map of his town, he clicked off that instance and never returned!!!
I've now upgraded and it has'nt happened again. |
|
|
|
|
