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

 

写在前面

在上篇文章中，我主要从私有协议的分析方式开始，通过抓取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上存储了码验证器。