当下即时聊天工具几乎是每个移动端必备的软件，其中的聊天内容，如文本、语音、图片等隐私信息的泄露问题也备受关注。沙话（shadowTalk），作为一个基于P2P加密通讯的即时聊天工具脱颖而出，但是它确实安全可靠吗？

1、ShadowTalk基本情况

ShadowTalk的客户端有PC端（Windows和Mac）和手机端（Android和iOS），IOS版应用于 2015年7月发布，Android版应用于2015年8月发布。在它的产品页中，我们可以看到“采用点对点通讯方式将文字、图片、语音、视频发送给自己的好友，不通过中央服务器对数据存储转发，对通讯内容进行加密传输，使用户的聊天信息更加安全隐私”[1]的介绍，“基于P2P方式的信息传输”是其核心亮点之一。

我们团队于2016年7月19开始关注ShadowTalk，并对ShadowTalk客户端进行了测试。其中PC端的Windows版下载安装后总是打不开，所以以下测试都是在手机端上进行，手机端Android版一直没有更新，官网现在已经不能下载了，具体测试版本信息见表1。为防止本测试对ST所属公司或机构造成不必要的负面影响，特意推迟数月公布测试过程和结果。

	Android	iOS
测试版本	v1.26	v1.24
测试时间	2016-7-20	2016-7-20
最新版本	v1.26(官网已无)	v1.28
最新更新时间	无	2016-10-22

表1 测试基本信息

2、ShadowTalk威胁模型及对抗性评估方法

2.1 建立ShadowTalk安全威胁模型

ShadowTalk官网称其使用的是P2P加密通信技术（图1），那么以P2P作为安全通信的即时通讯工具，在安全威胁模型上有着显著的不同（图2），底层P2P网络结构和P2P通信协议的设计及实现是否安全可靠抗攻击，将直接决定该工具的整体安全价值。

图1 ShadowTalk六大功能

图2 P2P安全威胁模型

（1）P2P网络拓扑结构安全

即时通讯的基本要求就是在任何时候能够与其他用户沟通，那么ShadowTalk在网络拓扑的设计与部署对于ShadowTalk能否保证有可靠的通信质量至关重要。良好的网络拓扑结构设计能够保证ShadowTalk在复杂的网络环境中的稳定性。

（2）P2P通信协议安全

ShadowTalk强调了P2P通信，那么ShadowTalk需要保证在茫茫网海中使得两个用户能够互相定位且连接，同时在沟通过程中，聊天的记录是需要加密的，在QQ中，QQ设计了自己的通信协议和加密算法，那么ShadowTalk也需要设计出良好的P2P通信协议来保证用户的通信安全。

（3）终端工具安全

Android端和PC端中，用户是可以去查看ShadowTalk下的文件，且为了减少流量，加快应用运行速度，ShadowTalk肯定会在本地存储文件，这些文件必须得到管理。

（4）云端服务安全

ShadowTalk会向云端请求各种信息，云端需要提供稳定可靠的服务。

（5）用户隐私安全

ShadowTalk是匿名注册的，不会涉及个人信息方面的隐私问题，但是由于通信可以被窃取和解密，且在云端和本地中存储有相关信息，还是会存在用户隐私安全问题。

2.2 基于模拟对抗的安全性评估思路和方法

对照ShadowTalk的安全威胁模型，我们的对抗思路是：

（1）P2P网络拓扑安全

用户与用户之间的P2P连接，是采用了“直接连接”，还是“第三方云中继”，还是“多跳加密连接”？具体几跳？时延如何？每跳是否再次加密？是否能探测存在某些“核心中继节点”？在非正常情况下、如云端常用IP被封，云端是否有备用域名和IP，是否还有其它紧急回连手段如ftp，博客论坛，邮件地址等？

（2）P2P通信协议安全

用户如何获得好友信息？如何去连接好友进行通信？通信中的消息是否加密？加密是否可以破解？每个用户的加密解密key对是存在云端，每次都需要向server请求？还是都存在本地？用户如何更新key？用户连接server后，server如何将好友ip列表发送给用户？发送哪些信息？手机、家用计算机上网，IP是有运营商动态分配的，如何保证每次都能连接到对方？如果用户的好友是在含有路由器NAT的内网中，用户如何穿越NAT进行连接的？

（3）终端工具安全

本地是否存储了日志，记录了用户信息？是如何保存的？ShadowTalk的升级过程可否进行中间人欺骗？是否有下载签名验证？各种验证手段可否伪造？（如通过sinkhole等方法，从网关、IDC等位置，用伪造的客户端软件代替ShadowTalk真实升级包进行升级，从而控制客户。）

（4）云端服务安全

云端主要使用了哪些域名？域名解析后有哪些IP？用户每次完成通信，是否会向云端发送报告“我和谁连接，连接了多久”等之类的信息？通过流量截获，分析ShadowTalk的客户端升级和配置文件升级方法（含主动升级、被动推送），分析“升级失败”时其是否有备用策略（例如，从服务器升级改为P2P升级模式）。

（5）用户隐私安全

用户连接服务器，服务器是如何实现用户与账户配对的？ShadowTalk收集了什么信息来保证账户与用户的配对？ShadowTalk会发送什么信息给服务器？

针对以上思路可实施的方法有：

