C/S架构应用的漏洞流量特征分析之：RealVNC RFB协议远程认证绕过漏洞（CVE-2006-2369）

启明星辰金睛安全研究团队 2020-06-30

5412

标题中的C/S架构应用漏洞，代表的是其狭义的定义，即区别于Web漏洞对应的B/S架构（虽然B/S架构也算是C/S架构的一种特例）的漏洞，其漏洞应用一般具有其专用的传输层、应用层协议，如VNC、TLS等。

本文从一个简单的经典漏洞入手，记录对其流量特征进行分析的过程与思路，可作为相关漏洞流量特征分析的入门参考。

一、基本信息

漏洞编号：CVE-2006-2369

漏洞描述：VNC(Virtual Network Computing)是基于RFB（Remote Frame Buffer）协议进行通信的，是一个基于平台无关的简单显示协议的超级瘦客户系统(Thin—Client).RealVNC VNC Server采用的RFB（远程帧缓冲区）协议允许客户端与服务端协商合适的认证方法，协议的实现上存在设计错误，远程攻击者可以绕过认证无需口令实现对服务器的访问。

漏洞影响范围：RealVNC <4.1.1

二、漏洞复现

搭建漏洞环境，采用Kali系统中自带的msf框架里的对应modules进行攻击：

VNC的端口一般从5900开始，桌面号0的端口是5900，桌面号1的端口是5901。设置好攻击目标等参数，run。

三、流量分析

对VNC协议与漏洞版本的服务端处理逻辑的进行分析，可知触发漏洞的具体的交互细节如下：

1) 服务端发送其版本“RFB003.008\n”

2) 客户端回复其版本“RFB 003.008\n”

3) 服务端发送2个字节，第1个字节指定所提供安全类型的数量（在这里为1个）

3a) 随后的字节数组中说明了所提供的安全类型

这里服务端向客户端说明，服务端仅提供了1种安全类型，且为“Type 2 – VNC Authentication”，也就是说需要口令验证。

4) 客户端回复1个字节，从3a的数组中选择安全类型

漏洞点就在这里，RealVNC 4.1.1或之前版本在实现RFB 003.008协议时没有检查判断在上面第4步中客户端所发送的字节是否为服务器在3a步中所提供的，因此认证就从服务端转移到了客户端。攻击者可以强制客户端请求“Type 1 - None”为安全类型，无需口令字段便可以访问服务器。

如下图，可以看到客户端无视服务端之前的消息，强制选择了0x01的安全类型，也就是None，使得绕过了权限验证，直接与服务端建立VNC连接。

5) 执行握手，服务端返回“\x00\x00\x00\x00”，表示认证成功.

四、总结

分析C/S架构应用相关漏洞的流量特征，首先需要了解其对应的协议本身。类似的经典漏洞还有OpenSSL心脏出血漏洞(CVE-2014-0160)，对应的协议为TLSv1.1协议。

如图，心脏出血漏洞利用的流量，在payload length字段会填入一个大于\x0400的值。至于这里为什么能确定填入大于\x0400的值就是攻击利用，请听下回分解。

文章转载自启明星辰金睛安全研究团队，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论