Whitepaper – UltraVNC Encryption Overview

By Bozteck

Introduction

Bozteck VENM Console can deploy UltraVNC with session level encryption enabled. This is recommended in network environments where you fear that your VNC session may be “sniffed” from the network and replayed back without your knowledge. The risk of someone successfully doing this on your LAN is very low as it does require a moderately high level of “hacker skill”. Some networks, however, need extra protection even against low risk attacks such as this.

This document will explain the principles behind the VENM supported UltraVNC encryption as well as how to deploy and enable it from the console. The skill level to use this information successful varies. If you simply accept the safe defaults, the skill level required is low. If you choose to make modifications such as creating a custom rc4.key file, the skill level required is much higher.

This document is for Admins who want to customize the encryption, get to know how it works at a lower level, or are having DSM errors when connecting to an encrypted server. Anyone else can skim through or read this document as they wish.

Basic Principles

vncviewer.exe –> {RC4.KEY} ===> (Network) ===> {RC4.KEY} ==> [msrc4plugin_noreg.dsm] –> winvnc.exe

There are two key files that are fundamental to UltraVNC session level encryption and they are “msrc4plugin_noreg.dsm” and “rc4.key”. These will be refered to as the DSM and KEY files respectively through the rest of this document.

When a vncviewer.exe file wants to talk to an UltraVNC server that is set to use encryption, it starts by looking for it’s copy of the KEY file. If found, it encrypts it’s connection attempt using the data in the KEY file. It, then, sends a connection request to the remote server using this encrypted mode of communication that would seem like garbage to anything else on the network.

On the other end, the server hears a connection being requested. Because it is also configured to require encryption, it consults it’s copy of the KEY file and uses the data in the KEY file to decrypt the communication request coming from the viewer. If the keys match up, the data is correctly deciphered and the two commence communication in this encrypted tunnel.

If the keys do not match, the connection attempt is rejected and the viewer presents an error to the user stating that possible reasons could include the failure to find a DSM file and a few other suggestions. The error message is vague but it pretty much just means that either:

  • The remote server is not configured for encryption but you are sending an encrypted request
  • The server is configured to require encryption but you are sending an unencrypted request
  • Both ends are configured for encryption but the KEY files do not match

More About the KEY and DSM Files (Server End)

The DSM file is a plug-in to the winvnc.exe service file. For reference, the winvnc.exe is the actual server executable for UltraVNC that is deployed to the remote computers and installed as a service. The DSM file must reside in the same folder as the winvnc.exe file. Don’t worry too much about that because the Bozteck VNC Deployment Tool does that work for you. When the DSM file is in the same folder as the winvnc.exe file and the configuration for the server has been properly set, the server will attempt to encrypt communication for any client that attempts to connect to it.

The KEY file also must reside in the same folder as the winvnc.exe file. The Deployment Tool also make sure that this happens as long as you do not modify things too much. If you simply tell the Profile Editor to enable encryption, it takes the KEY file that is located in c:\fastpush\vnc7\ultra and copies it to your Deployment Profile’s folder for easy deployment every time that you push that profile out to a computer.

Because this KEY file must match the KEY file on the Viewer end, it is best practice to only use one KEY file for your entire network. You do not gain sufficient security advantage by using multiple KEY files to make up for the headache required to keep them all straight and matched up. If you choose to generate a new KEY file, you must push that new KEY file out to each and every computer on your network that has encryption enabled to ensure proper connectivity.

By default, the UltraVNC Server is installed to either “C:\Program Files\orl\vnc” or “C:\Program Files\ultravnc” depending on the version of UltraVNC you are using. If you choose to distribute the KEY file using some method other than a VNC Push from VENM, it must in somehow make it’s way into that path on the remote computer end. Again, the VNC Push from VENM does this for you.

More About the KEY and DSM Files (Viewer End)

The KEY file is required to be in the same folder as the vncviewer.exe file. This KEY file must be an exact copy of the KEY file that is located at the server end as described above. By default, VENM uses the vncviewer.exe located in “C:\Program Files\Bozteck\VNCScan Console .NET” or whatever location you have installed VENM to.

