How to remediate – VNC HTTP Server Detection

1. Introduction

VNC HTTP Server Detection indicates a system is running Virtual Network Computing software, allowing remote graphical access. This presents a security risk as VNC can be exploited for unauthorised control of systems if not properly secured. Systems commonly affected are servers and desktops used for remote administration or support. A successful exploit could compromise confidentiality, integrity, and availability of the host system.

2. Technical Explanation

VNC uses the RFB protocol to transmit screen updates and user input over a network connection. The default configuration often lacks strong authentication and encryption. An attacker can attempt to connect to the VNC server without valid credentials, potentially gaining access if weak passwords are used or no password is set. There isn’t a specific CVE associated with simply *running* VNC; risks relate to insecure configurations. For example, an attacker could use a brute-force tool to guess VNC passwords and gain control of the remote system.

• Root cause: Weak or missing authentication on the VNC server.
• Exploit mechanism: An attacker attempts to connect using common credentials or performs a brute-force attack against the password.
• Scope: All systems running VNC software, including Windows, Linux and macOS.

3. Detection and Assessment

Confirming a vulnerable system involves checking for listening VNC ports and identifying the VNC version. A quick check can identify if the service is exposed; thorough methods involve banner grabbing.

• Quick checks: Use netstat -tulnp (Linux) or Get-NetTCPConnection | Where-Object {$_.LocalPort -eq 5900} (PowerShell) to check for processes listening on port 5900, the default VNC port.
• Scanning: Nessus plugin ID 16827 can detect exposed VNC services. This is an example only.
• Logs and evidence: Check system logs for VNC connection attempts or errors. Log file locations vary by operating system and VNC server implementation.

netstat -tulnp | grep 5900

4. Solution / Remediation Steps

Fixing this issue involves securing the VNC service or disabling it if not required. These steps ensure remote access is controlled and protected.

4.1 Preparation

• Ensure you have alternative methods of accessing the system in case of issues. A roll back plan involves restoring the snapshot or restarting the service with its original configuration.
• Changes should be made during a scheduled maintenance window, approved by the IT security team.

4.2 Implementation

1. Step 1: Set a strong password for the VNC server. This is usually done through the VNC server’s configuration file or GUI settings.
2. Step 2: Enable encryption on the VNC connection, if supported by your VNC server.
3. Step 3: Restrict access to specific IP addresses or networks using firewall rules.

4.3 Config or Code Example

Before

# /etc/vnc/config.d/vncserver-x11
# No password set, allowing anonymous access

After

# /etc/vnc/config.d/vncserver-x11
Password=your_strong_password
SecurityTypes=VNCAuth

4.4 Security Practices Relevant to This Vulnerability

Several security practices can mitigate this risk. Least privilege limits the impact of exploitation, while strong authentication prevents unauthorised access.

• Practice 1: Implement least privilege by granting VNC users only the necessary permissions.
• Practice 2: Enforce strong password policies for all accounts, including those used with VNC.

4.5 Automation (Optional)

# Example Ansible playbook snippet to set a VNC password
- name: Set VNC password
  copy:
    dest: /etc/vnc/config.d/vncserver-x11
    content: |
      Password={{ vnc_password }}
      SecurityTypes=VNCAuth
  notify: Restart VNC server
# Handler to restart the service
- name: Restart VNC server
  service:
    name: vncserver
    state: restarted

5. Verification / Validation

Confirming the fix involves checking that a strong password is required and encryption is enabled. A negative test should fail to connect without valid credentials.

• Post-fix check: Attempt to connect using an invalid password; connection should be refused.
• Re-test: Run netstat -tulnp | grep 5900 and confirm the service is still running, but now requires authentication.
• Smoke test: Verify a legitimate user can successfully connect to the VNC server with their credentials.
• Monitoring: Monitor system logs for failed connection attempts, indicating potential brute-force attacks (example query: grep “VNCAuth” /var/log/syslog).

vncviewer :5900 # Should prompt for password

6. Preventive Measures and Monitoring

Preventive measures include updating security baselines and implementing regular patch cycles. For example, ensure VNC is not exposed to the public internet unless absolutely necessary.

• Baselines: Update your system’s security baseline to require strong passwords for all remote access services.
• Pipelines: Include checks in CI/CD pipelines to prevent deployment of systems with default or weak VNC configurations.
• Asset and patch process: Review VNC server configurations during regular asset audits and apply security patches promptly.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Existing VNC connections may be terminated when a new password is set.
• Risk or side effect 2: Incorrectly configured encryption can lead to performance issues.

8. References and Resources

• Vendor advisory or bulletin: Check your VNC server vendor’s website for security updates and best practices.
• NVD or CVE entry: While there isn’t a specific CVE for running VNC, search the NVD database for vulnerabilities related to your specific VNC server version.
• Product or platform documentation relevant to the fix: Refer to your VNC server’s official documentation for instructions on setting passwords and enabling encryption.