入侵检测系列1(中)基于私有协议的加密流量分析思路(Teamviewer篇)

阅读量    1111529 | 评论 1

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

写在前面

在上篇文章中,我主要从私有协议的分析方式开始,通过抓取TeamViewer包观察其流量行为,从日志中获取协议的各个行为入手,对协议各个流程进行分解。

详情见:

入侵检测系列1(上):基于私有协议的加密流量分析思路(Teamviewer篇)

https://www.anquanke.com/post/id/223106

本文将继续对协议流程进行分解,包括对登陆行为分析(这里指本机连接至Server),发出连接请求,成功连接,两台机器间的通讯和一些其他操作进行解析,并在最后附上协议流程的时序图。受篇幅限制,关于TeamViewer的加密与身份验证内容将在下篇文章中详细讲述。

 

2.1 协议流程:登陆行为分析 (接上文)

Mater Server 与 KeepAalive

与MasterServer不同,KeepAliveServer拥有自己的TeamViewer网络ID:返回路由器Ping时,它们包含 Ping所经过的网络跃点列表 (通常仅包含初始发送者的ID和KeepAlive服务器的ID)。

KeepAlive Server

本机TeamViewer连接到KeepAlive Server,并完成与master的登录后完成客户端到TeamViewer的所有连接。这个时候还是没有执行任何密钥交换或者加密的状态。此时,TeamViewer状态栏显示本机客户端“连接准备已就绪(安全连接)”。

2.2 协议流程:本机TeamViewer发出请求连接

心跳包(keepalive server)用于维持在线状态。本机TeamViewer连接对方TeamViewer时候会发出心跳用于与对方TeamViewer进行通信、协商连接。本机TeamViewer登陆时候TeamViewer采用CMD_MasterCommand 命令,通过master服务器传出连接信息。

CMD_MASTERCOMMAND

设备使用此命令来告知TeamViewer master服务器已准备好进行通信。里面包含了登陆动作logging=1,mid, mac地址,licensecode,tv版本号等。

在这一阶段,本地TeamViewer开始建立与对方TeamViewer的连接。客户端会根据系统发送的指定硬件数据在Server生成唯一的客户端ID,也就是说它在同一台PC上的所有TeamViewer ID都是固定的。ID在CMD_MASTERCOMMAND阶段生成,CMD_MASTERCOMMAND包含主网络接口的(en0)MAC地址和计算机的序列号。

CMD_MasterCommand 到master的请求连接 。请求参数包括以下内容:

MID =系统唯一ID(如上所述)
ID =客户端ID
ID2 =目的地ID
v =客户端版本
ic =未知

os = 当前操作系统

如果结果为 CONNECT ,则表示目标有效,并且当前已连接到KeepAlive服务器。此时,KeepAlive服务器将向目标发送一个 CMD_RequestConnect 来启动连接。CONNECT响应还将包含目标端点的RSA 公钥。 NOROUTE_KeepAliveLost 表示该ID在某个时候有效,但是本机不再连接到KeepAlive服务器(即TeamViewer目前未运行)。 NOROUTE_IdNotFound 表示该ID永远无效。

CMD_MASTERRESPONSE
这是对响应CMD_MASTERCOMMAND,在16年的版本中,它含有配置。该配置信息中包含服务器名称及其对应的IP地址,标识符以及源端口和目标端口对的列表。这些列表使得设备了解以后要与哪些服务器通信。在19年和20年的版本,它只返回了本机ID和对方的ID,在第二次返回的时候返回OK表示是否识别到对方ID。

所以我们在pcap看到的动作如下:

CMD_IDENTIFY
这是设备用来向基础结构标识自己的另一条消息。再次,我们看到与TeamViewer应用程序关联的九位数字标识符,但是我们还看到了其他字段,这些字段为基础结构的非主要部分提供了有关设备的其他信息。

此时TeamViewer协商过程如下:

CMD_BUDDY

从图中,我们可以知道TeamViewer通过发送Buddy命令至KeepAliveServer。通过Buddy来确认KeepAliveServer存活状态、网络是否可达。Buddy命令其实与许可证相关,比如,某个客户违反免费许可证条例时,客户将被列入黑名单,即显示的是连接未就绪,它会要求用户使用商业模式。