You have the ability to customize the location of your vncviewer.exe file using either the main preferences (Support Files section), group properties (VNC Settings section), or the computer properties (VNC Settings section). If you choose to modify the location of the vncviewer.exe file, you need to make sure that a copy of your RC4.KEY file is moved with it.

Creating Custom KEYs

The Profile Editor has a button in the “Customs” section that allows you to generate a new key. This is an advanced level function and should never really need to be done in normal circumstances. To my knowledge, there has never been a tool released that allows someone to decrypt an encrypted UltraVNC stream for later playback. You should only need to generate a custom key if this is ever done. The KEY file does not control who can access you server. It only controls the way that the session is encrypted. You will still need to authenticate with the remote server using your password even if the KEY files match up.

If you do choose to create a custom KEY file, pressing this button is the easiest way to make sure that everything is placed in the correct locations for easy deployment. You may need to manually copy the new KEY file to the location where your vncviewer.exe resides, however. The newly generated key is always placed in c:\fastpush\vnc7\ultra.

Conclusion

I hope that this was a good in-depth overview of how the UltraVNC encryption works and how it interacts within the Bozteck VNCScan Enterprise Network Manager (VENM).

categoriahow-to, White Papers commento1 Comment dataFebruary 20th, 2009
Leggi tutto

Deploying VNC To Computers (Updated)

By Bozteck

Introduction

Bozteck VENM Console makes it very easy to deploy many versions of the VNC (Virtual Network Computing) remote control software to desktops and servers on your network.

With VENM, you simply create a template of settings called a Deployment Profile, select some computers, and choose to deploy VNC to them from the toolbar. Using the settings in your Deployment Profile, VNC is copied onto the remote computers, the services are installed and started, and you are ready to remote control the desktops!

Security and Authentication

Because this tool is copying files to secured ares of the hard disk over the network, you do need to know the credentials of a valid Administrator level user for the remote computer(s). If the computers are joined to a domain, you can typically use the domain administrator account.

If the computer is not a member of an Active Directory domain, you simply use the local administrator username and password. You will see in the instructions below how to specify this using the %HOST% variable.

You can enter and save these login credentials in the group properties if you’d like. You can do this by right-clicking a group and choosing to view it’s properties. You can save them in the section called “Remote Login Settings”. You can also simply enter them in every time that you choose to deploy a computer.

Firewalls

Files are being transferred over the network and commands to start and stop services are traveling about. This requires that any firewalls be adjusted to allow for this.

The deployment process requires that TCP port 445 is open on each computer. In addition, it would be a good idea to allow TCP and UDP ports 138 and 139. These are the standard Windows filesharing ports.

The deployment script will open any additional ports required by VNC for you.

Step-By-Step

Select The Deployment Editor

Choose to create a new profile

Fill in the desired settings
Note: only version and password are required
Choose to Deploy VNC from the ToolBar

categoriahow-to commentoNo Comments dataFebruary 2nd, 2009
Leggi tutto

Thumbnailed Remote Screen Captures in VENM Console

By Bozteck


Overview

Bozteck VENM Console includes a powerful remote screen capturing feature. This feature does not require that VNC or any other remote screen sharing software be installed in order to work. There are a few system requirements on the remote computer end, however.

Those requirements are as follows:

  • UnFirewalled ports 443 (TCP) and 139 (UDP, TCP)
  • Remote Registry service running
  • Administrative priviledges on the remote computer
  • Windows 2000, XP, Vista, or Windows 7

Because of these requirements, it is “best practice” to use this feature on computers that are on your LAN or within reach of your VPN. For security reasons, it is not advisable to use this feature over the open Internet.

You can supply the Administrator level access required to make this feature work in either the main VNCScan preferences, the group properties, or the computer properties. The choice depends upon the scope that you wish to apply.

Feature Set

  • Resizable – You can resize the thumbnail by adjusting the slider in the toolbar
  • Adjustable Interval – You can adjust the interval using a dropdown box of predefined timings or type in your own number. The intervals are measured in minutes. You can enter a decimal number to take snapshots in times less than one minute. If you manually enter a timing, it is applied when you press .
  • Archive Screen Captures – You can archive your screen captures for later viewing. The location of these archives can be changed by clicking on the “Folders” button on the toolbar.
  • Connect to VNC – You can connect to VNC right from the thumbnail. The connection options are taken from the computer entry settings in VNCScan.

