HTTPS中间人攻击实践（原理·实践）

 

前言

很早之前看过HTTPS的介绍，并了解过TLS的相关细节，也相信使用HTTPS是相对安全可靠的。直到前段时间在验证https代理通道链接时，搭建了MITM环境，才发现事实并非我想的那样。因为部分应用开发者忽视证书的校验，或者对非法证书处理不当，让咱们的网络会话几乎暴露在攻击者面前。

下文会向你们展现的对IOS系统上2款常见的应用（知乎，360浏览器）进行MITM攻击，获取或篡改用户数据。

基本介绍

中间人攻击的基本介绍可能看这里（ https://zh.wikipedia.org/wiki/中间人攻击）。大体是说一种在网络中劫持会话的攻击方案，若是只监听流量称之为被动网络攻击（passive network attack），如何攻击者主动修改数据流称之为主动网络攻击（active network attack）。

好在20几年前Https就出现了，在保证会话安全的同时也能很好的抵御中间人攻击（不过飘逸的应用开发者们老是能不经意的忽视这种保护）

网上对中间人攻击的介绍还算多，不过具体到实践的就相对要少不少（这里是指针对https的中间人攻击实践）

 

 

上图简单的表述了中间人攻击的主要过程（上部为正常https流量，下部为被劫持的https流量），后面咱们能够对着这个图来实施咱们本身的中间人攻击。

准备中间人攻击

须要提早准备些简单常见工具：

1：Fiddler （注意虽然Fiddler抓取HTTPS报文的实际原理就是MITM，不过这里固然不是用Fiddler实施中间人攻击。由于Fiddler是自动完成的，也没有实践的意义，而且Fiddler须要被攻击者本身提早导入并信任根证书）

2：一个已经申请SSL证书的域名 （须要域名也意味着还须要一台代理该域名的nginx服务器，这里之因此选择一个真实的域名主要是为尽量了还原现实的场景，若是您没有域名也能够用ip代替，不过证书仍是要提早准备好）

这里用的是一个合法签发的DV证书（网上其实能够很容易找到免费的证书），通常浏览器或客户端校验证书时，都会先检查证书是不是“受信任的根证书颁发机构”颁发，再检查SSL证书中的证书吊销列表，再检查检查此SSL证书是否过时，再检查SSL证书的网站的域名是否与当前访问域名一致。若是使用一个合法签发的证书实际上能够经过大部分校验。

 

HTTPS 会话的发起是须要先创建SSL通道的。

咱们借助Fiddler将全部HTTPS的流量引导到咱们本身的服务器【lulianqi.com】

引导流量须要使用到FreeHttp插件（ http://www.javashuo.com/article/p-dflfncnc-nc.html能够在这里下载该插件），插件安装好后直接按下面截图配置便可（FreeHttp自己具有强大的自定义报文篡改能力，若是有兴趣能够在前面连接处查看详细内容）。

如上图打开Fiddler进入FreeHttp插件页签，添加一个请求修改规则，点击肯定，将规则添加到规则列表并勾选该规则，将其置为可用。（若是您没有域名也能够用ip来代替，将http://lulianqi.com:443换成http://您服务器的ip:443便可）（注意图中红色线框标记的地方，如以上设置启用规则）

这里简单说明下使用代理的HTTPS请求会利用Connect请求创建SSL通道，咱们修改Connect链接目标便可（由于这个时候SSL通道尚未创建，目标地址仍是明文，咱们能够直接修改，这样操做能够模拟网络中存在的攻击）

 

FreeHttp默认跳过connect tunnels，因此这里咱们须要在设置项里设置is skip connect tunnels 为否（按图中提示操做便可）

 

而后是Fiddler本身的设置

如上图，在Options中配置仅捕获Connects，上面也有提到实际上咱们不须要Fiddler进行中间人攻击，因此不用解密，也不用在客户端导入证书

 

最后咱们须要配置咱们的服务器【lulianqi.com】上的nginx （固然，在这以前您的nginx须要在服务器上先安装并配置好网络）

