Possible Bug ?? SecureVNC -- Client Authentication Keys

[YY]

I have an interesting issue on using the Client Authentication Keys of SecureVNC Plugin.

I created a pair of the keys (*_ClientAuth.pubkey, *_ClientAuth.pkey) and testing with a Single Click connection, they worked as expected.

However, when doing a reverse connection with a normal uvnc winvnc.exe, I found the *_ClientAuth.pubkey (seems) not involved in the communication. Even not existing the winvnc.exe still able to establish the connection with the listening viewer.

With Single Click, missing the *_ClientAuth.pubkey casued "The server running as application" error at the viewer pc.

Is it a bug?

My test condition:
UltraVNC server & viewer -- 1.0.9.5
SecureVNC Plugin -- 2.3.0.0
Single Click -- RC23
OS -- Win XP Prof SP2

[Rudi De Vos]

did following tests (1095)

winvnc+secureplugin+server-key
vncviewer+secureplugin+viewer-key

invers + normal

If viewer-key doesn't match server key -> connection refused OK
This seems to work as it should be.


Old Single click versions !!!
You need to use the old secure plugins.
SecureVNC Plugin -- 2.3.0.0 framework differ from the framework used in SC.

[YY]

did following tests (1095)

winvnc+secureplugin+server-key
vncviewer+secureplugin+viewer-key

invers + normal

If viewer-key doesn't match server key -> connection refused OK
This seems to work as it should be.

Yes, your test result showed the way it should be .... but not match mine, in my experiment:

winvnc+secureplugin+*_ClientAuth.pubkey
vncviewer+secureplugin+*_ClientAuth.pkey

reversed connection ..... OK, that is fine


However, when trying this test:
winvnc+secureplugin (key not exist)
vncviewer+secureplugin+*_ClientAuth.pkey

reversed connection ..... STILL OK !?!?!?!?!?

Old Single click versions !!!
You need to use the old secure plugins.
SecureVNC Plugin -- 2.3.0.0 framework differ from the framework used in SC.

I got confused !!!
In my test, the Single Click (the winvnc.exe of RC23 ) was working properly with SecureVNC Plugin -- 2.3.0.0.
I didn't encounter a problem .... but I just took a brief trial.

[Rudi De Vos]

Code: Select all

However, when trying this test: 
winvnc+secureplugin (key not exist) 
vncviewer+secureplugin+*_ClientAuth.pkey 
reversed connection ..... STILL OK   !?!?!?!?!? 

This is the way it should work.
winvnc+secureplugin (key not exist) : You tell the server, who control the
security plugins that he need to use dynamic keys... If the viewer has a key or not, the server as master decided to exchange keys.

The encryption protect the server, server settings always overwrite viewer settings.

+If server has a key, the same key need to exist on the viewer site
+If the server doesn't have a key, the key is always dynamic exchanged.

The same viewer config with a key can be used for a connection that require the key or for a connection with dynamic key exchange.

SC:
I always used it with the encryption plugins provided with SC.
Keep in mind that when the server doesn't use encryption, the viewer
switch to non encryption mode....
( Server is MASTER.....)

[YY]

In my opinion, it is in fact a serious security hole.

1. In normal operation:
winvnc + secureplugin + *_ClientAuth.pubkey
vncviewer + secureplugin + *_ClientAuth.pkey

reversed connection OK, that is fine. No one can eavesdrop this communication.


2. In this condition:
winvnc + secureplugin (key not exist)
vncviewer + secureplugin + *_ClientAuth.pkey

reversed connection still OK =====> TOTALLY NOT ACCEPTABLE.


In order to establish a connection, the two parties must be using the matching keys pair. Since these is designed for remote support / single click situations, the server (and *_ClientAuth.pubkey) are public distributed, and is easy be tampered. This will not cause an impact, since there is the *_ClientAuth.pkey at the viewer, which is protected and untouched by others.

However, since now simply remove the server's *_ClientAuth.pubkey, will INSTRUCT THE VIEWER TO GIVE UP USING the *_ClientAuth.pkey to AUTHENTICATE the server, and using a new key from the server, that means these public & private keys encryption mechanism losing their function.


3. Consider this situation:
winvnc + secureplugin (key not exist)
vncviewer + secureplugin + *_ClientAuth.pkey

reversed connection still OK

In this case, the server's secureplugin is a patched version from a hacker, which always provide an special key (selected by the hacker) to the listening viewer. Since the communication is working completely normal, both the supporter and client will consider the connection is secured, yet it can be eavesdroped by other parties.

[rsutton]

3. Consider this situation:
winvnc + secureplugin (key not exist)
vncviewer + secureplugin + *_ClientAuth.pkey

reversed connection still OK

In this case, the server's secureplugin is a patched version from a hacker, which always provide an special key (selected by the hacker) to the listening viewer. Since the communication is working completely normal, both the supporter and client will consider the connection is secured, yet it can be eavesdroped by other parties.

