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

深碍√TFBOYSˉ_ 2022-04-24 14:06 271阅读 0赞

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

前言  
基本介绍  
准备中间人攻击  
实施中间人攻击  
TLS对中间人攻击的抵御  
无法抵御中间人攻击的实例（知乎，360浏览器）  
改进

回到顶部  
前言  
很早以前看过HTTPS的介绍，并了解过TLS的相关细节，也相信使用HTTPS是相对安全可靠的。直到前段时间在验证https代理通道连接时，搭建了MITM环境，才发现事实并不是我想的那样。由于部分应用开发者忽视证书的校验，或者对非法证书处理不当，让我们的网络会话几乎暴露在攻击者面前。  
下文会向大家展示的对IOS系统上2款常见的应用（知乎，360浏览器）进行MITM攻击，获取或篡改用户数据。  
回到顶部  
基本介绍  
中间人攻击的基本介绍可能看这里（[https://zh.wikipedia.org/wiki/][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插件（[https://www.cnblogs.com/lulianqi/p/10428551.html\#\_label0\_1][https_www.cnblogs.com_lulianqi_p_10428551.html_label0_1]可以在这里下载该插件），插件安装好后直接按下面截图配置即可（FreeHttp本身具备强大的自定义报文篡改能力，如果有兴趣可以在前面链接处查看详细内容）。

如上图打开Fiddler进入FreeHttp插件页签，添加一个请求修改规则，点击确定，将规则添加到规则列表并勾选该规则，将其置为可用。（如果您没有域名也可以用ip来代替，将[http://lulianqi.com:443][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][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还是相对安全的。

以上内容仅做交流，请勿用于实际网络攻击。  
原文地址[https://www.cnblogs.com/lulianqi/p/10558719.html][https_www.cnblogs.com_lulianqi_p_10558719.html]

[https_zh.wikipedia.org_wiki]: https://zh.wikipedia.org/wiki/
[https_www.cnblogs.com_lulianqi_p_10428551.html_label0_1]: https://www.cnblogs.com/lulianqi/p/10428551.html#_label0_1
[http_lulianqi.com_443]: http://lulianqi.com:443
[https_www.baidu.com]: https://www.baidu.com
[https_www.cnblogs.com_lulianqi_p_10558719.html]: https://www.cnblogs.com/lulianqi/p/10558719.html