如上图咱们直接在nginx中添加一个server用于劫持会话（咱们本身的域名要解析过来），证书使用的是lulianqi.com的一个dv证书。

这个nginx实际是就是中间人了，如今咱们的中间人仅仅劫持流量（即被动网络攻击），但一旦流量到了咱们的服务器并且SSL通道是与咱们的服务器创建的，即表示咱们能够任意的处理这些流量，随时均可以进行主动网络攻击。

 

实施中间人攻击

全部准备工做作完了咱们就能够看下中间人攻击的效果了

 

TLS对中间人攻击的抵御

固然正常状况下，咱们的网络安全确定不会这么脆弱，因此暂时咱们在下面看到的是在一切正常的状况下，看浏览器是如何借助HTTPS（LTS）抵御中间人攻击的

用浏览器访问https://www.baidu.com

得利于TLS证书体系，虽然咱们能发起中间人攻击，不过浏览器察觉到了证书的异常（这个时候就怕你点继续浏览）

浏览器如何知道当前通道存在风险的，浏览器一开始就知道本身须要链接的主机是www.baidu.com，咱们虽然经过网络劫持的方式让浏览器觉得咱们的中间人服务器就是www.baidu.com，不过咱们的中间人服务器却没有www.baidu.com的证书，因此咱们依然使用了lulianqi.com的证书，前面咱们也提到过了浏览器等客户端会检查“受信任的根证书颁发机构”，证书吊销列表，SSL证书是否过时，证书签发的域名。最后浏览器发现咱们证书签发的域名不是www.baidu.com，天然就知道了当前网络的风险，而后中止发送真实业务请求，并向用户提示或询问。

（证书的校验有赖于CA，而CA通常都是比较权威的组织机构，咱们选择信任他们)

 

若是用户执意访问，就会出现如上图证书提示的错误，但一样意味着您可能正处于攻击下（事实上的确如此）

而后咱们我服务器就完美的劫持了用户的会话，全部信息都暴露了（因此遇到这样的提示仍是不要点确认比较好）

 补充说明下上图及下文中相似的图片都是中间人服务器nginx的访问日志，若是日志中出现相应请求报文，即表示中间人攻击实施成功。

 

这里顺便看下Chrome的表现

Chrome明显对HSTS处理更为出色。由于对于已经开启严格安全传输HSTS的www.baidu.com，浏览器发现证书错误后，Chrome的作法是直接禁止访问，而Edge依然能够经过询问的方式继续访问

 

上面的实例演示了中间人攻击发起的基本过程，及浏览器是如何经过证书体系来抵御中间人攻击的。（HTTPS对中间人攻击的抵御）

还有一点须要说明上文及下文提到的流量或对话都是指HTTPS，若是您使用的是http那么风险随时都在。

 

 

没法抵御中间人攻击的实例（知乎，360浏览器）

现实中咱们被手机陪伴的时间明显更多，咱们下面来看下手机上移动应用是否能抵御这种中间人攻击。

许多应用使用HTTPS与后端进行通讯，这种作法在系统程序，网站及移动应用中很是常见。不幸的是，应用开发者每每没有正确的对证书进行校验，这样系统实际对攻击者敞开了怀抱。

QA流程应该包括证书校验方面的测试。

 

首先咱们将手机连上Fiddler代理（注意这里咱们不须要让手机安装或信任任何第三方证书）

咱们尝试着如平常生活同样使用手机（注意这里测试使用的都是IOS上APP）

 

 

 

 

大部分应用出现了没法访问，弹出式安全提示等反应

不过不幸的是仍然有一些应用无视了证书的保护，直接与危险的中间人服务器创建了链接，并向用户正常的显示了页面等数据。

下面列几个表明性强的APP进行说明 （这里不是特地选择这些APP，只是我手机中正好安装有，并且我的认为这些APP你们也比较经常使用）

 

1：知乎 （IOS版 4.34.1（1228） ）

 

 

 

