Security - Common Questions

Security - Common Questions

We have prepared this section of our website to answer some of the most frequent questions about our security.

Why do I receive security warnings?

The "Job" of Firewall/Security software is to notify the User when a new program or file is trying to access the internet and give them the option to "Allow" it to run and access the internet or "Deny" it access.
CrossLoop uses VIPTunnel technology and TightVNC for remote control and screen display. Some security programs flag files with VNC and VIP in their names and bring them to the user's attention as a possible threat.

Since CrossLoop is a remote control program and it must access the internet to function the user needs to configure their Security software to "Allow" CrossLoopConnect.exe, WinVnc.exe and VncViewer.exe to run and access the internet. Some programs report vipun.dll and Vnchooks.dll during the install of CrossLoop so you must configure your firewall to allow these files. Here is a great online resource that explains how to allow a program internet access for the most popular firewalls.

Since the VNC files may be used by other software your firewall may continue to alert you about these files. We have built in security into our model unlike other applications and you can read more about it in our Security section. There are many thousands of people using CrossLoop in over 140 countries and security is important to us, so you can safely allow CrossLoop's files.

If your security software automatically deletes or quarantines files without asking you if you want to allow them to run you should report that action to the security software company as a bug.

(Back to top)

Does the CrossLoop application contain any viruses?

CrossLoop does not contain any virus of any kind. A connection cannot be established with CrossLoop unless a user is present at both computers to initiate a connection and the user of the Share computer must also click on the "Allow" or "Deny" button of a confirmation screen before control is given. You can safely decline any potential warnings you receive about viruses.

(Back to top)

Can I get a virus through CrossLoop?

The only information transferred between the computers during a normal session is the pixels being displayed on the screen, mouse operations, and keystrokes. No file data is ever transferred between the computers except if you explicitly send files using our file sharing option.

Our latest version of CrossLoop supports file transfer. This process could be vulnerable to spreading a virus if the file transfer operation was used to copy an infected file from one computer to another. We display a warning to this effect in a dialog if the user initiates a file transfer.

(Back to top)

What information does CrossLoop track about my sessions?

The CrossLoop Share and Access applications are identified by a "Name". This name is generated automatically from your user name and computer name, e.g. "TOMR on TOMS-EMACH2". However, this field is editable and you are free to change your name to anything you wish. This "Name" is sent in clear text to the CrossLoop server during the rendezvous phase of the connection. In addition to the name the application also sends information about the version of CrossLoop which the application is running. This information includes the software version and build number. The reason for sending CrossLoop version information is to verify that we are able to connect the Share and Access applications.

After a connection is established and a session is created between the Share and Access computers, CrossLoop tracks the length of the session and the number of bytes sent between the computers. Periodically, both the Share and Access computers send information about the number of bytes sent/received to the CrossLoop server. This data is used for performance tuning and optimization of the CrossLoop services. CrossLoop also tracks the type of connection, relay or P2P.

In no event does the CrossLoop server have access to the encrypted screens which are shared between the Share and Access computers.

At the end of each session the local registry on the application is updated with session information, including: type of session (Share or Access), length of session, and a rating value if the session was rated. This information is only collected on the application and can be displayed on the application by accessing the "Usage Statistics" menu item. The purpose of this information is to allow you to see your accumulated usage of CrossLoop.

(Back to top)

How do I know there is no secret back-door in the code?

CrossLoop is a shell program which uses fork and exec to invoke a VNC (Virtual Network Computing) program. The Windows version of CrossLoop currently uses the TightVNC plug-in program, a free GPL-licensed, remote control software package derived from the popular VNC software. The binaries of TightVNC are unmodified and are included in the CrossLoop installation software. The CrossLoop website has a complete description of the interface between CrossLoop and VNC.

There are no back-doors in the CrossLoop application or server code.

(Back to top)

How can we block its usage on our network?

Blocking our server IP address would be an effective way of stopping the usage of CrossLoop on your network. Our application software must be able to contact the CrossLoop server using HTTP through port 80 during the rendezvous phase of our connection.

We certainly understand why your IT department would be concerned about unauthorized access to and from your network. However, CrossLoop cannot be operated remotely because it requires the presence of a person at both the Share and Access computers to make a connection. Presumably the person at the Share computer inside your network would be authorized. This person would need to allow a connection to be made from the Access computer.

(Back to top)

What is different about "Blowfish" encryption that makes it "more secure"?

We are aware that the 64-bit block size of Blowfish is considered short. This weakness has been exposed when encrypting more than 2**32 data blocks because it begins to leak information about the plaintext. Since our sessions involve considerably less than 33.6 Gigabyte data blocks (33.6 Gigabytes = 2**32 * 64-bit / 8-bit/byte) we do not regard this as a security risk for our users. We generate a new Access Code and produce a new symmetric key each time our application is run. We feel that the advantage of the extremely fast Blowfish algorithm and the credibility of Bruce Schneier have made Blowfish an excellent choice for our crypto.

