VNC

Threats and Countermeasures

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 original RFB protocol employed relatively weak authentication mechanisms and made no special provision 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 session hijacking and brute force password attacks attacks. The Dataplane.org VNC daemon is helping to monitor and combat this threat.¹

This white paper is another in a series to help educate and foster security best practices within the Internet community. Below we discuss common VNC threats and countermeasures.

VNC Authentication and Transport Weaknesses

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 5900 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 over 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:

• Configure the VNC server to only listen on the loopback interface and address (i.e. 127.0.0.1 for IPv4 or ::1 for IPv6).
• Run an SSH server on the VNC server host. Be sure to consider the threats and countermeasures for an SSH server. The Dataplane.org SSH Password Authentication: Threats and Countermeasures white paper may be of some help here. ³
• Establish an SSH session that forwards a local port on the VNC viewer to the loopback address and listening VNC port on the server. For instance, if the VNC server is listening on 127.0.0.1:5900 then 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 protected].
• Finally, in the VNC viewer client application specify 127.0.0.1 as 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 original and inherently weak RFB authentication mechanism and to always tunnel RFB sessions inside an encrypted channel.

Monitoring and Alerting

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

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 5900. 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.

Crypto + VNC traffic inspection

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.⁵

Syslog

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.

Community alerts and notification

As far as we are aware, the Dataplane.org vncrfb.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.⁷⁸

Tools

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.

Dataplane.org VNC server daemon ¹

This is a small, fake VNC server daemon coded in Perl with syslog support, developed by Dataplane.org.

fakevnc ⁹

A small, fake VNC server coded in Python with syslog support.

Ncrack ¹⁰

Brought to you by the developer of Nmap, Ncrack performs brute force attacks against a handful of common application services including VNC.

THC-Hydra ¹¹

The Hacker’s Choice tool is another brute force attack tool that includes support for VNC attacks.

VNCrack ¹²

Phonelit VNC cracking tool does remote and offline cracking.

Medusa ¹³

This brute force attack tool from Foofus.Net includes support for VNC.

Crowbar ¹⁴

Another brute force tool that includes support for VNC authentication.

Shodan ¹⁵

A search engine for Internet services such as known VNC server listeners. Requires an account some queries.

Commentary on filtering

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.¹⁶

Conclusions

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. We welcome your comments, feedback, and support. Contact us.

Pointers to Other Resources

• Paresh Kerai published two papers detailing the forensics information left behind for a handful of VNC implementations on Microsoft Windows and mobile machines, which include some details about how the VNC implementations examined implement logging. His papers can be found here and here.
• As published in Internet Computing by the IEEE, the original developers describe VNC here.
• A community-oriented version of the RFB specification is on github.
• Yonathan Klijnsma has given some talks on his experience with an, as of this writing, an unreleased tool called HoneyVNC and his analysis of that VNC honeypot in the wild here and here.
• Martin van Hensbergen has given a talk on his experience using BRO to detect VNC services including background information on RFB and VNC service instances seen in the wild. His slide deck can be found here.