国产浏览器往往基于Chrome浏览器开发，在带来新功效的情况下也带来了新的平安威胁。

　　本文将披露某国产浏览器的中间人信息泄露破绽以及科普bettercap攻击剧本的编写方式。

　　笔者本想按着先进们的文章测试下国产浏览器的特权域破绽，然则在测试历程中意外发现了某国产浏览器的一个中间人信息泄露破绽。

　　如图，每当该浏览器接见某URL的时刻，都市向该浏览器官方的某个系统请求一个urlcheck来检查该URL是否平安，其中请求的url参数就是base64后的url。

　　

　　我们暂且信赖该浏览器官方是善意的不会保留我们的urlcheck纪录，但这种HTTP明文请求仍然会使其易于遭受中间人攻击，导致纵然有SSL珍爱的情形下URL仍然会被泄露的问题，同时攻击者也可以据此伪造可信网站举行钓鱼攻击。

　　关于中间人攻击，由于笔者信赖FreeBuf读者均具有相关的知识且其原理细节并非本文重点，在此不予详细叙述。简而言之，该攻击能使攻击者容易的截取及替换明文传输的内容，可能导致信息泄露，信息被窜改，甚至系统被拿下。

　　显而易见，攻击者可以通过截取请求包并替换来举行破绽行使。

　　在这里破绽的演示攻击中，我们接纳bettercap攻击举行演示。

　　bettercap早在几年前就被公布出来，是各种无线攻击的瑞士军（协调）刀，具有取代ettercap的野心。

　　在原有的1.0版本中可以通过下令行参数来举行许多中间人攻击，而在2.0之后的版本该工具借鉴了MSF的模块化头脑，主要通过交互式终端执行举行攻击。

　　现在bettercap还提供一个漂亮的UI供攻击者简化攻击历程，不外本文并不会涉及该UI的使用。

　　

　　比起老牌的ettercap，该工具具有如下优点

　　1,加倍稳固，不像ettercap容易溃逃

　　2,易于拓展，可以用其支持的cap剧本和js代码拓展

　　3,易于操作，具有加倍简朴的下令举行arp诱骗

　　在编写剧本自动化攻击之前，我们可以先使用Burpsuite配合bettercap测试中间人攻击。

　　赫赫有名的Burpsuite已被人人熟知，但许多人只知道用它来抓包测试web层的破绽，不知道它也能用来举行中间人攻击

　　在举行中间人攻击测试之前，我们对Burpsuite举行一些简朴的设置。

　　首先我们需要去Burpsuite的proxy处，选中options,对我们的署理选择edit，

　　在Binding处选择All interfaces。由于burpsuite默认只允许内陆IP接见，而我们需要局域网内的机械来接见 。

　　

　　接着再在request handling处选择support invisible proxying来打开透明署理。

　　之所以我们要这么做是由于在署理的时刻我们无法解密SSL流量，应该让Burpsuite直接放行加密流量而不是做中间人替换证书。

　　使用bettercap攻击远比ettercap简朴，我们只需要两个下令就可以了。

　　any.proxy是bettercap自带的一个模块，它能够将流量举行重定向使得被攻击的机械的流量到达我们指定的署理。

　　使用any.proxy on 其用该模块，其中any.proxy的端口默认就是本机的端口，无需设置正好和burp一样。

　　而arp.spoof是arp攻击模块,直接arp.spoof on就能开启攻击了，默认攻击局限是整个局域网。

　　

　　攻击效果

　　

　　如上图所示，我们能够在不在靶机上安装证书的情况下，通过urlcheck的返回效果获取到原本该被SSL珍爱的URL，读出了bing搜索中的搜索内容（）。

　　同时通过手动改包，我们能够修改网站的标识（把Bing改成了Google），显示了这个破绽也可能被用于辅助社会工程学攻击。

　　这些效果很棒，然则作为黑客我们是不会满足于手动抓包改包这样只有观点验证性功效的实验的，我们需要将这个破绽自动化行使。

　　幸运的是，bettercap对于拓展其功效有着优越的支持。

　　bettercap允许我们用caplets编写自动化剧本举行攻击。caplets指的是后缀为.cap的剧本，能够直接执行bettercap的交互终端下令而不需要一条一条地手动输入，类似于metasploit的rc剧本。同时若是用它来修改http.proxy这个http流量阻挡模块，我们可以容易指定加载该cap目录下的js剧本而不需要思量绝对路径。

　　bettercap提供了如下几个下令来辅助用户治理已有的caplets。

