NICER Protocol Deep Dive: Internet Exposure of VNC

Last updated at Mon, 12 Oct 2020 13:14:48 GMT

Welcome to the NICER Protocol Deep Dive blog series! When we started researching what all was out on the internet way back in January, we had no idea we'd end up with a hefty, 137-page tome of a research report. The sheer length of such a thing might put off folks who might otherwise learn a thing or two about the nature of internet exposure, so we figured, why not break up all the protocol studies into their own reports?

So, here we are! What follows is taken directly from our National / Industry / Cloud Exposure Report (NICER), so if you don't want to wait around for the next installment, you can cheat and read ahead!

VNC (5900 & 5901)

It's really RFB, but weirdly, nobody calls it that.

TLDR

WHAT IT IS: Graphical desktop-sharing system that uses the Remote Framebuffer protocol to enable full keyboard-video-mouse interactivity on remote systems.

HOW MANY: 347,940 discovered nodes (looking at only 5900 and 5901.) 347,932 (99.99%) have fingerprinted versions.

VULNERABILITIES: At least 37, across all vendors with VNC products.

ADVICE: Don’t expose VNC to the internet directly.

ALTERNATIVES: Run VNC over an SSH tunnel if you must use VNC.

The Virtual Network Computing (VNC) service was created back in 1999 at the Olivetti & Oracle Research Lab (no longer active, thanks to AT&T) and uses the Remote Framebuffer (RFB) protocol to transport you to a desktop or server GUI far, far away. If you run macOS and use the “Screen Sharing” feature, you run and use a flavor of VNC. There are a dozen or so other vendors with their own, custom VNC client-server solutions, all built on the same underlying protocol.

Discovery details

Project Sonar found 347,940 VNC servers on the default port of 5900 and popular alternate port of 5901. If you’ve seen larger numbers from other sources (namely, the most excellent Kaspersky summary paper), those are very likely accurate, since VNC lives on many, many ports out in the wild west of the internet. For whatever reason, VNC implementations don't adhere too closely to their IANA-assigned port number as a design decision. That means you can use our numbers as an exposure baseline, but you may want to refrain from generalizing distributions by country or network too much, though our numbers indicate at least ~60% of VNC users tend to use the most common ports for the service.

OVH is in the lead here due to its “helpful” support page on “How to Access a Public Cloud Instance via VNC,” which includes the step of setting a password for the root user, since that’s what you log in as over VNC there. This is in violation of so many regulatory standards, it is sufficient to make our research team cry.

Amazon, too, goes out of its way to help you increase your attack surface, along with Alibaba and DigitalOcean. This likely explains their “top four” status in the cloud exposure view.

Exposure information

As is the case in a few other blog posts in this series, we need to take a moment to talk about business and residential ISP exposure for VNC, since it makes up a great deal of the total exposure. The following ISPs/providers garnered 30% of total discovered VNC nodes.

Stop us if you’ve heard this before, but these nodes are primarily businesses that want quick, remote access to something on their internal network or residential users who want to access internal home systems remotely.

Attempting to guess credentials in any way would violate the CFAA here in the U.S., and our researchers do not look good in orange, so we cannot say how many of these systems require logins, nor can we take screenshots of them since the resultant images may contain sensitive information and, therefore, be in violation of many regional privacy regulations.

Fifty-two percent of the discovered servers are running RFB version 3.8 (the most recently published RFB standard), followed by 19% running some flavor of macOS, making this protocol one of the few where Apple-manufactured computers are likely to show up in significant numbers. We even found a few dozen multi-function devices (the fancy word for printers these days) exposing their admin interface over VNC.

Attacker’s view

There have been many bugs in all flavors of VNC over the years, but the sort-of-good news is that most require an authenticated session to be effective. Having said that, there are over 8 billion credentials floating around on the “dark web” just waiting to be tried.

Just as with other services, we do not advertise VNC services in our Heisenberg honeypot network, so the above chart represents either opportunistic scanning or organization misconfigurations (i.e., trying to hit a once-owned VNC server in AWS, Google, or Rackspace that no longer sits at the IP address they thought it did).

The connection attempt counts are non-trivial numbers, so perhaps think twice before exposing VNC to the internet, and make sure you use patched VNC server code with ne’er-before-used, strong credentials backed by multi-factor authentication.

Our advice

IT and IT security teams should consider putting all VNC access behind a VPN connection or SSH tunnel and never expose VNC directly to the internet. Too many things can go wrong in the setup, care, and feeding of hosts with VNC access to make it safe for public internet use.

Cloud providers should stop encouraging the use of bare-naked VNC and come up with more secure and cost-effective solutions for their customers, such as VNC-over-SSH. Sure, there are some VNC client/server setups that offer enhanced security, but most of the tutorials and setup guides provide instructions that only really increase the attack surface of customers.

Government cybersecurity agencies should release regular guidance on how to safely use VNC, monitor VNC vulnerability disclosures and provide timely alerts, and encourage internet service providers to at least block VNC access on the default port (5900).