Virtual Network Computing (VNC) is a technology which enables one or more clients (aka viewers) to control a remote computer system. VNC is a cross-platform tool popular for remote systems support and administration over IP networks. The remote framebuffer (RFB) protocol, the underlying specification upon which VNC relies, and the varied VNC implementations have a mixed track record. The RFB protocol employs a relatively weak authentication mechanism and makes no special provisions for encrypting sessions between the viewer and server. Many administrators and many systems, including many virtual machine (VM) environments, have VNC deployed in networks with insufficient safeguards. While VNC implementations and deployments can easily improve upon VNC's native authentication and transport security, many VNC installations by default do not and therefore may be susceptible to brute force password attacks and session eavesdropping. The Dragon Research Group (DRG), through the use of tools such as the DRG Distro are helping to monitor and mitigate this threat. This white paper is another addition in a series to help educate and foster security best practices within the Internet community. Below we discuss common VNC threats and countermeasures.
The remote framebuffer (RFB) protocol is used by VNC to setup and manage
a remote control session between a client and server over TCP. The IANA
reserved and commonly used server port for VNC is
although other ports are often used in certain configurations. In
practice there is a only a single VNC authentication handshake security
type commonly in use as defined in section 7.2.2 of IETF RFC
6143. In this scheme, as
specified in IETF RFC 6134:
"The client encrypts the challenge with DES, using a password supplied by the user as the key. To form the key, the password is truncated to eight characters, or padded with null bytes on the right."
IETF RFC 6134 continues:
"This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel provided by IPsec [RFC4301] or SSH [RFC4254]."
This specified authentication mechanism is weak in two ways. First, notice that the specification limits a password to eight characters. This is a relatively few number of bits by modern standards, making a brute force password attack feasible with modest hardware. Second, because only the password is used as the key to DES, an eavesdropper could feasibly conduct a password cracking attack on the client's response to the challenge, possibly using a precomputed dictionary to speed the attack under certain conditions. The text from the specification above also hints at a third security issue. The RFB protocol makes no special provision to ensure secrecy of the VNC session data, furthering the risk of eavesdropping attacks.
The specification suggests, but perhaps not strongly enough, that users ought to run VNC on top of a another specification such as IPsec or SSH. Running VNC on top of SSH is a popular, easy and reasonable approach to protecting VNC access and sessions. We illustrate this method using OpenSSH to improve VNC's access control and transport privacy:
127.0.0.1for IPv4 or
127.0.0.1:5900then on the viewer machine an OpenSSH client can connect to the SSH server using the following syntax:
ssh -L5900:127.0.0.1:5900 email@example.com.
127.0.0.1as the destination address to the VNC server and the destination port as
5900. As long as the SSH session is established, all VNC RFB messages should be carried over the existing SSH channel.
Fortunately, many VNC implementations do include support for enhanced authentication and encryption. While the number of VNC implementations prohibits us from enumerating all options and solutions, it should be possible to either first manually wrap VNC sessions in an IPsec, SSH or SSL tunnel, or make use of advanced authentication and encryption services provided by the VNC software provider or through a third party plug in. We strongly advocate that VNC users never rely on the inherently weak RFB authentication mechanism and to always tunnel RFB sessions inside an encrypted channel.
In this section we briefly discuss four general areas that offer additional insight and ability to alert an administrator about VNC probes and attacks. Each offers their own unique perspective on probe events or attacks. Not all sites need to make full use of each, but having multiple views of your landscape improves your ability to detect and respond. Each category consists of an approach that has been widely implemented in other networks. Other systems and processes are possible, including many packages available from commercial vendors. However, in each section below, use of these subsystems can generally be done with little to no additional cost except for the time required for setup and management.
Netflow was a concept originally developed by Cisco to summarize network
traffic traversing routers.
Today it is widely implemented in many vendor hardware platforms as well
as a general tool to summarize network traffic by other means. There
are a number of tools available for Netflow collected data. Using them
for VNC probe monitoring is relatively straightforward since generally
VNC attacks occur over the IANA registered TCP port
However, web-based VNC, is typically implemented as a Java application
and often run over TCP port
5800 by default. Furthermore,
if the VNC server supports multiple displays, such as in a VM
environment, additional port listeners may be active, one for each
display. Generally VNC servers simply increment by one the starting
port number for each additional display. Netflow tools are good at
monitoring and alerting on well known traffic characteristics such as
these. Furthermore, you can use Netflow to monitor for TCP VNC traffic
from your hosts since a successful brute force attack may result in the
compromised system becoming part of a larger brute force attack network.
Ideally, VNC traffic will be wrapped inside another protocol that handles authentication and encryption. In the case of SSH-wrapped VNC traffic, unless you are witnessing multiple TCP connection attempts, which may indicate a brute force attack taking place over the secure channel, identifying threats may be limited and even then still look much like other interactive sessions. Similarly, IPsec, SSL or other mechanisms may or may not have VNC traffic running over one of the common ports, if you could even see the TCP session data at all. You may be able to identify key and certificate exchanges, which can provide clues into the identify of the viewer and server. Here again, multiple TCP connection attempts or unique flow characteristics over short intervals may indicate a brute force attack occurring on the secure channel. Ultimately however you may need to be able to identify and verify that the communicating end hosts are in fact witting parties by other means. Perhaps of most interest to the network administrator is identifying VNC RFB traffic that is not wrapped inside another secure protocol. There are a number of tools that examine network traffic and are able to identify particular applications such as VNC irregardless of the port used. This approach may be helpful not only for identifying legitimate, unprotected VNC sessions, but to also uncover trojans or compromised machines running otherwise hidden VNC back door servers.
Few VNC server implementations devote much effort to ensuring VNC communications can be logged with varying degrees of verbosity to a remote syslog server. When the VNC server is used on a system that does not tend to utilize a centralized logging facility, such as many Microsoft Windows hosts, the ability to monitor VNC server logs, if they even exist, can be difficult if not impossible. If your VNC implementation supports some form of logging we recommend you use it and ensure logs are sent to another secure host for later analysis if the need should arise. Take note that logs may not indicate any specific user name or password attempted, since those credentials are not communicated explicitly during the typical RFB challenge/response authentication phase.
As far as we are aware, the DRG
vncprobe.txt report is the
only available source of specific VNC probe insight based on a custom
VNC application listener module that analyzes actual VNC session
attempts. Some organizations
provide TCP "scanner" events in a more general report, which may of
course include TCP protocol events on common VNC ports.
There are relatively few tools available that aim to help administrators both detect and respond to VNC probe threats. Most are of the type that help identify open and vulnerable VNC servers. We list a number of the tools we are aware of below. Note, we avoid including generic port scanning tools, but those may also be helpful to identify otherwise unknown VNC servers. CAUTION: Please use active probing and penetration testing tools responsibly.
Some networks actively packet filter a select set of applications based
on TCP protocol ports and in fact some networks filter TCP port
5900 traffic between their network and others. Filtering
on a specific port is at best an incomplete solution and depending on
how it's configured it may result in collateral damage to other,
unrestricted traffic. Most VNC server implementations allow the
listening port to be set to most any arbitrary value. A packet filter
that allows any unexamined TCP traffic may therefore be bypassed by a
savvy end user who configures a VNC server to use one of the allowed
ports. If the port filter blocks TCP packets irrespective of the
direction of the opening connection, benign traffic may be dropped if a
client-side application happens to select the filtered port as it's
ephemeral port. A network administrator should carefully consider the
implications of any filtering policy to optimally deny all the
undesirable traffic, while permitting legitimate traffic.
VNC threats have been known and seen in the wild for many years. The attack surface for many VNC servers is often insufficiently protected, but this rarely needs to be the case. Putting VNC authentication and session traffic on top of another system such as IPsec, SSH or SSL can nearly eliminate many anonymous VNC threats. The aim of any administrator should be to improve their monitoring, prevention, detection and response capabilities. The aim of this white paper was to help shed some light on VNC threats and countermeasures as a means to help improve your security posture in one or more of those four areas. If we can be of anymore help with actionable intelligence, please contact us at firstname.lastname@example.org.