I think you are right in this. I am certainly no security expert, but it appears to be a big hole. I think that Adam Walling has done a remarkable job with this plugin, but I would sure like to hear his comments on your scenario. I rarely use SC, myself and SC does add a wrinkle due to the fact that it is operating in reverse, so to speak.

Dick

[Rudi De Vos]

If the hacker has root access to the PC he can

mywinvnc + secureplugin + *_ClientAuth.pkey

The you think your 100% secure, encrypted and the key is correct
But his winvnc version log all..

If a hacker get root access, it wil never by secure

A winvnc without a key works like a SSL website.
DH key exchange -> all is still encrypted over the net
Each key is different

1) A stastic key is a second ACCESS protection
You need to have the key and the password
2) A static key make the encryption less secure unless each key is only used a single time.

If someone access my system i want to be able to use dynamic keys
with a 32 char passwd or a static key without passwd.
It is not the company that give support that should make the choise for me...

I'm sure other people has another opinion and possible we need to discuss what's the best... but i don't think it's a security hole.

[YY]

The problem is NOT the server got root access by a hacker.

It is just the hacker has a way to eavesdrop the communication, to watch/capture the sceen, to record the key stroke or mouse click.

For e.g., if I'm in a hotel, and using my notebook to connect to my company's pc via VPN. that should be a secured connection. However, due to some bug/incorrect setting, actually a man in next room just able to watch my operation with his pc. Is it a problem?

IT IS NOT MY NOTEBOOK GOT ACCESSED BY A HACKER, BUT ALL MY OPERATION WITH IT IS EAVESDROPED.

The public key & private key encryption has no problem by itself, provided that the private key is kept protect.

But the present situation of reverse connection is something like:

Server: Hi! viewer, I forgot to bring my public key, how about I send you another one for the communication?

Viewer: No problem! Send it to me, and I will use it instead of the original private key, and my boss will not aware this.


So the communication is established, and no non-authorised paople got access the server, just may be eavesdroped.
Is this a secured communication?



To sum up my opinion:
If the server & viewer are arranged to use a pre-installed key-pair for the communication, why this arrangement is so easy to be broken .... just in the case the key is missing at the server side.

Remember:
1. I'm talking the reverse connection, which the uvnc is usually wrapped as a single .exe for remote helpdesk, and is public distributed, and everyone can get it and modify it.
I'm not saying the normal VNC connection having this problem with SecureVNC.

2. For the meaning of security hole, I'm not saying the server be accessed by non-authorized people, I just consider the communication is possible be eavesdroped.

[adzm]

My apologies for my belated reply; I had been away from the forum for a while.

To address the security concerns, you are correct that if the server does not have a client authentication public key, then the server does not advertise that it needs client authentication from the viewer.

The general design revolves around the concept that the server specifies what forms of encryption it requires, and the viewer accommodates the server's request.

However, even without client authentication keys, your communication cannot easily be eavesdropped.

In order to do so, the attacker would have to be able to actively modify the communication session, acting as a man-in-the-middle using its own keys. In most situations this is infeasible.

However, even if there is an active attacker in control of the communication, eavesdropping is still hampered by the password protection applied to the handshake.

The handshake is encrypted based on the passphrase that is configured within the SecureVNC plugin. If one is not set within the plugin, then it will use the VNC password.

In summary, the only way eavesdropping is feasible is if all the conditions are true:

1) An attacker is actively intercepting and modifying the communication between the server and viewer.
2) No passphrase has been enabled within the SecureVNC plugin
3) No password has been enabled for the UltraVNC server.

Regardless, a weak password will always be a weak password.

There are several possible resolutions to the issue being raised. For example, the server plugin could have an option to require client authentication keys. Then if the key is misconfigured or tampered in any way, then all connections would be refused. Additionally, the viewer could be configured to warn the user when not using a client authentication key.

Any thoughts on the approaches I mention above?

[redge]

an possible option ?
/requireencryption
/requirekey (not exist)

so server can't reverse connect without key and be rejected ?

[YY]

Hi! admz, Since I have a very basic knowledge of encryption, and I'm not sure fully understand your explanation. Anyway, thanks for your great job.

In summary, the only way eavesdropping is feasible is if all the conditions are true:

1) An attacker is actively intercepting and modifying the communication between the server and viewer.
2) No passphrase has been enabled within the SecureVNC plugin
3) No password has been enabled for the UltraVNC server.

My concern is the situation of the uvnc is usually wrapped as a single .exe for remote helpdesk, and is public distributed, and everyone can get it and modify it.

Is it easy for a hacker to modify that .exe, to achieve these three condition? So that if someone using that .exe may happen the eavesdropping?

Additionally, the viewer could be configured to warn the user when not using a client authentication key.

That is a good idea!