　　可以知道bettercap默认的caplets搜索路径有三个。

　　

　　在默认情况下，自带的caplets被放置在/usr/share/bettercap/caplets/，用户可以确立目录来和其余的模块离隔，bettercap会自动递归这些目录来查找可用的caplets。

　　

　　在了解了caplets的基本编写规则之后，我们看看若何拓展原有的http嗅探模块来嗅探url。

　　bettercap的http.proxy模块提供一个http的透明署理，能够监听并修改流量，而且可以允许用户编写js代码来自界说其行为。它可以和bettercap的arp.spoof模块配合实现中间人攻击。

　　该模块有着如下参数可以设置

　　参数

　　默认设置

　　形貌

　　http.port

　　80

　　需要转发的端口的流量

　　http.proxy.address

　　 <本机地址>本机地址>

　　内陆署理绑定的地址

　　http.proxy.port

　　

　　内陆署理的端口

　　http.proxy.sslstrip

　　false

　　是否打开sslstrip

　　http.proxy.script

　　用于操控模块的js 剧本路径

　　http.proxy.injectjs

　　注射进受害机的

　　http.proxy.blacklist

　　不举行署理的黑名单（用逗号离隔，支持wildchard)

　　http.proxy.whitelist

　　当黑名单启用的时刻需要通过署理的白名单（用逗号离隔)我们将会用到该模块的两个下令

　　我们这次需要编写的caplets中需要用到如下下令

　　编写http.proxy是重头戏，

　　而拓展http.proxy的js剧本花样如下

　　在今天的bettercap剧本编写示例中我们将会编写这里的onRequest和onResponse函数。

　　在onRequest和onResponse函数中的req和res就是传入的请求和返回效果。

　　关于req和res支持的操作，官方文档并没有提供一个完整详细的列表，然则笔者阅读了许多caplets的源码找出了以下用法

　　用法

　　说明

　　req.Path

　　url路径

　　req.GetHeader(“User-Agent”, “”)

　　获取某请求头

　　req.Client.IP

　　客户端IP

　　req.Hostname

　　server的主机名

　　req.Headers

　　获取所有请求头

　　req.Method

　　请求方式

　　req.ContentType

　　Content-Type

　　req.Query

　　获取查询字符串

　　req.ParseForm();

　　获取POST包的字典

　　req.ReadBody()

　　获取请求包的body

　　res用法

　　用法

　　说明

　　res.Body

　　返回包的body,只能修改用于改包而不能读效果

　　res.ContentType

　　Content-Type

　　res.SetHeader(“Content-Length”, )

　　设置返回包的头

　　res.Status

　　返回包的状态码

　　res.ReadBody

　　获取返回包的body(在onResponse时使用）

　　在知道了如上信息之后我们就可以编写我们的caplets了，首先在/usr/share/bettercap/caplets/目录下确立目录uc-url

　　确立uc-url.cap文件，编写文件使内容为

　　这个剧本的注释：第一行是设置http.proxy.script，即我们即将编写的拓展剧本

　　接着启用http.proxy模块

　　最后启用arp.spoof模块，由于没有指定目的，默认对同局域网所有主机执行arp攻击

　　接着我们在同目录下确立uc-url.js，编写如下内容

　　前面的RESET,G,R函数用于处置字符串，使其在终端输出的时刻有颜色。

　　其中onRequest函数中，我们凭据请求的方式，url的路径，以及hostname判断了urlcheck包。

　　若是是urlcheck包，则通过ParseForm函数获取其url参数而且用atob函数base64解码，最后在终端上打印该URL。

　　在onResponse函数中，我们也如法炮制，获取返回效果并修改。由于笔者的恶趣味，笔者将返回效果的title替换成了直播间，这样每当有可信网站的效果返回的时刻，这个对可信网站的形貌就会被替换成直播间。

　　攻击效果

　　在一切完成之后，通过如下下令执行攻击

　　如图，UC浏览器用户在SSL情况下接见freebuf时URL仍然能够被攻击者获取

　　由于freebuf并没有被标注为可信网站，再来一个网站标识替换后的效果图

　　

　　只管已经是年，大量的网站系统仍然没有使用SSL加密，中间人攻击仍然有其一席之地。对于平安研究者来讲，掌握相关知识，学习更新更好用的攻击工具的使用方式仍然是需要的。而开发者应该在开发的时刻思量到中间人攻击带来的威胁，部署SSL或者使用其余加密手段来抵御中间人攻击。

　　*本文原创作者：APU