（1） 本地程序调试，分析key，加密算法，协议格式生成，安全验证逻辑，功能实现缺陷。

（2）局域网出口数据包截获与分析，配合本地调试获取的key和数据包格式，进行解码（需要编写解码程序）。

（3）对云端（如果有）/高等级中继节点（如果有）/其它对等节点的渗透入侵，获取更多的key, 以分析通信架构和备用通信模式，尝试获取更多不同类型的payload。

（4）远程欺骗。利用获取的key（一般肯定会有多层key，数据加密的对称key，身份验证的不对称公钥/私钥，集群验证的不对称key等等），数据包格式，命令格式，控制节点/中继节点的ip地址等，开发远程发包欺骗工具，发送我方指令，抢夺控制权。

（5）升级拦截。在局域网出口，网关等处，或者借助攻陷的对方控制服务器，利用之前破解的客户端本地验证手段漏洞，构造我们的升级包，彻底替换客户手中的客户端程序。

3、安全评测过程和结果分析

3.1 P2P网络拓扑结构评估

图3 第三方中转服务器

ShadowTalk官方提到采用的是P2P加密通讯模式，但是却经过第三方服务器进行中转（图3），所以可以说采用是混合式的P2P网络通信。用户在添加好友、删除好友、与好友聊天等操作中需要先通过服务器注册设备信息（device_token）确定通讯好友（图5），服务器端返回好友列表信息（图6），客户端再根据设备信息进行P2P通信（图4）。

图4 ShadowTalk通信架构图

图5 ShadowTalk通信设备信息

图6 好友列表信息返回值

3.2 P2P加密通信协议和终端工程实现评估

ShadowTalk的通信存在可被截取并破解得到通信信息的可能性，实验中可以很容易地获取本地存在的密钥以及加密算法，如图7。

图7 ShadowTalk加密通信协议

从图7可以看出，ShadowTalk通信使用的是对称加密算法AES，并带有初始向量的加密方式进行加密，最后对加密的数据进行base64混淆输出。可以通过反编译手段获取本地保存的key，并且发现这个key是固定不变的，每次通信都使用这个保存在本地的key。当软件需要更换密钥时，需要通过修改代码，才能更换密钥。通过抓包进行流量分析，发现聊天通讯时该应用会发送密文消息给服务器，可以判断出用户之间的通讯不是通过P2P直接连接的，而是通过第三方（友盟）云中继的方式来连接。

反编译apk发现有本地存储log的类，会将一些信息存储到本地数据库中，如图8。

图8 ShadowTalk通讯日志

3.3服务器端探测分析评估

对ShadowTalk进一步分析，发现ShadowTalk确实使用了C/S模式，并且用到了一些服务器域名（图9），域名如下：

log.umsns.com，用于获取密钥；

msg.umengcloud.com，主要用于信息的通讯；

pingma.qq.com，向服务器发送密文消息；

alog.umeng.com，友盟给自己发的log日志；

Api.fir.im，fir.im的第三方SDK，用于应用更新。

特别强调，我们尊重国内法律和行业规范，并没有对以上任何云端服务进行任何形式的探测、渗透或攻击。

实验表明在无法连接到服务器（被封或断网）情况下，抓包分析ShadowTalk并没有使用其他的备用域名服务器或回连手段。

图9 ShadowTalk通信设备信息

3.4 用户隐私安全评估

ShadowTalk采用私密阅读模式，发送的文字信息需要点击隐藏框才可查看，图片需要长按方可查看。通讯后不留痕迹，采用阅后即焚机制，可以设置消息阅读后即焚时间，自己发送消息后到达即焚时间自动删除发送内容，对方阅读消息后到达即焚时间自动删除阅读内容，对于对方未读消息可设置在对方终端的保留时间，到期后自动删除（测试中也遇到一个问题，发送的视频，提示轻触查看，轻触查看后一片漆黑没有视频消息）。但是，既然出现了第三方中转服务器，那么这些隐藏只是相对用户的，只要经过第三方服务器，必然会留下通信记录。

4、评估结论

从理论上而言，ShadowTalk采用P2P加密通讯，总体安全性比纯C/S模式高。但我们通过严谨认真的实验分析后发现：

1. ShadowTalk并不是真正的P2P结构，没有完全去中心化，而是通过第三方云中继进行转发，并非标准的P2P隐私通讯模式。应用只要通过第三方服务器消息将不再完全保密，会在服务器端被解密；

2. ShadowTalk的终端工程实现上存在安全缺陷，无法防范本地木马的信息拦截、解密等攻击；

3. ShadowTalk客户端缺乏必要的备用组网通道，抗屏蔽封锁能力较弱；

4. ShadowTalk云端参与的服务器类型过多，涉及多家公司的产品和服务，缺乏必要的隐蔽和自我保护手段，安全性存在短板。

 在此，我们谨提出一些善意的改进建议：

1. 如果想要避免服务器监听，需要在已经建立P2P通信后，双方再协商通信协议，或者交换新的加密密钥等方式；

2. 增强终端工具的抗逆向破解能力，改进加密协议实现；

3. 增加短信、邮件、社交网络等多种备用补网手段；

4. 简化云端服务，减少非必要组件。

参考文献：[1]

本文转载自作者：DarkRayTeam， 文章中分析工具Surge

本文固定链接: https://www.eoowo.com/?p=1043 | 火星博客