2.3 协议流程:成功连接

CMD_IDENTIFY
这是本机TeamViewer用来标识自己的另一条消息。同时,我看到本机TeamViewer的9位数字的身份ID,除此之外还看到了其他字段,这些字段作为本机信息的非主要部分向对方提供了本机TeamViewer的其他信息。

根据多次对同一版本和不同版本的TeamViewer进行抓包,我发现这个CMD_IDENTIFY是流量检测中识别TeamViewer是否成功连接对方的重要标志。它存在于每次TeamViewer成功连接后的第一个包。但由于版本的不同,他每次的hex也是不同的。所幸,这个包在多个版本中长度保持不变,为32,且均以17 24 0a 开头。

CMD_REQUESTCONNECT
该命令包含向对方设备发送请求连接的信息。在此数据包的内容中,我们看到了另一台设备的实际TeamViewer ID,一个连接ID(可在通信的其他部分中用作参考),有时还包括发出请求的IP地址。

CMD_CONNECTTOWAITINGTHREAD

当请求与对方TeamViewer建立连接时,本机TeamViewer会接收这条消息。在16年的版本中,它包含发送设备的TeamViewer ID,TeamViewer基础结构使用的任何代理IP地址以及会话ID。在19年和20年的版本中,它的消息已经被加密。

2.4 协议流程:两台机器之间的通讯

在上文中,我们在pcap中是有看到udp流量的,很明显TeamViewer可以在UDP上运行。而且udp流量是从最后一个tcp后开始,称为CMD_UDPFLOWCONTROL。这里意味着,两台机器之间(尤其是位于不同专用网络上的设备之间)开始建立连接。为此,TeamViewer服务器提供了一些非常有用的数据:

a.另一端的目标IP地址(公共和一个或多个私有IP地址)

b.不同通信的目标端口

但是,读者们可能已经注意到UDP数据包(上面的蓝色)没有为其协议标记为TEAMVIEWER。原因是因为TeamViewer创建的UDP消息在内容的开头插入了其他空字节,从而更改了标头。

上面的CMD_UDPPING可以验证现在所使用IP和端口是否可以将消息传送到达目标IP。当我尝试访问不在同一网络上的TeamViewer PC时,只看到公有IP地址。

一旦设备尝试通过UDP开始通信(即完全避开TeamViewer 的TCP流量),我们就能够了解通信双方的公有IP地址和私有IP地址,以及它们使用的通信端口。此外,我们可以根据成功后的通信包来识别对方IP所处网络位置(内外网)。

2.5 协议流程:一些其他操作

我们知道,在两台机器成功连接后,我们可以对对方机器进行一些操作,比如可以远程锁定屏幕或切换控制发生的方向。这些行为似乎与CMD_CARRIERSWITCH相关。

另外,整个连接(传入和传出)过程涉及master server,KeepAlives Server(传入端)和它们都连接到的网关服务器。一旦它们都连接并且建立会话,就可以发现它们之间通讯使用的Data4数据包。

成功连接示意图:

2.6 协议流程: 总结

综上所述,整个TeamViewer 的通讯流程如下时序图所示:

 

3 TeamViewer 的加密与身份认证

首先我们来看看他的整个加密与身份认证流程:

3.1 加密流量

TeamViewer流量使用RSA公钥/私钥交换和AES(256位)会话进行加密保护。这项技术在https/SSL中有着可比性,在当今的安全标准中被认为是最安全的。由于私钥永远不会离开客户端计算机,所以整个过程可以确保互连的PC(包括TeamViewer路由服务器)都无法解密流量。

3.2 身份验证

每台TeamViewer客户端都使用了主集群(master cluster )的公钥,因此可以对主集群的消息进行加密,并检查由它签名的消息。PKI(Public Key Infrastructure,公钥基础设施)有效地防止了中间人攻击,尽管加密了密码,但密码从不直接发送,而是通过响应返回,并且只保存在本地计算机上。在身份验证过程中,由于使用了安全远程密码(SRP)协议,因此不会直接传输密码。本地计算机上只存储一个密码验证器。在身份验证过程中,由于使用了安全远程密码(SRP)协议,因此不会直接传输密码,而是在本地PC上存储了码验证器。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多