tkirwan
asked on
UltraVNC password security
Hello all,
I currently use UltraVNC in my domain as a help desk tool. Originally, it was set up just to use a password, but we have become increasingly concerned with the security of using just a password, so the decision has been made to use MS Logon so that only Domain Admins can even access the program.
A concern was voiced by the newest member of our department, saying that UltraVNC transmits it's authentication data in clear text, making it easy to intercept, and perhaps disclosing enterprise admin logon credentials.
On a side note, we are in a government installation, consequently, access from the outside is not possible, except via VPN.
Can anyone shed some light on this one for me?
Thanks!!!
I currently use UltraVNC in my domain as a help desk tool. Originally, it was set up just to use a password, but we have become increasingly concerned with the security of using just a password, so the decision has been made to use MS Logon so that only Domain Admins can even access the program.
A concern was voiced by the newest member of our department, saying that UltraVNC transmits it's authentication data in clear text, making it easy to intercept, and perhaps disclosing enterprise admin logon credentials.
On a side note, we are in a government installation, consequently, access from the outside is not possible, except via VPN.
Can anyone shed some light on this one for me?
Thanks!!!
http://www.uvnc.com/features/encryption.html
ASKER
I probably should have made myself a little clearer. I understand the way the DSM plugins work, but I think that having 88 keys for all of my different PCs would become unwieldy at best.
Or am I off-base on how it works with UltraVNC?
What I'm looking to find out is if, in it's native form, UVNC transmits it's data stream in clear text.....
Or am I off-base on how it works with UltraVNC?
What I'm looking to find out is if, in it's native form, UVNC transmits it's data stream in clear text.....
For all practical purposes, yes, in its native form UVNC transmits in clear text.
The DSM plugins don't require a pre-shared key. Most of them will hash your password to use as the key, unless there is a key available. Just make sure the plugin is installed and enabled on both ends, and it will just work. You can use pre-shared keys if you want, of course.
The DSM plugins don't require a pre-shared key. Most of them will hash your password to use as the key, unless there is a key available. Just make sure the plugin is installed and enabled on both ends, and it will just work. You can use pre-shared keys if you want, of course.
True: http://www.uvnc.com/general/faq.html
Does UltraVNC provides encryption of the communication?
No. Not directly. Because we don't want to. But UltraVNC features the DSM Plugin System (Data Stream Modification) and some Strong Encryption DSM Plugins are already available (see the links page). DSM Plugins are really easy to configure and use.
You should use remotedesktop/terminalserv
http://technet.microsoft.com/en-us/library/bb457106.aspx
VNC passwords stored in the registry are also easily reversable, so it's better you use AD, but UVNC isn't very good without the encryption.
In addition, your a gov't shop, and RD/TS can be set to FIPS-140 compliance:
http://technet.microsoft.com/en-us/library/cc750357.aspx
-rich
Does UltraVNC provides encryption of the communication?
No. Not directly. Because we don't want to. But UltraVNC features the DSM Plugin System (Data Stream Modification) and some Strong Encryption DSM Plugins are already available (see the links page). DSM Plugins are really easy to configure and use.
You should use remotedesktop/terminalserv
http://technet.microsoft.com/en-us/library/bb457106.aspx
VNC passwords stored in the registry are also easily reversable, so it's better you use AD, but UVNC isn't very good without the encryption.
In addition, your a gov't shop, and RD/TS can be set to FIPS-140 compliance:
http://technet.microsoft.com/en-us/library/cc750357.aspx
-rich
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Bear in mind though that doing work for/with the US government, you may be required to adhere to minimum encryption standards and validation (FIPS) which M$ happens to have on most of their crypto modules. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm
UVNC hints at using some OpenSSL (also fips certified) but they neglect to say which one does...
Also, using RDP isn't any harder than using your own desktop... setup is pretty simple and easily managed via AD. I'm no M$ fan, but RDP is one of the best things they ever did :)
In addition, the logging facilities (event log) can be very granular using RDP, you will want to turn up the default settings if you want to actually track anyone on your lan, the defaults typically only track failures and some successful actions.
-rich
UVNC hints at using some OpenSSL (also fips certified) but they neglect to say which one does...
Also, using RDP isn't any harder than using your own desktop... setup is pretty simple and easily managed via AD. I'm no M$ fan, but RDP is one of the best things they ever did :)
In addition, the logging facilities (event log) can be very granular using RDP, you will want to turn up the default settings if you want to actually track anyone on your lan, the defaults typically only track failures and some successful actions.
-rich
I admit if I were to choose something wide scale from the start in your situation, I would probably try to use RDP. It's just more convenient, and RDP is quite nice. RDP is integrated into XP, and feels more responsive.
But, annoyances like people turning off Remote Assistance or the service being corrupted and/or disabled may become a hassle. Not to mention having to go set it up and deal with new problems. "If it isn't broken, don't fix it." This is why I would see no reason to switch over from a UVNC set up that's already working. It's fine, and with minor changes would satisfy your coworker's qualms. Just drop in the DSM plugin.
richrumble:
Correct me if I am wrong. I would assume that AES 128 based on OpenSSL should adhere to the minimum standards. As would ARC4 128. I'm not sure about MSRC4, but given that RDP uses MSRC4 I would assume it would also.
But, annoyances like people turning off Remote Assistance or the service being corrupted and/or disabled may become a hassle. Not to mention having to go set it up and deal with new problems. "If it isn't broken, don't fix it." This is why I would see no reason to switch over from a UVNC set up that's already working. It's fine, and with minor changes would satisfy your coworker's qualms. Just drop in the DSM plugin.
richrumble:
Correct me if I am wrong. I would assume that AES 128 based on OpenSSL should adhere to the minimum standards. As would ARC4 128. I'm not sure about MSRC4, but given that RDP uses MSRC4 I would assume it would also.
True, they probably would be sufficient, however UVNC and or it's modules do not have the accreditation. I've used VNC products in Gov't settings however to comply with FIPS and other mandates it has to first be tunneled through SSH/SSL or other approved crypto. I've personally only used TightVNC/RealVNC/WinVNC but not UVNC, but I assume they are all about the same, the 3 I've used dont' differ really :) But securing them in this way was always a pain, so once RDP came along, I've never looked back. I also never use the "remote assistance" features, those I've never gotten to work consistantly.
-rich
-rich
richrumble:
I can't say I know a whole lot about what it really takes to be FIPS certified.
But, I would assume that FIPS-104-1 would apply only to the cryptographic module itself? It shouldn't be RDP that's FIPS certified, but the MS cryptographic services that has been FIPS certified. Thus, if the DSM plugin implements AES or RC4 using OpenSSL, isn't that sufficient?
MSRC4 should definitely be compliant then, as well. The MSRC4 plugin uses the MS cryptographic services available from the OS. The source of its encryption would be the same as that of RDP.
I can't say I know a whole lot about what it really takes to be FIPS certified.
But, I would assume that FIPS-104-1 would apply only to the cryptographic module itself? It shouldn't be RDP that's FIPS certified, but the MS cryptographic services that has been FIPS certified. Thus, if the DSM plugin implements AES or RC4 using OpenSSL, isn't that sufficient?
MSRC4 should definitely be compliant then, as well. The MSRC4 plugin uses the MS cryptographic services available from the OS. The source of its encryption would be the same as that of RDP.
Also true, and I don't think someones choice should depend solely on a "cert" from the gov't, you'll note that VNC stores the password hash in the registry. VNC does use 3DES, however it's weakened by using the fixed encryption key(23 82 107 6 35 78 88 7) and limiting the password to 8 max characters. So even if you do use a strong and approved cipher, the implementation can be weakened. I've not vetted UVNC myself so i can't speak to that ultimately... We can assume they don't weaken the encryption further I can't find proof otherwise :) Any kind of encryption is better than none especially for VNC.
It does appear from thier site they are using the same modules that are FIPS approved:
http://www.uvnc.com/features/encryption.html
UltraVNC features a Data Stream Modification (DSM) Plugin System allowing for any kind of operation on the data exchanged between client and server, from an external DLL (independent, not linked and not distributed with UltraVNC): additional rights checking, communication timing, data recording/persistence, encryption... it's up to the DLL developer.
http://www.securiteam.com/securitynews/3P5QERFQ0Q.html (this applies to current VNC clients/server's still and since VNC was first introduced)
-rich
It does appear from thier site they are using the same modules that are FIPS approved:
http://www.uvnc.com/features/encryption.html
UltraVNC features a Data Stream Modification (DSM) Plugin System allowing for any kind of operation on the data exchanged between client and server, from an external DLL (independent, not linked and not distributed with UltraVNC): additional rights checking, communication timing, data recording/persistence, encryption... it's up to the DLL developer.
http://www.securiteam.com/securitynews/3P5QERFQ0Q.html (this applies to current VNC clients/server's still and since VNC was first introduced)
-rich
I'll try not to drag this thread any further, as it may become a kind of hijacking of the thread.
I'll create another thread for further discussion, as I think this is an interesting question that needs to be addressed, so as not to misrepresent the VNC solutions available. I have found that VNC has some stigmas from the old days that it hasn't shaken off. Some are true, and some I usually find to be at least partially untrue
https://www.experts-exchange.com/questions/23866922/VNC-and-security.html
Ah yes, the classic authentication from back when AT&T had developed VNC as a prototype. Very insecure and might as well be clear text, not to mention the length limitation. But both RealVNC (Ent) and UltraVNC have alternative methods of authentication (that use Windows authentication). Both can authenticate to AD, and supports user impersonation to lower privileges. (Which the author is using in this case)
I'm surprised that RealVNC still has that problem. I remember RealVNC extending the authentication early on to support longer passwords, providing the truncated version for legacy reasons. Perhaps only in the free version? I also remember there being a version 4 in the works at least a year or two ago, if not longer.
Last I remember, their non-free version had undergone a great deal of change, many of which included strong security features. I recall it going as far as having the encryption features put into the Java viewer and being used by default. You have to pay for it, mind you, but RealVNC had impressed me. Especially the rate at which they were adding/improving. I would be surprised if RealVNC Enterprise did not meet or even exceed FIPS standards.
I'll create another thread for further discussion, as I think this is an interesting question that needs to be addressed, so as not to misrepresent the VNC solutions available. I have found that VNC has some stigmas from the old days that it hasn't shaken off. Some are true, and some I usually find to be at least partially untrue
https://www.experts-exchange.com/questions/23866922/VNC-and-security.html
Ah yes, the classic authentication from back when AT&T had developed VNC as a prototype. Very insecure and might as well be clear text, not to mention the length limitation. But both RealVNC (Ent) and UltraVNC have alternative methods of authentication (that use Windows authentication). Both can authenticate to AD, and supports user impersonation to lower privileges. (Which the author is using in this case)
I'm surprised that RealVNC still has that problem. I remember RealVNC extending the authentication early on to support longer passwords, providing the truncated version for legacy reasons. Perhaps only in the free version? I also remember there being a version 4 in the works at least a year or two ago, if not longer.
Last I remember, their non-free version had undergone a great deal of change, many of which included strong security features. I recall it going as far as having the encryption features put into the Java viewer and being used by default. You have to pay for it, mind you, but RealVNC had impressed me. Especially the rate at which they were adding/improving. I would be surprised if RealVNC Enterprise did not meet or even exceed FIPS standards.