How to remediate – VNC Server Unauthenticated Access

1. Introduction

The VNC Server Unauthenticated Access vulnerability means a remote user can connect to a system using VNC without needing a username and password. This allows attackers to gain control of affected machines, potentially stealing data or installing malware. Systems running VNC server software are usually affected, especially those exposed directly to the internet. A successful exploit could compromise confidentiality, integrity, and availability.

2. Technical Explanation

The vulnerability occurs because the VNC server is configured without authentication enabled. An attacker can connect to the service without providing any credentials. This allows them direct access to the remote host’s graphical interface. Nessus may report this issue even if a login screen appears, as it cannot verify successful unauthenticated connection in all cases.

• Root cause: The VNC server is configured with no authentication security type enabled.
• Exploit mechanism: An attacker connects to the VNC server’s port (typically 5900) using a VNC client without providing credentials. If successful, they gain control of the remote desktop session. For example, an attacker could use RealVNC Viewer or TightVNC to connect directly to the target IP address on port 5900.
• Scope: Systems running any version of VNC server software with unauthenticated access enabled are affected.

3. Detection and Assessment

• Quick checks: Use telnet <target_ip> 5900 and look for any banner or response indicating no authentication is required.
• Scanning: Nessus vulnerability ID 16837 may identify this issue, but results should be manually verified.
• Logs and evidence: VNC server logs (location varies by distribution) may show connection attempts without valid credentials.

telnet 192.168.1.100 5900
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
VNC Server: Welcome message (indicates no authentication)

4. Solution / Remediation Steps

The solution involves disabling the “No Authentication” security type in your VNC server configuration.

4.1 Preparation

• Ensure you have alternative access methods available if needed, such as SSH. A roll back plan involves restoring the snapshot or reverting configuration changes.
• A change window may be required depending on your organisation’s policies. Approval from a system owner might be necessary.

4.2 Implementation

1. Step 1: Open the VNC server configuration file (location varies by distribution, often /etc/vnc/vncserver-x11-serviced).
2. Step 2: Locate the line specifying authentication options.
3. Step 3: Remove or comment out any lines enabling “No Authentication” security type.
4. Step 4: Save the configuration file.
5. Step 5: Restart the VNC server service (e.g., sudo systemctl restart vncserver-x11-serviced).

4.3 Config or Code Example

Before

Authentication=yes
SecurityTypes=None,VNCAuth

After

Authentication=yes
SecurityTypes=VNCAuth

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limit the user accounts that have access to VNC server configuration and control.
• Practice 2: Safe defaults – configure VNC servers with authentication enabled by default, rather than relying on insecure settings.

4.5 Automation (Optional)

If you manage multiple VNC servers using a configuration management tool like Ansible, you can automate the process of disabling unauthenticated access.

---
- hosts: vnc_servers
  tasks:
    - lineinfile:
        path: /etc/vnc/vncserver-x11-serviced
        regexp: '^SecurityTypes=None,VNCAuth'
        line: 'SecurityTypes=VNCAuth'
    - service:
        name: vncserver-x11-serviced
        state: restarted

5. Verification / Validation

• Post-fix check: Use telnet <target_ip> 5900 and verify that a username/password prompt is displayed.
• Re-test: Re-run Nessus vulnerability ID 16837 to confirm the issue is no longer detected.
• Smoke test: Verify you can connect to the VNC server using valid credentials.
• Monitoring: Check VNC server logs for failed connection attempts without authentication as an example alert.

telnet 192.168.1.100 5900
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
VNC Server: Username: (prompt indicates authentication required)

6. Preventive Measures and Monitoring

Update security baselines and implement checks in your CI/CD pipelines to prevent similar issues.

• Baselines: Update your security baseline or policy to require VNC server authentication as a standard setting (for example, using CIS benchmarks).
• Pipelines: Add static analysis tools to your CI pipeline that scan configuration files for insecure settings like “SecurityTypes=None”.
• Asset and patch process: Review VNC server configurations regularly as part of your asset management or vulnerability patching cycle.

7. Risks, Side Effects, and Roll Back

Disabling unauthenticated access may disrupt existing connections if users are not prompted for credentials.

• Risk or side effect 2: Incorrect configuration changes could prevent all VNC connections. Ensure you have alternative access methods available.
• Roll back: Restore the original VNC server configuration file from backup and restart the service.

8. References and Resources

Links to official advisories and documentation.

• Vendor advisory or bulletin: Check your VNC server vendor’s website for specific security recommendations.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2018-10021
• Product or platform documentation relevant to the fix: Refer to your VNC server’s official documentation for configuration instructions.