VNC. RDP for all to see

TL;DR

• VNC still remains in some legacy environments due to legacy deployments and ease of use.
• Without proprietary extensions, VNC transmits data without encryption, making credential theft through packet sniffing possible.
• The captured challenge and response between a VNC client and server can lead to obtaining credentials.

Introduction

VNC (Virtual Network Computing) is a widely deployed service in perhaps forgotten corners of legacy enterprise networks. This is mainly because it’s a tried and trusted protocol that simply works, however this is disregarding its security flaws and disadvantages in the modern age.

A more well-known example could be the comparison between Telnet and SSH. Someone sitting in the middle of a Telnet transmission can essentially read all the information without any decryption, whereas SSH would require decrypting to the point it may not be effectively possible to intercept any useful data at all.

What is VNC and how is it used?

VNC is a remote desktop sharing technology that allows one to view and control another computer’s desktop over a network, created by Olivetti Labs in the late 90’s (later owned by AT&T). Based on the RFB (Remote Frame Buffer) protocol, now defined in RFC 6143, it was able to work across various operating systems such as Windows, Unix and Linux.

In practice, the service follows these steps in order to work:

1. The VNC Server runs on the machine you would like to control
2. VNC Client (Viewer) connects to that server over TCP/IP typically using port 5900 plus the display number
3. The server then sends compressed screenshots, also known as the frame buffer, back to the client.
4. The client then sends back keyboard and mouse input.

Security risks

In the present day, there are a large number of security risks that could lead to varying directions and levels of compromise within a network:

• No Encryption: Simply put, the traffic between the server and the client is plaintext. If an attacker were able to intercept VNC network traffic, they would be able to see all data in a human-friendly form, compromising the confidentiality of the data in transit. There are extensions which can allow some versions to use encryption, usually by using an SSH or TLS tunnel.
• Weak Authentication: Some VNC servers only use an 8 byte DES encrypted password which is trivial to decode if the password hash is obtainable.
• NULL Authentication: Depending on the VNC implementation, it can be possible to connect without a password. There are also version specific exploits for this (spoiler alert).
• Screen Capture / Keylogging: Even if direct interaction is not possible, it is often possible to capture screen contents or keystrokes without detection. This is usually possible due to the lack of encryption with the VNC traffic.
• Internet Exposure: Internet tools like Shodan can identify publicly facing VNC instances which can have disastrous consequences if it becomes an access point for any critical system. However, the same can be said about any unencrypted protocol being internet facing.
• Weak Stored Passwords: most VNC clients store the passwords in a configuration file or in the registry, encrypted using DES and a static key. There are a number of tools to decrypt these passwords, including our own pwdecoder.

Intercepting and cracking VNC authentication

Just to really demonstrate how to exploit it I wrote a python script (VncCrack.py). It takes the VNC authentication challenge request along with the response and cracks the password in plaintext.

It should be noted that there are various configurations of VNC that are natively secure, which would make this type of attack either redundant or very difficult, such as:

• Tunnelling VNC over an SSH tunnel which protects credentials as well as data in transit.
• Enforcing strong passwords that are unlikely to be decrypted.
• Restrict network access to small, isolated networks. Never open VNC to the public domain.
• Use encrypted version of VN such as TigerVNC or the paid version of RealVNC.

Firstly, I fired up a target ubuntu virtual machine and installed the latest version of tightvncserver and started it, specifying the password as simply ‘password’. Once set up, I could see VNC running from my attack host:

What I am simulating now is a scenario whereby I am a malicious actor which has access to the network in question and can sniff the traffic, which we already know is plaintext.

Here I will log into the target host from my attack host, which could theoretically be any other device on the same network with wireshark running on the network (in this case eth0).

Once it has logged in, the damage is done and I can stop wireshark from intercepting any more.

In the wireshark output I am looking for two specific entries, the “Authentication challenge from server” and “Authentication response from the client” as shown below.

Here is what the challenge looks like:

Here is what the response looks like:

Now we have all the tools we need to crack the password. In the script, I included a list of a few passwords, knowing the real password is ‘password’. In the real world, an extensive password list would likely be required.

Conclusion

We have gone over a few of the downfalls of VNC as well as demonstrating how comically easy it is to obtain a password simply from having network access to both the VNC server and client. As a result of this, the configuration and type of VNC in use should be scrutinised  in order to prevent exploitation. On Linux,  XRDP can be used, as it supports transport encryption, credential protection (with TLS enabled) and runs as non-root. However, it does not support NLA (Network-Level Authentication) like Windows RDP.

There are secure versions of VNC, such as the commercial version of RealVNC that tunnel VNC through an encrypted tunnel.