入侵检测系列1（上）：基于私有协议的加密流量分析思路（Teamviewer篇）-安全客

写在前面：为什么会有这篇文章？

这是我刚入职天眼的时候拿到的第一个任务，前线安服反馈客户要求增加关于 TeamViewer 和向日葵连接【成功】的告警。当时，包括天眼在内，普遍厂商的规则都是只能检测心跳包的告警。众所周知，心跳包的产生，不能说明该应用的使用阶段；当企业安全管理人员想监管员工是否【使用】违规应用时，基于心跳包的检测并不能有效帮助企业内的监管人员监测到违禁应用的使用情况。

受文章篇幅限制，基于私有协议的加密流量分析思路(Teamviewer篇)将分为几篇来讲述。本文第一部分讲述了私有协议分析的大致思路，第二部分开始以TeamViewer为例子对该协议进行行为观察和行为分析。

一、应用分析背景

1、什么是私有协议？

协议是计算机网络与分布式系统中各种通信实体键相互交互信息时必须遵守的一组规则和约定，这些规则明确规定了所交换的数据格式以及有段的同步问题，从而保证了双方通信有条不紊、可靠地交换信息。比较著名的网络协议有TCP/IP协议栈中的一些协议，比如IP、TCP、UDP、POP3、SMTP、HTTP等。已知协议都是有RFC规范的，按照规范解码就可以得到协议。

私有协议是指 协议格式 不公开的的协议。比如我们所知道的QQ，telegram,还有一些商用产品的通信协议，工控类的工控协议，甚至恶意软件所使用的通讯协议，都可以理解为私有协议。

2、分析私有哪些协议流量特征有哪些难点？

笔者认为，第一个难点是引起协议变化的场景未知。运营商在复杂多变的环境下生存下来，流量传输的协议格式必须发生变化，至于如何改变，对于协议分析者是未知的。第二个难点在于协议格式无明显规律，不能套用标准格式去分析私有协议。

3、私有协议的大体分析思路(Network Protocol Reverse Engineering)

基于网络流量的分析，以截获的网络数据流作为分析对象，依据协议字段的取值变化频率和和特征推断得到协议格式。其依据是：数据流中的当个报文是协议格式的一个实例，相同格式的报文样本往往具有相似性，可以将具有相似性的报文汇集到一起，推断他们所遵循的报文格式。

举个例子，利用Wireshark抓取pcap包，采用控制变量的思想，控制不同变量的输入，然后从数据包中提取协议格式，协议指纹。

4、私有协议分析的意义

分析私有协议有利于对复杂、大流量的网络流量进行监管和管控；当不法分子利用应用软件进行违法犯罪活动时，可以提取流量中相关信息，对犯罪份子的个人信息进行挖掘，追踪犯罪证据；对于利用私有协议保密性进行恶意攻击，信息窃取的行为，入侵检测可以通过对未知协议格式分析进行安全评估，寻找恶意代码特征。

二、TeamViewer身份协议分析

1.行为观察

1.心跳包

首先打开Wireshark，过滤出DNS协议，我们可以发现TeamViewer的一些非常显眼的域和子域名，以及一些不同的IP地址范围。这些IP地址有的会随时间变化而变化，而其他大多数是静止的。

结论一：我们可以将特定的域名及静态IP提取出来作为检测应用在电脑上开启但未知应用使用阶段的检测特征。

2.通讯行为

2.1 不可见通讯数据

从图片-通讯行为1-中可以看到，在操作TeamViewer的时候该应用存在关于TCP和DNS的准系统通信；

当应用请求连接时候他会发送一些DNS请求，随后又立即恢复到发送走TCP协议的包。

多次抓包后，观察发现TeamViewer的网络流量是在TCP端口5938上运行的自定义协议。

往下走，在此数据中可以看到一些较大的数据包，且包的数据是不可读的。

我们还发现通过UDP进行的通信。但是，同样，没有可读信息。

结论二：通讯行为中无论是在UDP还是TCP，其报文内容都不可读；

结论三：经过与16年，19年，20年的teamviewer版本pcap包比对，在TCP和UDP通讯数据中，5938端口是teamviewer比较固定的使用端口。

2.2 可见通讯数据

仔细观察，我发现蓝色区域这四个包协议，包的大小，长度，源端口都是一致的。而且，我发现172开头的IP，IP地址正是被连接的那台PC的IP。也就是说，从流量侧来看，我们是可以找到被连接的那台PC的。

点击UDP,看见以172开头的IP报文内容与124.65.9.61的报文内容出现相同的字符串 $GP (03 17 24 )。

结论4:经过多个TeamViewer版本的pcap包的对比，我们可以发现当连接的时候，他有【固定的】明文字符串 $GP(03 17 24 ).

接着我看到了tcp payload 部分，我注意到无论payload大小，payload的开头均为11 30，且在teamviewer连接成功前后都出现 11 30。

由此，我推测，11 30 应该是类似心跳包的指令。

还有许多数据包均以0x1724开头。最初我以为这是TLS应用程序数据记录数据包，因为当我看到以0x17开头的流量时通常就是这种情况。但是，由于如果下一个字节是TLS，则下一个字节将是主要版本号，而我看到的值是0x24，因此TLS没有意义。因此，我将其留待以后查看。

2.行为分析

2.0 从日志中寻找答案

到这里为止，似乎断了头绪。teamviewer是一个非常成熟的应用程序，具有广泛的功能，因此将它逆向并不是一件容易的事。但是，它的确保留了相当详细的日志文件(/Library/Logs/TeamViewer) 。我决定使用日志结合掌握自己的知识，并开始分解协议的各个部分，着重于身份验证。

从日志中，可以看见这些关键词组，如：

CKeepAliveClientClient::StartConnect，

CProcessCommandHandlerKeepAlive,

CKeepAliveClientClient::StartConnect(),

KeepAliveSession::KeepAliveChannelInitialized(),

SecureNetworkConnection::SendCallbackHandler()

等等诸如此类的关键词，我相信这些命令同样在流量上有一定含义。经过一番查找，我发现了前人写的一个脚本，可以用wireshark进行teamviewer 协议解析。

而之前发现的17 24 和 11 30 代表着teamviewer的版本号 v1 和 v2，后面紧跟的hex代表了指令，如示例1中的36 实际上代表着十进制中的54，既 tv_commands[54] = “CMD_SESSIONID” 。

是用插件验证猜想，结果如图示例2 ，实际情况与猜想一致。

似乎TeamViewer最初使用的是从客户端到服务器的v1命令，但在以后的身份验证阶段过渡到更多v2命令。尽管许多命令都是明文形式的，但有些命令却被混淆了（v1命令几乎被普遍混淆了，有些v2命令也被混淆了）。

随后我有点开多个 KEEPALIVEBEEP ,如图示例3所示，之前猜测11 30是心跳包，事实上是TeamViewer一个 Magic标识。

2.1 协议流程：登陆行为分析

TeamViewer客户端在启动时执行的第一阶段是Network Ping，然后登录到主服务器。TeamViewer有多个可用的主服务器（master <\d> .teamviewer.com）。我不知道它依据什么来选择master服务器，但从流量上我能看到本机客户端一般只能使用1歌或几个主服务器。

Ping和登录目的是识别客户端，并将其定向到心跳KeepAlive server。客户端连接到心跳KeepAlive server后，它将建立持久会话和联机状态。客户端通过主服务器启动出站连接，而服务器通过开放的KeepAlive连接启动入站连接。