What To Look Out For

  • The “Please Wait Screen” – This screen is the start image for a new screen capture session. It is normal for it to still be visible even after the progress bar has cycled a couple of times. If it is still the only image being displayed for a computer even after the progress bar has cycled more than three times, you may want to check the permissions settings for the computer.

    You can test this out by attempting to access the c$ share of the remote computer. You can do this by clicking on your Start button and choosing “Run”. In the textbox, type \\\c$ (where is the name or IP address of the remote computer).

  • Black Screen Capture – This is shown if the remote computer is sitting at the login screen and nobody is logged into the computer.

Video Example

Download video

categoriahow-to commentoNo Comments dataJanuary 24th, 2009
Leggi tutto

Background Scanning and Alerting Features in 2009.1.20

By Bozteck

Overview

New in 2009, Bozteck includes background service scanning and alerting to it’s powerful Enterprise Network Manager. This paper is a brief explanation of how it works and how to best take advantage of this new feature.

Usage and Benefits

Background scanning allows you to see an accurate view of what computers are running the VNC and RDP services as well as what computers are currently pingable on your network. You set the amount of time between scans in the main program preferences and then let VENM fo the rest!

The powerful alerting features keep you up to date on what is happening even when you’re away from your desk. Each of these actions can be set in the group properties and overridden by the computer properties. Below is an overview of available alerting and actions.

  • When a computer goes offline
    • Send an email to a designated address
    • Run a local custom command such as “PING -t %HOST%” or any other command that you have created using the Custom Commands feature in VENM.
  • When a computer comes back online
    • Send an email to a designated address
    • Auto-connect to VNC once the VNC service has been detected
    • Run a script remotely on the computer once Windows has been fully loaded. This is a powerful way to schedule a script if the computer is currently not online.


How It Works

There is a decision tree method being employed for determining if a computer should be probed in the background. This decision tree is explained in the following bullet points.

  • Scanning is enabled in the program preferences
    • Scanning is enabled in the group settings
      • Computer is inheriting settings from the group
        • Scan the computer according to group settings
      • Computer is overriding group settings
        • Services are selected in the computer settings
          • Scan the selected services
        • Services are NOT selected in the computer settings
          • Skip this computer in the group scan
    • Scanning is NOT enabled in the group settings
      • Skip the entire group from background scanning
  • Scanning is disabled in the program preferences
    • Do no background scans at all

Conclusion

We’re excited about these new features in the VENM Console and will continue to build upon them. We would love to hear your feedback about this! Let us know what you think at feedback@vncscan.com

categoriahow-to commentoNo Comments dataJanuary 19th, 2009
Leggi tutto

VNC RDP and Ping Background Scanning with VNCScan

By Bozteck

Download the full video in MP4 Here.

categoriahow-to commentoNo Comments dataJanuary 15th, 2009
Leggi tutto

Execute Scripts Remotely (Video)

By Bozteck

You may want to make this video full screen to see it more clearly.
Download the full video here

categoriahow-to commento3 Comments dataJanuary 13th, 2009
Leggi tutto

Disabling Firewalls for Management

By Bozteck

I’ve had a lot of requests for a way to disable XP firewalls on the network or at least open up the required ports to remotely manage the computers. If your workstations are protected by a NAT translating router with a decent firewall built into it, there is typically little need for the XP desktop firewall to be running on them.

If you have the XP firewall enabled, there’s very little that you can do in the way of remote management for these PC’s. Fortunately, there are was to automate the configuration of the XP firewalls on your network depending on what type of a network you are using.

Login Script Method

The easiest way to do this is with a login script. If your company is using a directory services such as Novel or Active Directory, you can create a script that runs each time that a user logs in. You can use this script to open the required firewall ports.

We run into a problem, however, if the user that is logging in does not have local administrative rights on his PC. This is required to modify the settings. For this, we can employ a nice piece of freeware called CPAU. Using this tool, you can do a run-as style command to make it go. Alternatively, you can use a tool such as Admin Script Editor to compile your script into an executable that runs under a specific security account. There are other tools that can do this and feel free to add them in the comments section if you would.

Active Directory Startup Script Method