能够清楚看到知乎是彻底无视了证书不匹配的错误，与没有受到MITM时表现是同样的，正常访问，正常提交数据。但事实倒是全部流量都是经过中间人服务器转发到知乎的，中间服务器解密了全部流量，而且能够对其进行篡改。更糟的是这一切发生的时候，用户是彻底不知情的。简单的说就是当您在使用知乎APP浏览或发帖时，网络节点中的任何别有用心的人都是能够获取您在浏览的内容，并对其进行修改。（这样的描述一点都不夸张，后面会说明实际MITM中，也不会须要您的手机提早链接Fiddler代理，有许多可行且更隐秘的方式能够将流量引入中间人服务器。若是应用不能识别到分享，就会跟上面描述的状况同样）

 2：360浏览器（IOS版本360浏览器 4.0.10）

其实某款特定APP因为自身安全问题不能抵御MITM，最多也只会影响到本身的APP及本身的用户，不过浏览器若是出现这种问题就会对使用者全部浏览的网站都有影响

特别是以安全为一大卖点的360，其自家浏览器的安全策略让人没法理解

 

 

 

 

 

 

上面的截图来自使用360浏览器分别浏览baidu及apple的状况，能够看到使用360手机浏览器浏览网页（开启https的网站），在受到MITM时只有一个不起眼的变化，那个本来应该是绿色的小盾牌变成了灰色，而且没有向用户进行任何询问，直接就创建了不安全的SSL通道，后面的状况就很惊悚了，全部使用360手机浏览器浏览的内容所有被中间人服务器劫持。

一开始本身也并不相信360手机浏览器会直接无视证书错误，不向用户询问。特地找了另外一台没有安装过360手机浏览器的手机（iphone6），在AppStore里下载了新版本的360手机浏览器测试，结果是同样的，除了那个不起眼的灰色小盾牌彻底无视了证书域名不匹配的错误。（顺便提一下上面的知乎也同样，都用新手机测试过，的确有安全问题）

 

3：其余APP

固然我在本身手机了不仅发现上面2款APP存在上面的问题，还有许多APP存在相似的问题，包括个别金融类应用，还有部分APP部分模块的流量存在被劫持的风险。这里也就不一一列出。

经过上面的实践能够看出咱们平时使用的网络并不安全，部分开发者忽视证书校验，或对证书异常处理不当，致使原本十分有效LTS失去本来的防护能力。

 

 

改进

仍是强调下，我的对于上面提到的2款App（知乎，360浏览器）并无恶意，只是借此说明下当前网络大环境下确实存在的一些安全风险。

也但愿2款APP的相关开发者看到后，能够及时改进，为用户提供更安全的使用环境。

 

以上实践测试环境（你们能够此从新上面的效果）

手机：iphone6（10.3.3） ，iphone6s （11.3.1），iphone8 plus（11.2.1）    

服务器：CentOS （7.3） nginx （1.10.3） 

以上测试的2款应用均是苹果版本的APP

知乎 （4.34.1）

360手机浏览器（4.0.10）

 

上述中间人攻击实践中使用到了Fiddler及FreeHttp插件仅是为了方便控制及调试中间人攻击的状态，实际操做中并不须要Fiddler，也就是说你的手机不须要链接任何代理，由于每每流量的劫持发生在更隐蔽的网络节点中，如链路中的网络设备彻底能够在无感的状况下将通过本身的流量先转发到中间人服务器,或者这种劫持也可能由DNS解析引发，您能够尝试修改host文件模拟dns劫持将目标域名指向中间人服务器一样能够获得上面的结果。

事实上ARP欺骗，WPAD劫持，DNS劫持，BGP路由劫持，都会为这种中间人攻击创造条件（做为网络设备的控制者实施起来就更容易了，因此不要链接不认识的wifi热点，固然对于网络运营商咱们也只能选择相信）

开发者只要正确的在所在平台的底层TLS库中开启证书校验，并对异常证书作合理处理，HTTPS仍是相对安全的。

 

以上内容仅作交流，请勿用于实际网络攻击。