传输协议不安全，数据泄露谁之过？——流量劫持技术分析

万物互联时代，无线网络全面覆盖我们的生活，基本上各家门店都有wifi标志，而且有的还没有密码，蹭WiFi似乎已成为一项基本“生存技能”，现代人的基本状态就像下面这首打油诗一样：

枯藤老树昏鸦，空调Wifi西瓜

葛优同款沙发，我就往那一趴

如果企业没有对自家应用做好数据防护，蹭网的同时，用户个人隐私也暴露在互联网中，不安全协议传输数据，直接导致用户数据被中间人劫持获取。

同时，流量被劫持获取，可以直接对服务器发起攻击，获取服务器业务数据、用户数据等核心资产信息。那么企业应该如何去避免此类攻击的发生呢？首先得去了解一下中间人攻击的前因后果。

中间人攻击的前因后果

协议先天性缺陷

（1）HTTP明文传输导致用户信息泄露？

从攻击的视频中可以知道，攻击者是实施了HTTP协议的中间人攻击，相信每个计算机行业人员都知道，超文本传输协议（HTTP，HyperText TranSfer Protocol）是互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个标准，也就是说万维网不得不使用这个协议，也是非常的尴尬。

从攻击者的角度是怎么看待这个问题呢？

寻找一个采用HTTP协议传输数据的网站系统，这里针对用户登录的账号信息进行数据获取，使用WireShark流量分析工具对局域网下的用户HTTP数据包进捕获，参考下图：

对TCP数据流进行数据分析，可以发现，存在明文的用户名uname和密码password，参考下图：

总结：由此可见HTTP数据流是用明文方式传输数据，攻击者可以利用局域网抓包等手段轻易获取用户与服务器的交互信息。 

（2）为什么HTTP是明文传输？

从上一小节可以知道攻击者抓取的HTTP数据包里面的数据是明文，为了解明文传输的原理，可以先了解以下在OSI七层模型中HTTP协议工作的地方，OSI模型七个层次的功能以及协议集图示如下：

根据OSI七层模型，可以知道HTTP协议工作在应用层，再来看看HTTP数据包的封装过程，发送方在客户端页面输入上层数据，上层数据到传输层会添加TCP报头形成数据段，再下送到网络层添加IP报头形成数据段，在继续下送至数据链路层添加以太网首部和尾部，形成以太网帧，最后传递至物理层形成01010形式的比特流，整个过程，上层数据这一部分没有进行任何加密数据处理，参考下图：

同理接收方也是如此，接受方收到二进制比特流，通过层层上送解包，最终获取明文的上层数据，参考下图：

总结：HTTP虽然是应用层的协议，但是其数据在整个数据装包中都是处于明文状态，只是不同层次之间进行了包的封装转换，在不同层次会看到不同的数据，比如在物理层，只能看到0101010类型的二进制比特流，但是在应用层却可以看到明文的数据，整个过程只是一个数据包的封装和解包，没有设计数据的加密和解密操作。

（3）中间人攻击的根源是什么？

通过了解HTTP明文传输的分析过后，结合OSI七层模型每一层的含义，参考如下：

路由器是存在于OSI七层模型的网络层，也就是通常接触最多的局域网，家里接入有线或者无线网络都会设置路由器，用户通过接入路由器与外界网络进行联系。

中间人攻击也是在这一层面实施攻击的，这一层存在的协议参考OSI七层模型可以知道有IP，ARP，ICMP等协议。在路由器层面，也就是局域网内是通过地址解析协议即ARP（AddreSS ReSolution Protocol），根据IP地址获取物理地址进行目标寻址交流。大概的流程内容如下：

• 主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址；

• 收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

ARP协议没有安全认证机制，因为局域网内主机是建立在信任的基础上的，所以只要主机接收到ARP应答包，都会缓存在ARP表中，这就为ARP欺骗提供了可能。攻击者可以发送错误的IP地址MAC地址的映射关系。

ARP欺骗主机等攻击是最常见的中间人攻击，在同一个局域网中，通过将网卡设置为混杂模式，借助ARP欺骗实现中间人攻击即可监听目标设备的网络通信。ARP攻击原理如下图：

主机A IP:192.168.1.2 MAC:02-02-02-02-02-02

主机B IP:192.168.1.3 MAC:03-03-03-03-03-03

网关 IP:192.168.1.1 MAC:01-01-01-01-01-01