(Back to top)

Why does the program open 3 different ports in my firewall?

We open additional UDP ports in our attempt to do P2P communication between Share and Access parties to avoid relaying through our server. If you only want port 80 to be accessed then do a relay connection by holding down the ALT key when you press "Connect". Our port 80 access tunnels inside of HTTP POSTs.

(Back to top)

How do you ensure the data packets between the application and the Share are not intercepted?

Our encryption is done at the endpoints and is not exposed in plaintext anywhere during a session between the Share and Access computers. During relay connections our server has no access to the Blowfish encryption key. A man in the middle attack would not be possible without knowledge of the Blowfish encryption key.

(Back to top)

Does this program have protection against TCP flood and Denial of Service (DOS) attacks?

Since we don't require open TCP ports that anyone on the net can connect to (i.e. open to SYN flood attacks), we're not vulnerable. In fact we provide extra protection for the Share which is executing WinVNC because we allow only loopback (localhost on 127.0.0.1) connections. It is impossible for an outside computer to connect directly to WinVNC.

(Back to top)

Does your program have a method that I can use to prevent it from running at certain times?

Our program cannot run unattended. In other words, it will only run when you invoke it. If you push the "Connect" button as a Share party we time out after 2 minutes. If you are running something that you do not wish anyone connecting to your computer to see … do not run the Share, or if it is loaded, do not connect.

(Back to top)

How do you ensure only the invited application can connect?

The invited application must receive the Access Code from the Share via some out of band technique, e.g. over the telephone. The Share cannot run unattended and we purposely timeout the Share after two minutes. We expect there to be human conversation between the Access party and the Share party. When the Access party enters the Access Code received from the Share there is an Allow/Deny screen displayed at the Share. The Share must allow the connection to proceed before the Access party has access to the screen of the Share party.

We hash the symmetric key generated from the Access Code to produce a 32-bit session ID. This session ID is used for our rendezvous between the Share and Access party. It is a necessary condition but not sufficient condition to allow the invited application to connect because we encrypt a known message with the full 128-bit encryption key at the Access party and decrypt it at the Share end. There can only be a match if the Share party and Access party have the same 128-bit encryption key.

(Back to top)

Does VNC create security issues by opening a non-secure tunnel into our servers?

IT managers generally regard any VNC product to be a security risk because they require an open port on the server and communicate with unencrypted data between the application and the server. Typical VNC products (RealVNC, TightVNC, UltraVNC, etc.) all have the security problem in that they require an open port on the internet to operate as a host (running WinVNC or the equivalent). Furthermore, you must forward the VNC port requests to your computer from your firewall. This is a huge security risk, which is coupled with the absence of built-in encryption and poor authentication. From this perspective, the IT managers are correct about the security risks.

The CrossLoop Solution:
  • CrossLoop provides a secure wrapper around VNC operation.
  • VNC is configured so that it will only accept connections from localhost (127.0.0.1). This means that there are no open ports on to the Internet or LAN and that VNC will only accept connections from the computer on which it is hosted. There is no requirement to modify your firewall to forward VNC port requests to your computer. Our CrossLoop software acts as a proxy running on a localhost connection with VNC. CrossLoop has no inbound open ports and performs the rendezvous between the Share and Access applications by means of an HTTP POST to our server.
  • All communication between the VNCViewer (CrossLoop Access) and the WinVNC server (CrossLoop Share) are encrypted using Blowfish with a 128-bit encryption key. This communication includes both the authentication of the VNC connection as well as all of the screen/mouse/keyboard updates.
  • Unlike the normal VNC server, the CrossLoop Share cannot be operated remotely and does not support unattended sessions. It requires the presence of a person on the Share computer to accept the CrossLoop session request from the person doing the CrossLoop Access.
  • Each time CrossLoop is executed a unique 12-digit Access Code is generated for the session. This Access Code is hashed to generate the 128-bit encryption key used by Blowfish. Thus, each CrossLoop session has a different encryption key. This is unlike VNC in which the same authentication password is used for each connection.
Because there are no open ports on the application computers, CrossLoop is protected from SYN floods or other forms of DOS attacks. This would, for example, be possible with a traditional VNC server which opens a port through the firewall and sits there listening on a port. Since we don't require open TCP ports that anyone on the net can connect to (i.e. open to SYN flood attacks), we're not vulnerable. We provide extra protection for the Share which is executing WinVNC because we allow only loopback (localhost on 127.0.0.1) connections. It is impossible for an outside computer to connect directly to WinVNC.

(Back to top)

Home | About Us | Expert Sign Up | Download | Help | Helpers | Privacy | Terms
© 2006-2012 CrossLoop Inc. All Rights Reserved.