“P2P安全通讯工具”ShadowTalk确实安全可靠吗?

*本文原创作者:DarkRayTeam,本文属FreeBuf原创奖励计划,未经许可禁止转载

当下即时聊天工具几乎是每个移动端必备的软件,其中的聊天内容,如文本、语音、图片等隐私信息的泄露问题也备受关注。沙话(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.png

图1 ShadowTalk六大功能

2.png

图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网络拓扑结构评估

说明: IMG_1203

图3 第三方中转服务器

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

14809346454909.png!small

图4 ShadowTalk通信架构图

14809346929542.png!small

图5 ShadowTalk通信设备信息

14809347241814.png!small

图6 好友列表信息返回值

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

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

14809347443919.png!small

图7 ShadowTalk加密通信协议

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

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

14809347611386.png!small

图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并没有使用其他的备用域名服务器或回连手段。

14809347972130.png!small

图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,本文属FreeBuf原创奖励计划,未经许可禁止转载