主机B为攻击者，向被攻击者主机A不断发送ARP响应数据包内容：IP：192.168.1.1对应MAC：03-03-03-03-03-03 向网关不断发送ARP响应包内容：192.168.1.2对应MAC：03-03-03-03-03-03，在局域网内，广播寻址是根据MAC地址来定位用户地址的，所以，一旦mac地址进行了改变，用户地址也就进行了改变，由于ARP会更新缓存表的特性，导致了攻击者可以通过不断发送ARP响应包达到欺骗网关和被攻击者的目的，代替用户与网关进行信息交互，同时代替网关与用户联系，进而形成了中间人攻击。

总结：ARP缓存接受任何时间更新成为中间人攻击的根本原因

安全协议不安全

（1）HTTPS加密传输也存在信息泄漏？

开发人员针对部分不安全协议进行了安全控制，采用HTTP+SSL的方式进行数据传输，也就是我们常说的HTTPS协议。使用安全套接字层（SSL）进行信息交换，简单来说就是HTTP的安全版，来保证传输的数据安全。

从攻击者的角度是怎么看待这个问题呢？

可以通过实验来看结果，选择QQ邮箱登录网站，该网站使用HTTPS，使用WireShark抓包查看TCP数据量

追踪TCP数据流，数据全是乱码，无法识别数据，很明显数据已经被加密了，通过抓包并没有获取用户信息。

到这里一定会存在一个疑问，如果我的App与服务器全部采用HTTPS通信不就没有中间人攻击的问题了吗？

事实上如果用自己伪造的CA证书去加解密数据包，一样可以获取到敏感信息，大致攻击思路：攻击者在设备上导入并信任自己的CA证书，然后利用该证书进行数据的加密和解密，在这个过程中，明文信息已经被暴露在攻击者面前。

比如这里，将CA证书导入设备让其信任，使用工具抓包，能够清晰看见HTTPS数据包的信息。同样是qq邮箱登录的数据，区别就在于使用工具之前我让设备信任了自己的CA证书。当然这里并没有抓到明文密码，这是由于qq邮箱还有其他数据安全加密设置，参考下图：

总结：HTTPS证书信任机制出现问题，还是可以进行中间人攻击截取用户明文的数据流量。

（2）HTTPS为什么存在安全风险？

从上一节可以了解到，HTTPS加密协议也是存在中间人攻击的，为了解攻击的原理，我们可以先来看一看HTTPS的握手过程。这里以支付宝为例，利用WireShark获取支付宝的HTTPS数据流量进行分析

客户端发送Client Hello请求建立HTTPS链接，服务器返回Server Hello回应客户端接收到请求，并下发HTTPS证书给客户进行验证，客户端验证通过，发送对称加密密钥，进行数据交换。能够非常直观的看出握手流程，简单的HTTPS实现图

如果客户端未严格校验证书或者忽略了域名校验，攻击者可以通过对客户端进行操作，从而绕过客户端的弱校验，达到欺骗服务器，进行中间人攻击的目的。简单例举了HTTPS存在的问题

• 忽略SSL证书校验

• 忽略域名校验

• 证书信息泄漏 

情况一、信任任何证书。出现这种情况的原因很有可能是使用的开源通信库存在缺陷，还有就是开发人员在开发过程中未连接生产环境的服务器，为解决认证过程中证书报错的问题只能暂时修改代码使其APP信任任意证书，而在上线前未对此代码进行处理。通过对APP进行逆向分析，可以在客户端代码中发现存在开发人员忽略证书认证的代码片段

该段代码重写了谷歌原有X509Certificate[]的校验方式，进行了覆盖，却没有添加自己的证书校验代码，导致证书校验的代码为空，攻击者可以使用任意证书进行流量劫持，这里利用了工具自签名一个证书，即可进行HTTPS证书校验绕过，参考下图：

情况二、信任证书管理机构（CA）颁发的证书。这种情况的APP可以信任任何CA颁发的证书，据说这类的证书只需50美元就能买到。此类问题出在AFNetworking 2.5.2及之前的版本，也就是说如果某APP使用了此版本的开源通信库，在不安全Wifi网络中的黑客、VPN网络中的职工或者国家支持的黑客，只要使用CA颁发的证书就可以对该APP的HTTPS加密数据进行监听或者篡改，在源代码中发现配置代码片段：

