近期大家对于VNC（Virtual Network Computing）远程登录系统软件干了有关科学研究，在文中中，大家将与大伙儿共享这些方面科学研究結果。大家发觉了一些运行内存毁坏漏洞，一共取得了37个CVE序号。在其中一些漏洞假如被攻击者运用，很有可能会完成远程控制代码执行实际效果。

0x01 选题背景

VNC系统软件能够协助一台机器设备远程登录另一台机器设备的显示屏，必须留意的是，协议书标准中并沒有限定特殊电脑操作系统，容许混合开发完成。VNC在很多电脑操作系统上都是有相匹配的完成版本，包含GNU/Linux、Windows、Android及其别的一些冷门系统软件。

因为混合开发完成及其许可证书开源系统，如今VNC早已是最常见的一种远程访问专用工具。依据shodan.io统计分析，互联网技术上最少有600,000台VNC *** 服务器线上。假如再算上仅在本地连接中能用的机器设备，这一数据可能越来越更加巨大。

依据大家的数据统计，VNC广泛运用于工业生产自动化技术中。近期大家公布了一篇文章，详细介绍了远程访问专用工具在工业生产自动控制系统（ICS）中的运用。依据文章内容可能，大概有32%的工业自动化系统电脑中安裝了包含VNC以内的各种各样远程访问专用工具（RAT）。在其中18.6%的ICS手机软件发售库中包括RAT，且会在程序安装时顺便安裝，剩余81.4%的RAT则由职工或承包单位手动式安裝。在另一篇文章中，大家剖析了一些进攻方式，在其中攻击者会安裝并应用一些远程访问专用工具。除此之外在一些状况下，攻击者还会继续在进攻全过程中运用远程访问专用工具中的一些漏洞。

依据大家的可能，大部分ICS厂商会在商品中根据VNC来完成远程访问专用工具，因而对VNC安全系数的剖析就看起来至关重要。

2019年，Windows RDP（Remote Desktop Services）被曝存有BlueKeep漏洞（CVE-2019-0708），造成了群众的强烈反应。假如Windows服务器上已经运作RDP *** 服务器，那麼该漏洞就容许未受权攻击者得到该服务器的远程控制代码执行管理权限。该漏洞危害“较早版本的”电脑操作系统，例如Windows 7 SP1、Windows 2008 Server SP1及SP2。

在Windows中，有一些VNC服务端组件以服务项目方式存有，能够出示高管理权限浏览服务项目，这代表着这种组件自身就具有系统软件的高访问限制。这也是大家科学研究VNC安全系数的缘故之一。

0x02 系统软件叙述

VNC（Virtual Network Computing）是出示浏览总体目标系统软件客户插口（桌面上）的一种系统软件。VNC应用RFB（remote frame buffer，远程控制帧缓冲区域）协议书，在机器设备中间传送显示屏图象、电脑鼠标挪动及电脑键盘恶性事件。一般 状况下，每一个系统软件的完成都包含一个服务端组件及客户端组件。因为RFB协议书是规范化协议书，因而不一样完成版本的客户端及服务端中间能够互相通讯。服务端组件将服务端的桌面上图象发送到客户端，供客户端查询。客户端会将客户端的恶性事件（例如鼠标光标挪动、功能键、数据信息复制及黏贴）根据裁切缓冲区域（cut buffer）推送回 *** 服务器。根据这类 *** ，假如远程控制服务器已经运作VNC服务端，客户端上的客户就可以操纵远程控制服务器。

每每远程控制服务器的桌面上升级时，VNC服务端都是会推送图象。升级实际操作很有可能在许多状况下产生，在其中就包含客户端的实际操作。根据互联网推送全新升级的详细截屏显而易见是相对性较为消耗資源的一种实际操作，因而协议书沒有推送全部屏幕截屏，只是只升级由于一些实际操作或随時间更改的相对清晰度。RFB还适用多种多样显示屏升级制冷压缩机编码方式，例如，协议书能够应用zlib或是RLE（run-length encoding，行程安排编号）开展缩小。

尽管此软件原本的应用领域较为确立，但由于包括十分多的作用，因而开发人员在产品研发环节很有可能会出現一些疏漏。

0x03 很有可能的加强攻势

因为VNC系统软件由服务端及客户端组件构成，因而我们可以思索以下2个关键的加强攻势：

1、攻击者与VNC服务端处在同一个互联网中，进攻服务端取得成功后，能够应用服务端管理权限在总体目标服务器上实行编码。

2、客户应用VNC客户端联接至攻击者的“服务端”，攻击者运用客户端中的漏洞来进攻客户，在客户服务器上实行编码。

显而易见，攻击者更喜欢在服务端上得到远程控制代码执行管理权限。殊不知，已发觉的大部分漏洞都坐落于系统软件的客户端组件中。一部分缘故是由于客户端组件必须包括特殊编码，用于编解码服务端推送的各种各样文件格式的数据信息。开发人员在撰写数据信息编解码组件时，常常易犯各种各样不正确，造成出現运行内存毁坏漏洞。

另一方面，服务端的编码量相对性较少，只必须向客户端推送历经编号的显示屏升级数据信息，解决来源于客户端的恶性事件就可以。依据协议书标准，服务端务必适用最少6种信息种类，以出示一切正常实际操作需要的全部作用。这代表着大部分服务端组件基本上沒有尤其繁杂的作用，进而降低了开发人员出错的机遇。殊不知，一些系统软件中完成了各种各样组件，用于提高服务端的作用（例如文件传送、客户端与服务端闲聊等作用）。大家的研究表明，大部分难题都出現在服务端的提高作用中。

0x04 研究方案

在本次科学研究中，大家挑选了最普遍应用的几类VNC完成版本：

1、LibVNC。这是一个开源系统混合开发库，用于建立根据RFB协议书的自定运用。例如，VirtualBox应用了LibVNC的服务端组件来出示vm虚拟机的VNC浏览作用。

2、UltraVNC。它是适用Windows平台的比较时兴的开源系统VNC完成计划方案。很多工控自动化企业会提议客户（如[1]及[2]-?dti=0&lc=en-WW)）应用该计划方案，根据RFB协议书联接到远程控制HMI插口。

3、TightVNC。RFB协议书的另一种常见完成计划方案。很多工业生产自动化技术生产商强烈推荐客户应用该商品从*nix服务器联接到HMI插口。

4、TurboVNC。一种开源系统VNC完成，应用libjpeg-turbo库来缩小JPEG图象，以提升图象传送高效率。

在此次科学研究中，大家并沒有剖析十分火爆的一款商品（RealVNC），由于该商品的许可证书不允许大家对其开展逆向分析。

0x05 现有科研成果

在剖析VNC实际完成以前，我们可以先搜集有关原材料，看这种商品中以前出現过什么漏洞。

2014年，Google Security Team公布了一份较短的LibVNC漏洞数据分析报告。因为该商品的编码量较少，因而大家觉得Google技术工程师早已找到LibVNC中存有的全部漏洞。殊不知，我还是在GitHub上找到一些issue（例如[3]及[4]，这种issue时间点都是在2014年以后）。