You can also run the script using Active Directory’s group policy for the machine account. This script runs under the context of the machine’s system account and does not need to be elevated by tools such as CPAU. You can do this in the Group Policy Editor under “Windows Settings => Scripts => Startup”.

The following is a script that will open the required ports on the XP firewall:

netsh firewall set portopening udp 445 WindowsNetworking enable all
netsh firewall set portopening tcp 139 WindowsNetworking enable all
netsh firewall set portopening udp 137 WindowsNetworking enable all
netsh firewall set portopening udp 138 WindowsNetworking enable all
netsh firewall set portopening tcp 5900 VNC enable all
netsh firewall set portopening tcp 5800 VNC-HTTP enable all

Group Policy Method

You can set these options using Active Directory’s Group Policy, also. You can access this in the Group Policy Editor by navigating to “Computer Configuration => Administrative Templates => Network => Network Connections => Windows Firewall”.

Extra Notes

As a side note, if you choose to use a scripting tool such as Admin Script Editor to compile your script, you can also choose to distribute it directly to the end users so that they can execute it themselves.

Make sure that you also disable Simple File Sharing on the remote computers. That can be just as much of a barrier to remote administration as the firewall. I’ll make a post about that one soon.

Leggi tutto

Demo: Installing UltraVNC to Vista

By Bozteck


You can download this tool
here!

categoriahow-to commento4 Comments dataMay 30th, 2008
Leggi tutto

Backup/Restore VENM Data

By Bozteck

How VENM Stores Data

Most data in VNCScan centers around the groups.xml file. This means that most other data resides in the same folder as this file. When you change the location of the groups.xml file in the main VNCScan preferences, much of the other data follows suit.

The default location for VNCScan data is under your “My Documents” folder inside a subfolder of “VNCScan\data”. If you browse that folder with Windows Explorer, you will see a lot of XML files.

There are a few key files that have special meaning. Here they are with their functions:

· Settings.xml – This file holds all of the initial settings for the console. It contains any customized file locations such as an alternate location for the groups.xml along with anything else that is global to the application.

· Groups.xml – This holds all of your group names along with their settings. You will find XML files in the same folder named after the group names, also. These files hold the computers and their settings.

For instance, if you have a group named “Default”, it would be listed in the groups.xml as well as have its own file named default.xml to hold it’s computers. It is separated out like this to improve performance.

· ConnectionLogs.xml – This holds the connection logs for each computer. It resides in the same folder as the groups.xml and moves with it.

· Computername_maint.xml – The Computername is any computer name with a maintenance log. These files store the maintenance logs for the computers.

Note: There is also a file called settings.xml located in the VNCScan program folder. That file should be backed up and restored with the rest of your data.

Other folders worth noting under ‘My Documents\VNCScan’ are:

· Jobs – Stores all of the remote scripts and their settings

· Profiles – Stores all of your VNC deployment profiles and their settings

Backing Up Your Data

These are the default folder locations that you should be backing up regularly:

· ‘My documents\VNCScan’

· ‘C:\Program Files\Bozteck\VNCScan Console .NET’

· ‘C:\fastpush’

Restoring Your Data

1. Close the VNCScan console and any open VNC sessions

2. Restore the data from your backup into the proper locations

3. Launch VNCScan Console.

categoriahow-to commento3 Comments dataJanuary 14th, 2008
Leggi tutto

Obtaining remote MAC addresses

By Bozteck

It’s long been a feature in the VENM console. When you scan your network, the scanner would send a broadcast packet to obtain the MAC address of the detected computers on your LAN. The key concept in that sentence is “broadcast packet”.

Most of our customers are Network Administrators or Engineers so I probably don’t need to bore you with the reasons that using broadcast packets just does not work over a WAN connection such as VPN. If you’ve scanned over a VPN, you’re probably aware that the VENM console just fills the MAC address field with a bunch of 0′s.

We’ve been writing code into the latest scanning engine that will use other methods to attempt to detect the MAC address if the broadcast packet fails over a WAN or VPN. Right now, we have it working in the ‘Computer Properties’ window and we’re working to get it working in the scan.

The catch is that you need to have Administrative rights on the remote computers and the port required must not be blocked. This is typically TCP port 135.

This is just one of the many things that we’re working on for your next release.

categoriahow-to commentoNo Comments dataDecember 19th, 2007
Leggi tutto