该段代码一个重要的配置ALLOW_ALL_HOSTNAME_VERIFIER,使其信任官方的CA证书，无论是颁发给谁的，只要是官方的证书，都可以信任，从而导致验证失败。

情况三、信任合法证书。这种情况的APP只信任对自己而言合法的证书，首先我们看一下SSL认证的原理的前三步：1、客户端向服务器传送客户端SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。2、服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。3、客户端利用服务端传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行下一步。那么如何让APP信任非法的证书呢，看上文说到的3步，我们只需要做到在合法性验证的时候能够欺骗APP，通讯就不会中断。在手机本地添加一个信任证书，APP在本地验证的时候，由于手机信任该证书，APP默认也信任该证书，达到欺骗APP的目的。

情况四、这种情况是采用了服务器和客户端双向认证的措施，即客户端在确认服务器是否合法之后，服务器也要确认客户端是否是合法的（服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得用户的公钥）。正是这个原因，我们在测试APP时会发现尽管我们信任了burp或者fiddler的证书，可是在进行登录操作时APP依然会显示网络连接错误，此时服务端已经知道客户端可能是非法的，然后拒绝连接。如果你是开发人员，想分析HTTPS流量也很简单：使用burp导入客户端证书，此时burp就可以与服务器正常的建立连接，你也可以正常的截取到数据包了，只要获取到证书以及密钥，即可进行数据获取。APP开发时，在本地实现证书导入，应用于HTTPS双向校验传输证书的密钥可以在本地获取，参考实现代码片段

分析上例代码可以发现，应用于证书client.p12的密钥，猜测在he.b()/he.a()函数中会进行一个处理，利用hook技术，对函数内容进行hook，即可获取字符串信息，该信息包括了密钥和其他的数据，利用获取的密钥和本地保存的client.p12证书，即可模拟开发人员进行HTTPS双向验证，截取用户明文信息。

两者代码片段分别如下

总结：HTTPS安全协议不安全，主要还是在设计阶段选择了单向校验，在加上后期没有进行严格的证书校验，导致HTTPS证书验证被绕过，其次就是采用了双向校验，但是本地校验的代码没有进行安全保护，攻击者通过动态HOOK，也是可以获取CA证书以及其密钥信息。

（3）HTTPS中间人攻击的危害？

HTTPS虽然也存在中间人攻击，但是和ARP局域网攻击又存在很大的差别，参考下图：

ARP欺骗，数据信息攻击获取范围是介于路由器和用户手机之间，也就是OSI模型的数据链路层，路由器和用户手机之间传输的信息都可能被攻击者截取，通过中间人攻击获取在同一局域网下所有用户的数据流量

SSL欺骗，SSL是位于OSI模型的传输层和应用层之间，可以通过绕过APP本地校验机制实现在传输层和应用层之间的数据传输（数据到达应用层，也就是给用户的展示界面是明文的）截取，从而获取明文数据，或者是HTTPS相关的密钥信息。仅存在用户自己手机内部，只能获取攻击者本身操作的账户流量信息

总结：就攻击范围来讲，在客户端的攻击HTTPS攻击是影响面比较窄，但就针对服务端的攻击影响来看，两者是一致的，都可以操作服务端数据，获取服务端信息，都能危及服务器安全。

几维安全解决方案

应对传输协议缺陷，流量被劫持的安全风险，几维安全建议以协议安全，数据安全，应用代码安全为目标来应对中间人攻击。

首先对客户端APP的可执行文件DEX、SO、Mach-O被破解的风险，几维安全采用源代码保护技术，对DEX文件进行JAVA2C，将JAVA代码下沉至Native层，并在该层对转化后的伪C代码进行强度最高的虚拟化处理，对SO和Mach-O文件采用源代码编译的方式，直接把C/C++/Object-C/Swift工程项目编译成KiwiVM虚拟化后的结果，保障客户的不被攻击者逆向破解。

其次对在终端设备运行的客户端运行时会在内存中传递重要的数据，通过接入几维安全防御安全SDK，可以对手机环境，进程防护，代码注入等方面进行全面的检测和防护，保证本地内存数据不遭受恶意篡改。

同时，针对通道存在的明文传输和协议破解伪造风险，几维安全提供结合代码虚拟化技术和白盒技术研发的白盒密钥SDK。利用SDK对传输的数据和存储的数据进行高强度的加密，且提供动态加密、数据完整性校验等功能，支持多种对称加密、非对称加密和哈希算法，严格保障了数据的完整性和保密性。

文由几维安全