How to remediate – VNC Server Unauthenticated Access: Screenshot

1. Introduction

The VNC Server Unauthenticated Access: Screenshot vulnerability means a remote VNC server does not require a username and password to connect. This allows an attacker on the network to gain access to the system without permission. Affected systems are typically those running a VNC server for remote administration, often Linux or Windows machines. A successful attack could compromise confidentiality through screenshot capture and potential further control of the affected host.

2. Technical Explanation

The vulnerability occurs because the VNC server is configured with no authentication enabled. This allows anyone who can reach the port used by the VNC server to connect directly. An attacker could use a standard VNC client to connect and view the screen, potentially capturing sensitive information or gaining control of the system. There are no known CVEs specifically for this configuration issue; it’s a misconfiguration rather than a software flaw.

• Root cause: The VNC server is configured without any security type enforced.
• Exploit mechanism: An attacker connects to the VNC server’s port (typically 5900 or 5901) using a VNC client. No credentials are required, and the connection is established immediately.
• Scope: Systems running RealVNC, TightVNC, UltraVNC, or other VNC server software with no authentication enabled.

3. Detection and Assessment

You can check if a system is vulnerable by attempting to connect using a VNC client without providing credentials. A thorough method involves port scanning and configuration review.

• Quick checks: Use a VNC client (like Remmina or TightVNC Viewer) and attempt to connect to the target IP address and port (5900/5901) without entering any username or password. If connection succeeds, it is vulnerable.
• Scanning: Nessus plugin ID 16827 can detect unauthenticated VNC servers. OpenVAS also has relevant checks. These are examples only.
• Logs and evidence: Check the VNC server logs for successful connections without authentication. Log locations vary by VNC software; consult the vendor documentation.

vncviewer 

4. Solution / Remediation Steps

The solution is to disable the ‘No Authentication’ security type and enforce a strong password or other authentication method.

4.1 Preparation

• Ensure you have access to the VNC server’s configuration files and can restart the service. A roll back plan is to revert the configuration file to its original state.
• A change window may be needed if this affects production systems; approval from system owners is recommended.

4.2 Implementation

1. Step 1: Open the VNC server’s configuration file. The location varies by software (e.g., /etc/vnc/config.d/vncserver-x11 for RealVNC on Linux).
2. Step 2: Locate the security options within the config file.
3. Step 3: Change the security type from ‘No Authentication’ to a password or other authentication method (e.g., VNC Password, PAM).
4. Step 4: Save the configuration file.
5. Step 5: Restart the VNC server service. For example: sudo systemctl restart vncserver-x11 on Linux.

4.3 Config or Code Example

Before

# /etc/vnc/config.d/vncserver-x11
SecurityTypes=NoAuthentication

After

# /etc/vnc/config.d/vncserver-x11
SecurityTypes=VNCPassword

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limit access to the VNC server only to authorized users and systems.
• Practice 2: Secure defaults – configure VNC servers with strong authentication enabled by default, rather than no authentication.

4.5 Automation (Optional)

Automation is possible using configuration management tools like Ansible.

---
- name: Ensure VNC server has password authentication
  lineinfile:
    path: /etc/vnc/config.d/vncserver-x11
    regexp: '^SecurityTypes=NoAuthentication'
    line: 'SecurityTypes=VNCPassword'
  become: true
  notify: Restart VNC Server
- name: Restart VNC Server
  service:
    name: vncserver-x11
    state: restarted
  become: true

5. Verification / Validation

Confirm the fix by attempting to connect with a VNC client and verifying that authentication is now required.

• Post-fix check: Use a VNC client and attempt to connect to the target IP address and port (5900/5901). The client should prompt for a username and password.
• Re-test: Repeat the quick check from Section 3; connection attempts without credentials should now fail.
• Smoke test: Verify that authorized users can still connect to the VNC server using their new credentials.
• Monitoring: Check the VNC server logs for authentication attempts and successful connections. Look for failed login attempts if you suspect brute force attacks.

vncviewer 

6. Preventive Measures and Monitoring

Update security baselines to enforce strong authentication on VNC servers.

• Baselines: Update your security baseline or policy to require password authentication for all VNC server deployments. For example, a CIS control related to remote access configuration.
• Pipelines: Include checks in CI/CD pipelines to scan for insecure VNC configurations during deployment.
• Asset and patch process: Review VNC server configurations regularly as part of your asset management and patching cycle.

7. Risks, Side Effects, and Roll Back

Changing the security type may disrupt existing connections if users are not aware of the new authentication requirements.

• Risk or side effect 1: Existing VNC clients may need to be reconfigured with the new credentials.
• Risk or side effect 2: Incorrect configuration could prevent all access to the VNC server.
• Roll back: Restore the original VNC server configuration file from your snapshot. Restart the VNC server service.

8. References and Resources

Links only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: RealVNC Security Considerations
• NVD or CVE entry: Not applicable, as this is a configuration issue rather than a specific vulnerability.
• Product or platform documentation relevant to the fix: RealVNC Security